[MMUSIC] SDP(ng)&QoS

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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic