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

[[e-mail]]

Hi Andreas,


Before going into details there are still some things that are unclear to me
reading your mail.

You say that application-QoS is not codec specific but media dependent, correct?

The QoS contract between service user and a service provider specifies
applications-QoS requirements and contraints, correct?
If the previous statements are correct, this would mean I can use a very
high-bandwidth with e.g. 20fps or the newest lowbandwidth codec also at 20 fps
and in both cases it would be compliant with my QoS contract although in the
first case I'm consuming N times more resources.

If I were an provider I wouldn't care about the codec used or the frame-rate,
what interests me are the resources this users is going to use (the traffic QoS)

I your mail you state "The provider simply does not care, if I send video at 20
fps or at 5 fps as long as I comply to my agreement." What is exactly this
agreement?

But don't understand me wrongly I think the application-qos is very useful data
(especially 'only?' for the end-users). However in my opinion we need both
application and traffic QoS.

Regards,
    Suresh




Andreas Kassler wrote:

> 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