Re: [MMUSIC] draft-guenkova-mmusic-e2enp-sdpng-00.txt

["Andreas Kassler" <[e-mail]>]

Hi,
first of all I would like to thank you for your valuable comments on our
draft. However, I think there is some slight misunderstanding.
>
> I'm reading your draft with great interest as it is very related with
> draft-bos-mmusic-sdpng-qos-00.
> Below are some first quick remarks/questions. I hope this can start a
> fruitful discussion.
>
> Under QoS parameters you also put parameters like video frame rate,
> sampling rate, ... .
> This parameters are indeed interesting and affect the QoS level as
> perceived by the end-users. However the transport level should be
> completely service independent (doesn't care if the IP packets carry
> audio or video). Therefor we consider this to be more codec related
> information than true QoS information. If a user wants a higher video
> frame rate this will automatically result in a higher bitrate, etc. The

This is not true in all cases, for example, if the user increases frame rate
and switches to
a more efficient codec, the bitrate may not increase. Also, if the user
decreases visual
quality, the bitrate may decrease even if the frame rate is increased.


> QoS information should be general enough to be used in access and
> backbone networks and be service independent (meaning independent the
> same for audio, video, ...  streams). Putting codec specific information
> as frame rate, etc endangers the service independence, as with the
> development of new codecs you might be forced to add new parameters. So
> to conclude the extra information you mention is useful but should be
> considered as codec information not QoS information.



When talking about QoS we have to first define what we mean. There are
many definitions around, and the most well known is the definition of QoS
for
network traffic what you are relating to. However, QoS
end-to-end  encompasses more than just network ressource negotiation and
management. We see QoS according to the definition of ITU-T Rec.800:
"The collective effect of service performance which determines the degree
of satisfaction of a user for this service". In the sense of SDPng we see
service
as a ditributed multimedia service,  whos QoS is defined by a set of QoS
parameters.
In that sense the user defines the QoS of the distributed multimedia
service,
e.g. a VoIP session or a Video Telephony session. We have then to think
about
characteristics that  describe the performance of such a multimedia service.
Clearly, network transmission service is just a part of it and we do _not_
focus
on this within SDPng. In contrast, we are interested in negotiating QoS as
the
user of a multimedia service wants to achieve it in an end-to-end fashion
(i.e. between a sender of a media stream and between a receiver of a media
stream).

 Therefore:
 - QoS provisioning and management for traffic flows is necessary to achieve
 e-2-2 QoS for a multimedia service (in this mail also referred as
APPLICATION  LEVEL QOS) but NOT sufficient.

 - Capability information, furthermore, does not capture the user QoS
expectations/requirements, merely hw/sw configurations. This is an
orthogonal
problem. The application level QoS dictates what codecs are applicable to
achieve the QoS. For example, one cannot provide CD quality audio with a
GSM codec. On the other hand, the terminal capabilities determine the set
of QoS levels that can be offered to a user. If there is only a GSM codec,
CD quality audio cannot be offered. Since we assume application level QoS
is derived from user requirements/expectations, and not from codec
configuration,
the parameters we proposed (frame-rate, etc) do NOT depend on type of codec,
but on the type of media and the way we expect users perceiving QoS for
that type of media.

 - the e2enp is a general protocol, that can be mapped on any session layer
protocol, e.g. SIP. The purpose is to  negotiate capabilities and QoS for a
multimedia session. QoS here means _not_ QoS for the traffic flow. This
would be
subject to IntServ/DiffServ or NSIS.

 - the e2enp is complementary to any work being done in NSIS: at a later
time, we might envision some form of liaison between MMUSIC and NSIS.
Then, capabilities and QoS at application level may be negotiated with
SIP/SDPng,
a mapping to IP traffic specification is necessary that may then be used
as input for NSIS.

 - the e2enp is genaral enough to allow applications to adapt to QoS
violations at the transport layer even without using network reservation
mechanisms !
A cheap and effective way of handling QoS violations.

 - if two peers cannot agree on application level QoS AND capabilities, they
can not derive realistic amount of network resources to reserve.

 - in our model, if during a negotiation the receiver proposes  appl-level
QoS and Capabilities for a given stream (or group thereof), is the sender,
who can derive network level QoS  parameters and use them for NSIS or
RSVP reservations, or for DiffServ marking. If the sender itself proposes
to a receiver to send a stream with a certain appl-level QoS and
Capabilities, it can well do the same as indicated above, but only after
having received the answer from the receiver,  in order to refine the
estimated
amount of network resources to reserve, BEFORE ANY RESOURCE
RESERVATION IS COMMITTED. Furthermore, the e2enp allows
making plans, i.e. to negotiate alternative appl-level QoS and Capabilities
 - and not just one instance thereof - a priori of any actual network
 reservation.

 - The amount of network resources required by a sender can depend not only
on the hw/sw characteristics of capabilities and network,  but also on the
current
load of BOTH peers' terminals AND network. Therefore, the appl-level QoS
and Capabilities negotiation allows agreeing on a set of alternative QoS
targets,
which can then  be mapped at real-time to the actual environmental
 conditions.

 - The drafts of Bos e.a. do not take into account interstream QoS
 constraints (e.g. lipsync)

 Hopefully, we have clarified some issues. If you see some further
requirements we should add, please let me know.


>
> Section 6 related work:
> "The authors of [5] suggest that some IMs along the negotiation path may
> influence the negotiation, though in general having nothing to do with
> the data. According to such a protocol model the network is not
> transparent."
> It is true that some of the IMs along the path have nothing to do with
> the data (e.g. 'home' service provider in roaming scenarios). However
> the end-users service provider is the one with which the end-user has a
> QoS contract. Therefor your service providers IMs should be able to
> modify the QoS requested by the end-users even though data doesn't
> traverse his network. The model we used in our draft is: the end-user
> has a QoS contract with his service provider. The service provider on
> his turn has agreements with the access/transport providers. So
> according to me this makes the protocol very network transparent.

You are again right, when you talk only about QoS for traffic streams.
However,
the provider simply does not care, if I send video at 20 fps or at 5 fps as
long I comply to my agreement. However, for me, the application, is crucial
to get the 20 fps to the other end.

> In section 3 first bullet point, you state "A QoS contract shall capture
> user's QoS expectations, as well as network provider policies .... (this
> means for instance to control that the QoS levels fit into the
> predefined policies, or to control the amount of resources by
> up-/downgrading QoS upon detection of QoS changes/QoS violations)".
> Isn't this in fact also demanding that IMs outside the data path can
> influence the QoS? Is the network provider the same as the service
> provider?

I agree that IMs outside the data path may influence QoS for traffic flows.
However, they do not care about QoS as the user wants to perceive it.
The application/multimedia management system has to find a balance
between _user_ or _application QoS, the capabilities of the local and
peer system and the network QoS that the provider offers for the traffic
flow.
Our suggestion for E2ENP goes exactly in that direction. Find an agreement
on what capabilities can be used and what QoS at _application_ level is
required in terms of frame rate, visual quality,... Find agreement on
backoff
solutions in case of ressource shortage. Proceed with network QoS
negotiation
(using RSVP or NSIS or ... nothing at all) and there you go.

Regards, Andreas

>
> Regards,
>     Suresh
>
> Teodora Guenkova wrote:
>
> > Dear MMUSIC WG Folks,
> >
> > we have submitted draft-guenkova-mmusic-e2enp-sdpng-00.txt, that
> > should appear in the archives soon. Until it does, it is available
> > from:
> >
> > http:
> >
/www-vs.informatik.uni-ulm.de/ietf/mmusic/sdp-ng/drafts/draft-guenkova-mmusi
c-e2enp-sdpng-00.txt
> >
> > This document takes inspiration from
> > draft-ietf-mmusic-sdpng-trans-00.txt
> > and analyzes issues for providing both sedentary and
> > mobile users of multiparty, multimedia communication services
> > with efficient mechanisms for coping with unstable network
> > conditions and limited resource availability, conforming to the
> > users' QoS requirements and expectations. To this extent, the
> > concept of a comprehensive and efficient end-to-end QoS signaling
> > mechanism is needed, dealing not only with capabilities/QoS
> > negotiation, but
> > also with efficient re-negotiations and coordinated resource
> > management. Requirements of a protocol (thereinafter, the
> > "End-to-End Negotiation Protocol" - E2ENP), as well as a
> > possible implementation thereof, based on extensions of SDPng
> > and on the use of SIP, are then discussed. Finally, differences
> > and/or synergies with existing solutions and proposals
> > (especially with draft-bos-mmusic-sdpng-qos-00.txt and
> > draft-bos-mmusic-sdpqos-framework-00.txt), as well as security
> > considerations, are provided.
> >
> > Regards,
> > --
> > -----------------------------------------
> > Teodora Guenkova-Luy
> > Dept. Distributed Systems, University of Ulm,
> > Oberer Eselsberg, 89069 Ulm, Germany
> >
> > Tel.: [phone]
> > FAX: [phone]
> >
> > e-Mail: [e-mail]
> > -----------------------------------------
> >
>


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