Our goal is to allow the applicatio

Our goal is to allow the application to make adaptation decisions in response to fluctuations in QoS seen by a flow, but the adaptation process should be under the control of the user.

2.1. Interactions between the user and the application

We do not consider in detail the mechanisms for interactions with the user but we discuss the requirements of the user in allowing the application to make adaptation decisions dynamically.

There may be many instances of an application used by many different users. Each of the users will have their own preferences for the application. Any decision-making process for adaptation must allow the application to apply user preferences to the information about QoS being experienced by the flow. For example, with an audio tool with numerous encoding schemes, one user may specify that the tool “always uses the best audio quality possible” while another user may specify that the tool aims to “retain stability” in the face of network QoS fluctuations. The application may interpret these preferences as meaning the “encoding with the highest data rate requirement whenever possible” and “do not change flow-state too often”, respectively. So the adaptation decision is not only application specific but also application instance specific, and controlled by user preferences.

Typically, we would like user preferences to reflect the fact that users may have minimum technical knowledge. User QoS preferences may be expressed as an application-specific enumeration such as “high”, “medium” or “low” quality. As the application will be making flow-state changes, the user may wish to specify QoS stability criterion, e.g. “do not change flow-state more than once every minute”. Note that the this last criterion is the user's request for the application not to change to a “better” quality flow-state too often (i.e. avoid state-flapping), but if the QoS degrades, then we would expect the application to adapt as required.

Such heterogeneity means that the adaptation decision information reflects a per-instance view. So the information used by the application to make adaptation decisions should:

•
Not unduly constrain the QoS mapping from user requirements to application capabilities.
•
Be amenable to the mapping of the user QoS preferences and QoS stability criterion on a per application instance basis.
2.2. Interactions between the application and the network

Before an application instance can make decisions about any changes in its behaviour, it needs to know what is “sensible” for its flows, i.e. what its current network connectivity can support. This requires some information from the network. Information about the network is typically expressed as values of QoS parameters such as delay, jitter, available capacity, loss, etc. This information may be received in a number of ways:

•
Via local mechanisms, e.g. from the communication stack on the host.
•
Via application-specific mechanisms, e.g. via proprietary signalling.
•
As control messages from the remote receivers of the flow, e.g. using RTP/RTCP [8].
•
From network management tools, e.g. using SNMP [9].
If we consider that “the application knows best”, then we must appreciate that there is likely to be no single “best” ubiquitous solution for getting information about the resources within the network. The “best” mechanism may depend on the network environment or the application's function or both, but only the application (application designer) is in a position to make that assessment.

The application must also have some way of expressing its functional capability in terms of the construction of its flows, i.e. which flow-states its flows can use. Typically, these will be performance bounds defined in terms of QoS parameter values for the flow-states, e.g. minimum data rate required, maximum delay, etc. Note that as a definition of a flow is application-specific, so is the timescale over which measurements of such performance bounds are measured. This means that our model must be capable of working in whatever timescales are specified by the application.

ผลลัพธ์ (ไทย) 1:

เป้าหมายของเราคือการ อนุญาตให้โปรแกรมประยุกต์เพื่อทำการตัดสินใจปรับตัวตอบสนองต่อการผันผวนของ QoS โดยการไหล แต่ควรมีการปรับตัวภายใต้การควบคุมของผู้ใช้2.1. การโต้ตอบระหว่างผู้ใช้และโปรแกรมประยุกต์เราไม่ต้องพิจารณาในรายละเอียดกลไกการสำหรับการโต้ตอบกับผู้ใช้ แต่เรากล่าวถึงความต้องการของผู้ใช้ในการอนุญาตให้โปรแกรมประยุกต์เพื่อทำการตัดสินใจการปรับตัวแบบไดนามิกอาจมีหลายอินสแตนซ์ของโปรแกรมประยุกต์ที่ใช้ผู้ใช้ที่แตกต่างกันจำนวนมาก แต่ละผู้ใช้จะมีลักษณะของตนเองสำหรับแอพลิเคชัน กระบวนการตัดสินใจสำหรับการปรับตัวต้องให้โปรแกรมประยุกต์เพื่อที่ใช้การกำหนดลักษณะผู้ใช้ข้อมูลเกี่ยวกับ QoS ที่ถูกพบ โดยการไหล มีเครื่องมือเสียงมีหลายรูปแบบเข้ารหัส ผู้ใช้หนึ่งอาจระบุที่เครื่องมือ "จะใช้คุณภาพเสียงดีสุด" ในขณะที่อีกผู้ใช้อาจระบุว่า เครื่องมือมีวัตถุประสงค์เพื่อ "รักษาความมั่นคง" ในการเผชิญกับความผันผวนของ QoS ของเครือข่ายได้ โปรแกรมประยุกต์อาจตีค่าเหล่านี้เป็นความหมาย "เข้ารหัสข้อมูลสูงที่สุดในข้อกำหนดอัตราได้" และ "ไม่ เปลี่ยนสถานะการไหลบ่อยเกินไป" ตามลำดับ ดังนั้นการตัดสินใจการปรับตัวเป็นโปรแกรมประยุกต์ที่ระบุไม่เพียง แต่ยังอินสแตนซ์ของโปรแกรมประยุกต์เฉพาะ และการควบคุมการกำหนดลักษณะผู้ใช้โดยปกติ เราต้องกำหนดลักษณะผู้ใช้เพื่อสะท้อนความจริงที่ว่า ผู้ใช้อาจมีความรู้ทางเทคนิคที่ต่ำสุด ตั้งค่า QoS ของผู้ใช้อาจเป็นการแจงนับของแอพลิเคชันเฉพาะเช่น "สูง" "กลาง" หรือ "ต่ำ" คุณภาพ เป็นโปรแกรมที่จะทำการเปลี่ยนแปลงสถานะการไหล ผู้ใช้อาจต้องการระบุเกณฑ์เสถียรภาพ QoS เช่น "ไม่สามารถเปลี่ยนสถานะการไหลมากกว่าหนึ่งครั้งทุกนาที" หมายเหตุนี้สุดเกณฑ์ร้องขอของผู้ใช้สำหรับโปรแกรมประยุกต์ไม่ให้เปลี่ยนไปยัง "ดีกว่า" คุณภาพไหลบ่อยเกินไป (เช่นหลีกเลี่ยงการกระพือรัฐ), แต่ถ้าลดการ QoS แล้วเราคาดหวังว่าโปรแกรมที่ปรับเปลี่ยนตามความต้องการHeterogeneity ดังกล่าวหมายความ ว่า ข้อมูลการตัดสินใจปรับตัวสะท้อนมุมมองต่ออินสแตนซ์ ดังนั้น ข้อมูลที่ใช้ โดยโปรแกรมประยุกต์การปรับตัดสินใจควร:•อันเป็นสาเหตุไม่จำกัดการแม็ป QoS จากความต้องการของผู้ใช้ไปประยุกต์•จะคล้อยตามการกำหนดลักษณะผู้ใช้ QoS และเกณฑ์เสถียรภาพ QoS บนการแมปที่ต่ออินสแตนซ์แอพลิเคชัน2.2. การโต้ตอบระหว่างโปรแกรมประยุกต์ของเครือข่ายก่อนที่อินสแตนซ์แอพลิเคชันสามารถตัดสินใจเกี่ยวกับการเปลี่ยนแปลงในพฤติกรรมของมัน มันต้องรู้ว่าสิ่งที่ "เหมาะสม" สำหรับของไหล เช่นสิ่งที่เชื่อมต่อเครือข่ายปัจจุบันสามารถรองรับได้ นี้ต้องใช้ข้อมูลจากเครือข่าย โดยทั่วไปมีแสดงข้อมูลเกี่ยวกับเครือข่ายเป็นค่าของพารามิเตอร์ QoS ล่าช้า กระวนกระวายใจ ความจุ ขาดทุน ฯลฯ ข้อมูลนี้อาจได้รับในหลายวิธี:•ผ่านกลไกท้องถิ่น จากกองสื่อสารบนโฮสต์•ผ่านกลไกงานเฉพาะ เช่นผ่านไฟสัญญาณเป็นกรรมสิทธิ์•เป็นข้อความควบคุมจากระยะไกลรับของไหล เช่น ใช้ RTP/RTCP [8]•จากเครื่องมือการจัดการเครือข่าย เช่นใช้ SNMP [9]ถ้าเราพิจารณาว่า "โปรแกรมที่รู้ดีที่สุด" แล้วเราต้องขอบคุณที่ มีแนวโน้มที่จะไม่แก้ปัญหา "ที่สุด" อยู่ทุกหนแห่งเดียวสำหรับการรับข้อมูลเกี่ยวกับทรัพยากรภายในเครือข่าย กลไก "ที่สุด" อาจขึ้นบนระบบเครือข่าย หรือฟังก์ชันของโปรแกรมประยุกต์ หรือทั้ง แต่เฉพาะโปรแกรมประยุกต์ (ออกแบบประยุกต์) อยู่ในตำแหน่งที่จะทำให้ประเมินว่าโปรแกรมประยุกต์ต้องมีแบบของความสามารถในการทำงานในด้านการก่อสร้างของการไหล เช่นกระแสของไหล-อเมริกาซึ่งสามารถใช้ โดยทั่วไป เหล่านี้จะเป็นขอบเขตประสิทธิภาพการทำงานที่กำหนดในแง่ของค่าพารามิเตอร์ QoS สำหรับกระแสอเมริกา เช่น อัตราข้อมูลขั้นต่ำที่จำเป็น ความล่าช้าสูงสุด ฯลฯ หมายเหตุว่า เป็นคำจำกัดความของการไหลเฉพาะโปรแกรมประยุกต์ ให้เป็นสเกลวัดขอบเขตเหนือการวัดประสิทธิภาพการทำงานดังกล่าว หมายความ ว่า รูปแบบของเราต้องสามารถทำงาน timescales ใดถูกกำหนดโดยโปรแกรมประยุกต์

