Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL

From: Bob Braden <[email-masked]>
Date: Wed, 30 May 2001 23:39:17 GMT

*> From [email-masked]  Wed May 30 14:59:58 2001
  *> From: "Roy, Radhika R, ALCTA" <[email-masked]>
  *> To: [email-masked], [email-masked], [email-masked]
  *> Cc: [email-masked], [email-masked], [email-masked],
  *>    [email-masked], [email-masked], [email-masked], [email-masked],
  *>    Yukio Hiramatsu
  *> 	 <[email-masked]>, [email-masked],
  *>    [email-masked], [email-masked], [email-masked]
  *> 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.

_______________________________________________
Sipping mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sipping

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 02 Jun 2001 11:42:30 +0100

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.