Subject: [NSIS] RE: [Ieprep] proposed charter 5 priority levels

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 4 Oct 2006 16:08:57 -0400

Thought that it might be interesting in this WG as well ...

________________________________

From: Roy, Radhika R.
Sent: Tue 10/3/2006 9:58 AM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'; King, Kimberly S.
Subject: RE: [Ieprep] proposed charter 5 priority levels 

Posting again as it did no go through ... (Curtis: Kindly reply my mail even if it does not come out of the IETF reflector.)

Curtis:

Your explanation are OK. It is what we all like to see happen, but the standards are yet to be there from SIP point of view.

If we take the SIP call as an example, there are couple of steps involved to come to the point of actions in QOS that you have explained. The steps are as follows:

1.      SIP call has couple of priority levels. It is called call-level priority. That is, if there are the SIP call and the Web call and if the SIP call has the higher priority precedence that that of the Web call, SIP call will be treated with higher priority (even if pre-emption is allowed, Web call may even be pre-empted if needed). The QOS in dealing with the SIP will be maintained to transfer its call signaling message with proper QOS. How about the media payload that is supposed to be transferred once the call is established?

2.      Even if the SIP call is set up with proper maintaining proper QOS level, the SDP message field may contain one or more media. There is no standard how to map the SIP call-level priority to the media payload level priority. For example, there may be audio, video, and data sharing. Audio may have the highest priority and data sharing may be the second highest priority while video may have the lowest priority. If there is scarcity in bandwidth in the middle of the communication after a while, video or data may even be dropped. In summary, there is no IETF standard for mapping between the call SIP call-level priority to the SDP media level priority.

3.      With respect to RSVP, there is also not any standard in the IETF to map the SIP call-level priority to media payload level priority level attributes to the RSVP-level attributes. If someone can map all those QOS attributes of media payload to RSVP parameters, the rest is simple or there is at least some standard procedures for providing some-sort-of-QOS on end-to-end basis to maintain the application QOS, for example, as you have provided some pointers. (I am also skeptical here the way IETF NSIS WG is working for QOS signaling. The present NSIS QOS signaling in rather network-centric, NOT end-to-end application-centric. There is also a huge disconnect to satisfy the end-to-end application QOS.)

4.      For mapping the QOS from the VoIP call signaling to media payload attributes to RSVP QOS parameters, there is a complete standard available in the ITU-T SG16 for H.323 - done almost 8 years ago. But SIP is yet to do this standard.

I hope that you would now understand my concerns that just by saying that SIP priority levels are there and there is nothing but is simply like handwaving as if everything is in place and no work is needed in QOS to fill those gaps.

James P. has done a good amount of works for SIP priority levels. He and Henning S. may point more on this.

Sorry for the delayed response.

Best regards,

Radhika

________________________________

From: [email-masked] on behalf of Curtis Villamizar
Sent: Wed 9/27/2006 1:32 PM
To: Roy, Radhika R.
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; [email-masked]
Subject: Re: [Ieprep] proposed charter 5 priority levels 

In message <[email-masked]>
"Roy, Radhika R." writes:
> 
> 
> Can SIP priority level be mapped to media which is the main objective of
> QOS? If not, what help does it provide with respect to QOS?
> 
> RRR

Both SIP priority and DSCP are carried in the RSVP signaling (or NSIS
as Jerry pointed out).  This allows queues to be dynamically adjusted
if need be.

Only one DSCP marking is being proposed on the traffic itself so that
the SIP priority in the traffic itself cannot be distinguished.  This
is not regarded as a problem since the traffic is policed and the
reservation for this DSCP marking should assure zero drop as long as
the policing is effective.

This "one marking for all" scheme does preclude the use of highly
efficient multiplexing that might introduce limited loss to the lowest
priority traffic or allow all traffic classes to exceed their stated
allocation (ie: AF where marking is done at ingress, not policing).
This does not preclude multiplexing gains.  For example, many audio
encodings peak at 5-10 times their average BW.  This can be specified
in the peak, burst size, and average values in RSVP with the policers
and queuing set (dynamically if needed) to allow multiplexing but keep
loss at zero.

Worst case would still be a spike in delay.  For example consider
audio near a disaster scene.  An explosion could cause a spike in
audion on many senders.  There would be no loss per se but an increase
in delay that would exceed the playback jitter buffering and cause a
click and may move the jitter buffer out to a longer playback point.
If the playback buffer could not compensate, the audio playback of the
explosion would not be accurate, but that is probably the least of
anyone's worries in this scenario.  After the explosion audio would
return to normal.

Note that policers and queuing can be set dynamically or staticly.  If
set staticly then blocking would occur when limits were hit.  If the
ETS traffic is very small compared to the capacity of the network it
is running over then static may make sense, or just static queue
allocation in the network core.

I hope this thoroughly answered your question (and correctly too, if
not experts on this please jump in and correct me).  I'm learning too
but I think I'm coming up to speed.

Curtis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis