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

[[e-mail]]

Hi Suresh, Andreas, Davide et al,

I have the feeling that you are not so far from each other, and that we are
here tackling a problem of terminology. So I will try to avoid the term
"QoS" even if this is QoS discussion.

First of all, you need to define the service and the ideal delivery
possibilities.
Just defining the service you are already defining quality parameters. For
example: the image on a screen in a cinema room is by far better than what
you can obtain at home with your television set. I'm already hearing the
answer: these are two different services.
In our case, I guess that, e.g., a voice service will not be defined with
the same parameters (e.g., bandwidth) than an audio music service that can
be compared to listen a CD at home. But the answer is the same as
previously: these are two different services.
Therefore, when you define a service, you need to determine which will be
the tools and related parameters to be used: codec, frames per second, etc.
This does not preclude to define the same service with several levels of
perception from the end-user (and therefore, using different codecs, etc.).

Once you defined the service in technical terms (codec, fps, etc.) you can
associate to it some Traffic Information, that is a description of what you
need in an ideal transport environment.

And finally, as reality is not always as wonderful as we can dream, you
need to indicate how sensible can be the stream to delays, jitter, loss,
etc., that is, you need to associate some Sensitivity Information.

These are also the reasons why we don't use the term "QoS parameter" in
draft-bos-mmusic-sdpng-qos-00, but Traffic Information and Sensitivity
Information.

All this information has to be shared/exchanged between users, service
providers, etc. maybe negotiated and finally agreed.
Once everybody is happy at the session/application level, you need to ask
your bearer level to reserve resources, setup connections, etc. and you
will surely use all or almost all this information to derive the
characteristics of the bearer you will request.

Obviously, I agree with the remark of Davide, you will negotiate at the
application level what you want to do, and next you will go down to the
bearer level to ask for resources to try to actually do what you already
agreed at the application level (maybe using NSIS protocol or any other
method).

Best regards,
Juan Carlos





"Mandato, Davide" <[e-mail]>@ietf.org on 15/03/2002 15:15:43

Sent by:  [e-mail]


To:   Suresh LEROY/BE/ALCATEL@ALCATEL
cc:   Andreas Kassler <[e-mail]>, Teodora Guenkova
       <[e-mail]>, [e-mail], Eisl Jochen
       <[e-mail]>
Subject:  Re: [MMUSIC] draft-guenkova-mmusic-e2enp-sdpng-00.txt


Dear Suresh


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

I guess Andreas meant that a given application-level QoS
defines the set of applicable codecs and their parameters.
In contrary, a given codec allows only to support a limited set
of application-level QoS.
And surely, application-level QoS specification has to be
media dependent.

>>> 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.

Again, this statement is correct, if we interpret a "service
provider" as a distributed multimedia service that provides
the user on an end-system with multimedia streaming services.
To this extent, we assume a "service provider" as an entity
that provides an "abstract service", whose QoS is defined by
a set of parameters. Such service provider offers its
service to a "service consumer", e.g. an user or an application.

For example, from a sheer application-level perspective,
we can model stream receivers as "service consumers" and
stream senders as "service providers".

From a system-wide perspective, though, the distributed
multimedia system itself as a whole can be seen as a "service
consumer" of more fine-grained services, for example a network
transmission service, a capture service, a compression service,
and so on.

A comprehensive QoS negotiation scheme thus involves 3 roles:
the negotiation initiator ("offerer"), the negotiation
responder ("answerer"), and the underlying service
provider.

The negotiation of application-level QoS is a business among
"offerer", "answerers", and the providers of services (e.g.
capture service, a compression service, etc.) available locally
at *all* of the end-peers.
Whereas the negotiation of QoS for the network traffic flows
is a business involving *in addition* the transport service
provider(s).

It is the task of the multimedia system to map user QoS
parameters into application-level QoS ones (e.g. frame rate,
frame size, visual quality).
Once the negotiation at application-level is completed, the
multimedia system maps the negotiated application-level QoS
into QoS parameters for the internal services that it uses, e.g.
the network transmission service. The negotiation of QoS for
the network traffic flows takes place and the reservation can
(eventually) be applied according to whatever mechanism is used
(eventually, the ultimate solution that will appear from the
NSIS work). Only at this point, the _transport_ service provider
comes into play.

Furthermore, a requirement for the E2ENP is to carry out
network reservations in a coordinated manner among end-peers,
to avoid that *network* resources (which, in a distributed system,
are those shared the most) are pointlessly reserved when the
end-peers themselves have not sufficient resources for carrying
out the given multimedia service.
This means that the end-to-end negotiation of capabilities and
application-level QoS among end-peers should take place in
combination, or even a priori, of the negotiation of QoS for
the network traffic flows, as well as of the network resource
reservation.
And the aforementioned requirement also means that the network
resource reservation process is the very last step in the session
establishment process.

Summing up: the user does not care about what codec is actually
used, as long as her/his requirements are satisfied.
However, when it comes to paying, knowledge about used bandwidth
may become an issue. Based on the codecs that have been agreed upon
during the capability negotiation, the multimedia system would
map the negotiated application-level QoS into traffic spec and
act as service user of the network transmission service provider,...

>>> 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)

You are absolutely right, that's what the _network_ service
provider cares all about.

>>> 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?

I guess Andreas meant that the agreement is "how much traffic
one sends over the network".

>>>
>>> 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.

Sure, we are completely on the same track. Nevertheless, there
is a need to coordinate application-level QoS and the QoS for
the network traffic flows.
That's what the E2ENP tries to help to achieve.
The E2ENP allows agreeing on capabilities and application-level QoS,
and then to proceed with agreeing on QoS for the network traffic
flows. But the latter is a business of NSIS or IntServ/RSVP, or
DiffServ.

Alternatively, the E2ENP also allows one using best effort services
only. Of course, in this case, since there is no reservation for
the QoS for the network traffic flows, the application QoS is likely
to suffer.

Kind Regards
Davide
________________________________________________________________

 Davide Mandato

 Principal Engineer                  <<mailto:[e-mail]>>
 Broadband Wireless Technologies Research (BWTR)
 Sony International (Europe) GmbH     Tel: [phone]
 Stuttgart Technology Center          Fax: [phone]

 Heinrich-Hertz-Str. 1
 70327 Stuttgart, Germany

  <http://www.sony.de>
  <http://www.sony-europe.com/>
______________________________________________________________


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




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