Subject: [MMUSIC] SDP(ng)&QoS

From: [email-masked]
Date: Fri, 05 Apr 2002 17:35:24 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Andreas Kassler" <[email-masked]>
Date: Wed, 10 Apr 2002 16:01:57 +0200

Hi,

also for me it is clear, that QoS extensions to SDPng are urgently needed.
However, it seems to me that discussion about QoS and capability negotiation
needs some coordination and extension. There are several drafts
floating around in MMUSIC and other areas that address QoS in the
one or other field. Also, there seems to be a misunderstanding,
what QoS means in which context. For example, some drafts consider
QoS negotiation only for network/transport layer parameters (e.g.
draft-bos-mmusic-sdpng-qos-00.txt). Other drafts (e.g.
draft-guenkova-mmusic-e2enp-sdpng-00.txt) focus on application
level QoS and let other areas (e.g. NSIS, manyfolks) concentrate on
the signalling of network/transport layer QoS.

Whereas the inclusion of QoS parameters at network/transport layer
seems to be a first step towards bringing QoS into SDPng (it has
been a requirement for the SDPng design), there is significant more
work to do. For example there has been a number of drafts (e.g.
draft-levin-sip-for-video-XX.txt) that have identified the need for
the following topics that deal with end-to-end QoS at application
level (inline with the proposals/requirements in
draft-guenkova-mmusic-e2enp-sdpng-00.txt):

- Ultimate goal should be to come to a solution to enable
SIP/SDP/SDPng/RTP/RTCP systems to provide real-time multimedia
services across global networks with quality video and audio that
delivers a satisfying and predictable end user experience.

- We should think about how SDPng can participate best to solve the
puzzle!

- We should be aware of the fact that during a session's lifetime,
the characteristics/capabilities of the endterminal may be changing
dynamically both as a result of network conditions, as a result of
mobility (different access network due to hand-off in multihomed
terminals) and as part of software reconfiguration (e.g. codec
download) and of terminal resource usage (e.g. starting of local
applications).

- Another point to consider is that typically a multimedia
application has to maintain many audio and video streams in
parallel. There are QoS requirements for a given stream (e.g. a
certain frame rate, frame size and visual quality), but there are
also QoS requirements between the stream (inter-stream
correlation/synchronization). These have to be negotiated as well.

-There has to be a mechanism to reference a given stream and change
its QoS characteristics, once the streaming has already started.
This has to be achieved without changing the codec. For example, if
a hand-over occurred and the network/transport QoS can no longer be
maintained, the user may want to switch from 20 fps to 15 fps for
the video stream. Referencing a stream within a multimedia session
also enables the negotiation of inter-stream QoS requirements.

-There has to be a mechanism to negotiate capabilities
independently from application level QoS. For video, certain codecs
may achieve the same application level QoS but the resource
requirements may differ.

- There has to be a mechanism to negotiate a set of valid
application QoS configurations, e.g. an adaptation path, that are
enforced in case a QoS violation occurred. For example start at (20
fps,CIF), switch to (15 fps,CIF), (10 fps,CIF), (10 fps,QCIF), (5
fps,QCIF),... This has to be achieved independently of any codec
decisions to provide mechanisms for dynamic codec download. To
minimize signalling traffic, there should be mechanisms to
reference such points within an Adaptation Path.

-There has to be a mechanism to specify a bandwidth range or a set
of Traffic parameters to a given codec. Video codecs can operate at
a broad range of target bandwidth sets. For each Traffic parameter
set, a number of alternative sensitivity (e.g. delay, jitter)
information should be supported. Also, video may complicate things
as for a given set of traffic parameters, many combinations of
application QoS parameters exist. For example, there are situations
where (15 fps,CIF) may result in the same amount of traffic as (30
fps,QCIF). When considering visual quality as another application
level QoS parameter, there are many more combinations possible.

-There should not be any restriction about what architecture to use
for network/transport resource signalling/provision at session
initiation time. Additionally, SIP signaling (together with SDPng
content) may take in general a different path than data.

-it is not desirable that intermediate nodes remove parts of the
original session description in mobile environments. Consider the
following example: Node A supports MPEG4 at 768 kBit/s and at 384
kBit/s. Let us assume that the terminal is multihomed and at the
moment uses UMTS and lets assume that 768 kBit/s are not supported
at the moment. If an intermediate node changes the session
description by removing the 768 kBit/s entry the peer B receiving
this information would have no knowledge that in principle Node A
could use 768 kBit/s based on Node As capabilities. If Node A
enters the building and dynamically switches to an inhouse W-LAN,
the 768 kBit/s would be no problem on an end-to-end basis, but the
peer B does not know it.

There are many more issues to consider when talking about real
end-to-end QoS. Currently, NSIS is targeting at a signalling
protocol for network/transport QoS. However, that is only half the
game. It is worth to look at negotiating and maintaining end-to-end
QoS at the application layer, that also has to include management
of local resources (which is out of scope of the MMUSIC WG).

I believe that extensions to SDPng together with SIP are a very
good solution to provide mechanisms to negotiate capabilities and
end-to-end QoS at application layer and coordinate this with
signalling for network/transport QoS (e.g. NSIS or IntServ or
whatever) even in a wireless and mobile environment. However, there
are significantly more issues to that than introducing only
traffic/sensitivity information in a session description.

It was the intention of draft-guenkova-mmusic-e2enp-sdpng-00.txt to
first fully understand requirements for SDPng to support QoS at
application layer in a mobile environment, before we start to draft
some solutions. However, in my opinion this discussion needs also
some coordination from the WG chairs on how to proceed. For example
to determine whether SDPng shall focus on application level QoS
negotiation (frame size, visual quality,...), and/or on
network/transport level QoS negotiation, and/or to negotiate *and
coordinate* both application and transport/network level QoS, in
order to provide a uniform QoS solution.

Regards,
    Andreas