Roy, Radhika R, ALCTA rrroy at ATT.COM
Thu May 31 13:51:09 EDT 2001

Hi, Baker:

It appears that a good amount discussion can be started to answer your
questions (what has being discussed for the last couple of years in the
ITU-T and TIPHON in particular). I am not trying to do so. Let me answer
your questions summarizing the key points as follows:

1. Broadly, all applications can be considered in two categories: a.
Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g.,
data applications like file transfer, WWW, Mail, etc. - can a part of

The performance parameters of both real-time (audio, video) and
non-real-time (data) traffic can be abstracted in an universal way that can
be used by all applications (e.g., H.323, SIP, WWW, mail, etc).

However, the signaling messages used by each application are
application-specific although the QOS parameters used by all of them still
remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling
messages, SIP might use SDP).

The QOS signaling messages that use QOS parameters can be termed as the
application layer QOS signaling messages and are sent on end-to-end basis
and the values of those QOS parameters do not change no matter what may be
the underlying transport networks (e.g., IP, ATM).

2. The network layer QOS signaling messages carried over the network may not
be end-to-end significance. For example, an end-to-end path of an IP network
may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS
parameters may get translated between the source-destination path and may
not remain the same what has been negotiated on end-to-end basis in the
application layer (item 1).

The problems that are being addressed are as follows:

A. How to develop the end-to-end QOS signaling mechanisms in the application

B. How to relate the application layer QOS signaling to the network layer
QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one
consistency remain between the application and network layer QOS parameters.

Hope this may clarify some of your questions.

Best regards,
Radhika R. Roy

-----Original Message-----
From: Fred Baker [mailto:fred at cisco.com]
Sent: Thursday, May 31, 2001 1:09 PM
To: Roy, Radhika R, ALCTA
Cc: Bob Braden; gratta at lucent.com; sob at harvard.edu; mankin at isi.edu;
diffserv at ietf.org; iptel at lists.bell-labs.com; issll at mercury.lcs.mit.edu;
megaco at fore.com; sip at lists.bell-labs.com; sipping at ietf.org;
tsvwg at ietf.org; hiramatsu.yukio at lab.ntt.co.jp; rbuhrke at lucent.com;
tsg11q8 at ties.itu.ch; tsg11q9 at ties.itu.ch; ITU-SG16 at mailbag.cps.INTEL.COM

At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote:
 >All applications (e.g., H.323, SIP) uses signaling messages
 >among its functional entities (e.g., terminal, agents,
 >gatekeepers, proxies, gateways) for communications.

I'm not sure we're on the same planet. Please help me out here.

I can think of a few applications that have agents, gatekeepers, proxies,
and gateways, mostly resulting from the imposition of firewalls or
authentication systems, or from legacy applications like imitating the
telephone system in a data network. The only one that *requires* any kind
of gateway, to my knowledge, is H.323 teleconferencing, which represents a
paltry fraction of traffic according to most current measurements. Anything
else (75% of Internet traffic is http or FTP, most of the rest is mail, on
private LANs applications like NFS are pretty common, and even SIP can be
done without a gateway between consenting systems) could be hooked up in
separate systems on a LAN and made to work without any such signalling at

Could you be more specific on what QoS signalling is required by the world
wide web, mail, FTP, common ERP applications like ERP and PeopleSoft,
calendaring, and so on? If not, could you be more specific about what "all"
applications you have in mind?

And could you be more specific about what issues this proposal is
addressing that have not already been addressed in de facto standards and
deployed in operational systems? It would be very nice to understand what
you are preparing to ask vendors to do, and whether operators are
interested in deploying them.

This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
sip-implementors-request at cs.columbia.edu with "subscribe" in the body.

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

More information about the sg16-avd mailing list