Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
Hi, Bob:
You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP).
So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path.
This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer.
AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem.
Any contributions along this line will be highly appreciated.
Best regards, Radhika R. Roy AT&T
-----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain).
However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms.
Yes, the application layer is end-to-end. But does it traverse the exact same route as RTP transport layer? I don't think so, in that this is not IP. IP routes each packet individually with the right to change routes independently for each stream, and each packet in a stream. This is the basis for load balancing, overload control, and link failure survivability.
With this in mind, the application layer can negotiate an end-to-end QOS with the ends. It cannot control the intermediate routing nodes. A method is needed to accomplish the end-to-end QOS control via the RTP IP stream.
Bob
-------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan@ICN.Siemens.com -----------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
The application layer QOS should be an indication of the abstract quality and priority requirements or capabilities. This should really be called "Application Level Service Class" because it affects more than just the transpost level QOS mechanisms. It also affects Gatekeeper and Gateway behaviour.
This should be independent of the transport layer mechanisms.
The mapping of service class to transport level QOS and Gatekeeper and Gateway behavior is an implementation issue or is subject to service level agreements.
Gary
-------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom@delta-info.com Website: www.delta-info.com --------------------------------------------
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Roy, Radhika R, ALCTA Sent: Friday, June 01, 2001 9:44 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
Hi, Bob:
You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP).
So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path.
This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer.
AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem.
Any contributions along this line will be highly appreciated.
Best regards, Radhika R. Roy AT&T
-----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain).
However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms.
Yes, the application layer is end-to-end. But does it traverse the exact same route as RTP transport layer? I don't think so, in that this is not IP. IP routes each packet individually with the right to change routes independently for each stream, and each packet in a stream. This is the basis for load balancing, overload control, and link failure survivability.
With this in mind, the application layer can negotiate an end-to-end QOS with the ends. It cannot control the intermediate routing nodes. A method is needed to accomplish the end-to-end QOS control via the RTP IP stream.
Bob
-------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan@ICN.Siemens.com -----------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Gary Thom -
Roy, Radhika R, ALCTA