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

["Mandato, Davide" <[e-mail]>]

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