Subject: RE: ATM extensions to SDP - QoS parameters be in there

From: "Schroeder, Tim" <[email-masked]>
Date: Tue, 15 Feb 2000 17:45:42 -0600

I would like to see the ATM QOS parameters in SDP.  I find the "advantages"
(your one hand, below) more compelling than the other hand.  I'm of the
opinion that a session description should contain enough information to (set
up, if necessary, and) use a bearer.  For ATM, the QOS parameters are needed
to set up the bearer, and therefore should be included.

Tim Schroeder

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, February 14, 2000 1:51 PM
To: [email-masked]'
Subject: ATM extensions to SDP - QoS parameters be in there

There is a small group of people working to extend SDP to describe
an ATM bearer.  For both MGCP and Megaco/H.248, SDP is the way to 
describe the characteristics of a bearer in a session, and if we 
want an ATM bearer, we need to do it with SDP.  In addition to the 
Media Gateway Control protocols, it would be nice if the same 
mechanism worked for SIP, which uses SDP for the same purpose.

A question has arisen which is architectural, and thus this message.
When you create an ATM connection, you specify addresses, and you
also specify QoS parameters.  The protocols that create the 
connections have both sets of parameters.  The question at hand
is, should SDP carry QoS parameters, as well as addresses and
bearer type (IP, ATM, ...)?  On the one hand:
	QoS is as much of a session specification as a codec choice
	It would be very expedient to have c= lines for the various 
		ATM QoS parameters because all users of SDP would then 
		be able to completely describe an ATM VC
	One (ATM) protocol is used to carry both sets of parameters,
		so why artificially split QoS and address info

On the other hand:
	We have shunted IP Qos to separate protocols -- IP QoS 
		parameters are not defined in SDP
	Generally speaking, QoS choices are made at one end, while 
		SDP is used primarily between peers to describe sessions

This issue may come up again in other contexts, so I'm soliciting 
advice from the larger group on this architectural question.

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:[email-masked]

---

From: Paul Sijben <[email-masked]>
Date: Wed, 16 Feb 2000 10:00:46 +0100

Tim,

I am of the same opinion. SDP describes what in some circles is known as
"bearers". In my opinion these bearers contain a description of the media
parameters, transport parameters and the associated QoS. 

So this does not imply that you copy all the ATM QoS parameters or the RSVP
paramters but you need to transport enough information to create them. Iin
the extreme, if the entities at both ends of the bearer discussion adhere
to the same policy that information may even be implicit. 

Paul

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Message:+31 208702874			
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

---

From: "Andreas Kassler" <[email-masked]>
Date: Wed, 16 Feb 2000 10:27:22 +0100

Hi,
may be I am wrong, but I would rather include a Generic
QoS specificatiobn into SDP and do somewhere the
mapping to ATM bearer QoS or RSVP type QoS
(RSopec, TSpec). The advantages would be
to be independent from the network with respect
to QoS parameters. The generic QoS spec
could be something similar to WinSock generic QoS spec, and
WinSock does then the mapping to ATM or RSVP.
Possible parameters coul encompass:

- service type (guaranteed, predicted, best-effort)
- Token Rate [Bps], specifies the permitted rate at which data can be
transmitted over the life of the flow
- Token Bucket Size [bytes], the maximum amount of credits a given direction
of a flow can accrue, regardless of time. In video applications,
TokenBucketSize will likely be the largest average frame size. In constant
rate applications, TokenBucketSize should be set to allow for small
variations
- Peak Bandwidth  [bps], The upper limit on time-based transmission
permission for a given flow, sometimes considered a burst limit
- Latency [ms], Maximum acceptable delay between transmission of a bit by
the sender and its receipt by one or more intended receivers. The precise
interpretation of this number depends on the level of guarantee specified in
the QOS request.
- Delay Variation [ms], difference between the maximum and minimum possible
delay a packet will experience. Applications use DelayVariation to determine
the amount of buffer space needed at the receiving end of the flow, in order
to restore the original data transmission pattern.
- Minimum Policed Size [bytes], specifies the minimum packet size for which
the requested quality of service will be provided.
- MaxSDUSize [bytes], specifies the maximum packet size permitted or used in
the traffic flow.

Regards, Andreas Kassler
-----------------------------------------------------------------------
 Andreas Kassler
 Department of Distributed Systems
 Oberer Eselsberg                              Phone: + 49 731/502-4139
 University of Ulm                             Fax  : + 49 731/502-4142
 D-89069 Ulm                      e-Mail: [email-masked]
 http://www-vs.informatik.uni-ulm.de/Mitarbeiter/Kassler/