ผลลัพธ์ (ไทย) 2:

เป้าหมายของเราคือการอนุญาตให้ใช้ในการตัดสินใจในการปรับตัวเพื่อตอบสนองต่อความผันผวนของ QoS เห็นได้จากการไหล แต่กระบวนการการปรับตัวควรอยู่ภายใต้การควบคุมของผู้ใช้. 2.1 ปฏิสัมพันธ์ระหว่างผู้ใช้และการประยุกต์ใช้เราไม่ได้พิจารณาในรายละเอียดกลไกสำหรับการโต้ตอบกับผู้ใช้ แต่เราหารือเกี่ยวกับความต้องการของผู้ใช้ในการช่วยให้การประยุกต์ใช้ในการตัดสินใจในการปรับตัวแบบไดนามิก. อาจจะมีหลาย ๆ กรณีของแอพลิเคชันที่ใช้โดยที่แตกต่างกัน ผู้ใช้ ผู้ใช้แต่ละคนจะมีค่าของตัวเองสำหรับการประยุกต์ใช้ ใด ๆ กระบวนการตัดสินใจในการปรับตัวจะต้องอนุญาตให้แอพลิเคชันเพื่อใช้การตั้งค่าการใช้ข้อมูลเกี่ยวกับ QoS ที่ถูกมีประสบการณ์โดยการไหล ตัวอย่างเช่นมีเครื่องมือที่เสียงที่มีรูปแบบการเข้ารหัสหลายผู้ใช้คนหนึ่งอาจจะระบุว่าเครื่องมือที่ "มักจะใช้คุณภาพเสียงที่ดีที่สุดที่เป็นไปได้" ในขณะที่ผู้ใช้รายอื่นอาจระบุว่าเครื่องมือที่มีจุดมุ่งหมายเพื่อ "รักษาความมั่นคง" ในหน้าของ QoS เครือข่ายความผันผวน โปรแกรมประยุกต์อาจตีความตั้งค่าเหล่านี้เป็นความหมายว่า "การเข้ารหัสที่มีความต้องการอัตราการส่งข้อมูลสูงสุดเมื่อใดก็ตามที่เป็นไปได้" และ "ไม่เปลี่ยนการไหลของรัฐมากเกินไปมักจะ" ตามลำดับ ดังนั้นการตัดสินใจการปรับตัวไม่ได้ใช้เฉพาะ แต่ยังอินสแตนซ์ที่ใช้เฉพาะเท่านั้นและควบคุมโดยค่าของผู้ใช้. โดยปกติเราต้องการตั้งค่าผู้ใช้ที่จะสะท้อนให้เห็นถึงความจริงที่ว่าผู้ใช้อาจจะมีความรู้ทางเทคนิคขั้นต่ำ การตั้งค่า QoS ผู้ใช้อาจจะแสดงเป็นนับเฉพาะโปรแกรมประยุกต์เช่น "สูง", "กลาง" หรือที่มีคุณภาพ "ต่ำ" ในฐานะที่เป็นแอพลิเคชันจะทำให้การเปลี่ยนแปลงการไหลของรัฐที่ผู้ใช้อาจต้องการที่จะระบุ QoS เสถียรภาพเกณฑ์เช่น "ไม่เปลี่ยนการไหลของรัฐมากกว่าหนึ่งครั้งทุกนาที" โปรดทราบว่าเกณฑ์ที่ผ่านมานี้เป็นคำขอของผู้ใช้สำหรับการประยุกต์ใช้ไม่ได้ที่จะเปลี่ยนเป็น "ดี" ที่มีคุณภาพการไหลของรัฐบ่อยเกินไป (เช่นหลีกเลี่ยงการรัฐกระพือ) แต่ถ้า QoS ลดแล้วเราจะคาดหวังการประยุกต์ใช้ในการปรับตัวเป็น ต้อง. ความแตกต่างดังกล่าวหมายความว่าข้อมูลการตัดสินใจการปรับตัวสะท้อนให้เห็นถึงมุมมองต่ออินสแตนซ์ ดังนั้นข้อมูลที่ใช้โดยการประยุกต์ใช้ในการตัดสินใจในการปรับตัวควร: • . ไม่เกินควร จำกัด การทำแผนที่ QoS จากความต้องการของผู้ใช้ความสามารถในการประยุกต์ใช้• คล้อยตามการทำแผนที่ของการตั้งค่า QoS ผู้ใช้และ QoS เสถียรภาพเกณฑ์บนพื้นฐานต่อเช่นแอพลิเคชัน. 2.2 . ปฏิสัมพันธ์ระหว่างใบสมัครและเครือข่ายก่อนเช่นโปรแกรมที่สามารถตัดสินใจเกี่ยวกับการเปลี่ยนแปลงใด ๆ ในลักษณะการทำงานของมันก็ต้องรู้ว่าสิ่งที่ "เหมาะสม" สำหรับกระแสของมันคือสิ่งที่เชื่อมต่อเครือข่ายในปัจจุบันสามารถรองรับ นี้ต้องใช้ข้อมูลบางส่วนจากเครือข่าย ข้อมูลเกี่ยวกับเครือข่ายมักจะแสดงเป็นค่าของพารามิเตอร์ QoS เช่นความล่าช้ากระวนกระวายใจจุที่มีการสูญเสีย ฯลฯ ข้อมูลนี้อาจจะได้รับในหลายวิธี: • ผ่านกลไกท้องถิ่นเช่นจากกองการสื่อสารในพื้นที่• ผ่านกลไกเฉพาะโปรแกรมประยุกต์เช่นผ่านการส่งสัญญาณที่เป็นกรรมสิทธิ์. • เป็นข้อความการควบคุมจากเครื่องรับสัญญาณระยะไกลของการไหลเช่นใช้ RTP / RTCP [8]. • จากเครื่องมือในการจัดการเครือข่ายเช่นใช้ SNMP [9]. ถ้าเราพิจารณาว่า "โปรแกรมรู้ดีที่สุด" แล้วเราต้องขอขอบคุณที่มีแนวโน้มว่าจะไม่มีเดียว "ดีที่สุด" วิธีการแก้ปัญหาที่แพร่หลายสำหรับการรับข้อมูลเกี่ยวกับทรัพยากรภายในเครือข่าย "ดีที่สุด" กลไกอาจขึ้นอยู่กับสภาพแวดล้อมเครือข่ายหรือการทำงานของโปรแกรมประยุกต์หรือทั้งสองอย่าง แต่เพียงการประยุกต์ใช้ (ออกแบบประยุกต์ใช้) อยู่ในตำแหน่งที่จะทำให้การประเมินว่า. โปรแกรมนี้ยังต้องมีวิธีการแสดงความสามารถในการทำงานในแง่ของบางอย่าง การก่อสร้างของกระแสของตน IE ที่ไหลระบุกระแสของมันสามารถใช้ โดยปกติเหล่านี้จะมีขอบเขตการปฏิบัติงานที่กำหนดไว้ในแง่ของค่าพารามิเตอร์ QoS สำหรับการไหลของรัฐเช่นอัตราการส่งข้อมูลขั้นต่ำที่จำเป็นล่าช้าสูงสุด ฯลฯ โปรดทราบว่าเป็นความหมายของการไหลเป็นโปรแกรมเฉพาะเพื่อให้เป็นระยะเวลามากกว่าที่ วัดขอบเขตการปฏิบัติงานดังกล่าวจะวัด ซึ่งหมายความว่ารูปแบบของเราจะต้องมีความสามารถในการทำงานในสิ่งที่ระยะเวลาที่ระบุไว้โดยการประยุกต์ใช้