Re: proposed charter 5 priority levels

In message <62D92A9A02BCC845B202323D49A48426E1CE7E@0591-ITS-EXMP02.us.saic.com>
"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