[MMUSIC] SDP(ng)&QoS

[[e-mail]]

Hey all,

During the last IETF meeting there was a presentation given by Joerg Ott
on QoS extensions for the session description protocol.
The intention from the chair was to see if there is interest for the
MMUSIC wg to work on this topic, unfortunately there was no time for
discussion so lets try to do this via e-mail.
Below I tried to answer most of the questions mentioned at the end of
the 'SDP(ng) & QoS' as we really believe these type of extensions are
needed.
But before starting, when looking at the
draft-ietf-mmusic-sdpng-req-01.txt there is a explicit requirement for
QoS extensions in chapter "QoS-Parameters for different protocol domains
(e.g. traffic specification and flow specification or TOS bits for IP
QoS) need to be specified.". So it seems in the past this type of
discussion already took place and was agreed.


WHAT HAVE WE MISSED SO FAR?
If we look at what is currently being defined in SIP and SDP related to
QoS there are mainly two things:
1) The manyfolks draft allows to request the need for QoS provisioning
and the indication of success of reservation.
2) The media authorisation token allows the authorisation of the QoS for
the different media streams by providing a binding between the media
stream in the SDP and the QoS siganlling for the media streams.
What is still missing is the QoS information itself, which cannot always
be derived from media description in SDP!
The QoS information in the session description will be a valuable source
of information to base the actual QoS reservation on (e.g. RVSP, NSIS
protocol, ...).
Potential uses of the QoS extensions:
1. Synchronisation of the QoS in the different domains. Quality of
service will most probably be handled differently depending on the type
of access networks and backbone network.
2. Allows differentiation between the sessions (e.g. business vs private
sessions) and between type of subscribers (e.g. premium vs basic
subscription).
3. Allows end-users to negotiate in a flexible way the QoS they want for
each medium in the session prior to the QoS provisioning itself.
4. Facilitates the introduction of new codecs.
5. Allows to specify E2E QoS for media streams that are not associated
with a codec.
6. Input for the QoS provisioning protocols like e.g. RSVP or NSIS.
7. Service provider are more than just bit pipe providers (extra
revenues).
8. Service level admission control in the local access network and home
service provider.

DO WE NEED QOS INFORMATION BEYOND WHAT CAN BE DERIVED FROM THE CURRENT
SDP?
The only thing from which we can derive QoS information in the current
session description protocols is the codec itself (or the optional b=
parameter).
Here is already the first problem. Not all media are associated with a
codec! E.g. whiteboard applications. Not all the involved parties might
be aware of the QoS needed for new codecs (e.g. fancy downloadable
applications)
From the codec itself it is possible to derive traffic parameters like
e.g. peak-bandwidth, sustainable bandwidth,  packet size, ... as
normally one codec only corresponds with one traffic information set.
The parameters that define the level of perception by the end-users
cannot as such by derived from the codec. These 'QoS' parameters are
delay, delay variation, & packet loss ratio.  The set of QoS parameters
(called 'SI' sensitivity information in
draft-bos-mmusic-sdpng-qos-00.txt) allow the end-user and/or service
providers to differentiate among the sessions and each other.
Explicitly specifying the traffic information allows proper
authorisation of the media stream by the service providers without
having to know the codec itself.

WHERE WOULD THIS INFORMATION COME FROM?
First of all this information should be optional, it must be possible to
setup session without having to add QoS information to the session
description.
The QoS extensions can be added to the session description by either the
end-user or the service provider. The most obvious scenario is when the
end user specifies the QoS level. In case of roaming users both the
local access provider and the home service provider should be able to
check/modify the QoS.
Another scenario could be were the end-user doesn't specify anything but
for instance the service provider checks in the subscription profile
what level of QoS the end-user is allowed to use and adds this to the
session description.
If we look at draft-bos-mmusic-sdpng-qos-00.txt there are three
different ways to specify the Sensitivity information (e.g. delay,
jitter and packet loss ratio). The first one is the complete parameter
set, which implies you specify a value for every parameter. These values
are an indication of the upper bound for the parameters.
The second option is the use of standardised QoS classes. The QoS
classes need to be standardised by a recognised standardisation body
like IETF, ITU, ... so that they can be understood by all the parties
involved.
The last option mentioned in the draft is the use of QoS flavours. The
QoS flavour is just like QoS classes an abbreviated representation form
of the Sensitivity Information. The difference with QoS classes is that
they are defined by the service provider and as such only interpretable
by the end-user and his service provider.  Based on the destination
(other service provider) the service provider can translate the QoS
flavour to either the parameter or the QoS class representation form.

IS THERE A NEED TO SIGNAL THIS INBAND?
Adding QoS information to the session description is a logical choice.
First of all it is in the session description that the QoS information
can be linked to the specific media streams. If for instance the local
access provider cannot offer you bandwidths higher than 20 kbps this
will affect the choice of codec. Also per media stream more than one QoS
level could be suggested and together with the codec negotiation the QoS
negotiation takes place. The QoS information can be linked to the QoS
pre-conditions (manyfolks).
By signalling the QoS inband all the involved parties (e.g. local access
provider, service provider & end-hosts) are aware/involved in the QoS
negotiation.  Mechanisms at the session layer (e.g. SIP) as
record-route, offer-answer model, firewall traversal, etc are
automatically supported.
The QoS extensions are not used for QoS provisioning.


Regards,
    Suresh


_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic