Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
*> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" rrroy@att.com *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting.
This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party?
Thanks,
Bob Braden
*> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
1/ please stop copying all the lists. most of us are on all of them
2/ this is a layering question and is clearly indpenenant of mapping qos at lower layers (if it isnt its severely broken) - its clear that diffserve and issll sit several layeres BELOW what you want to do and that the signaling mechanisms for both are indpeennsdat and much lower - i notice for example you dont include 802.1p and q - similar layer type stuff...
3/ the docs cited are telpeony specific EXTREMELY and in fact dont relate to results that show that people have broader tolerances than yo umight expect when using different ways to get voice around - while its reasoanble to have a subset of QoS parameters signaled fro mapps that are application specific, a better way to do it is through a profiling mechanisms, which has a code point scheme, that then uses more general means to signal the actual QoS parameters
4/ the IETF has several appropriate signaling protocol efforts and paramerter specification schemes...although i believe its not well architectured across all the layers right now and its not clear we have a profile mechansism/language/syntax/semantics
5/ there's the siglite discussio ngoing on and there was the bof to talk about new signaling protocols at the last IETF _ this seems to be somewhat ignoring that activity - is that intentional? if so why?
j.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Bob Braden -
Jon Crowcroft