Subject: [MMUSIC] Re: New draft on QoS extensions for SDPng

From: [email-masked]
Date: Fri, 01 Mar 2002 10:57:36 +0100

Hi Colin,

Thanks for the comments on the draft (draft-bos-mmusic-sdpng-qos-00.txt).

Inline are answers to some of your comments (in italics).

I also took the liberty to forward it on the MMUSIC list, just to try
to start a discussions in a wider audience.

>The scope of the draft seems to be somewhat wide, and I'm concerned
that it may be too wide. You might consider the effects of different >negotiation
schemes (e.g. what are the differences between SIP and RTSP negotiation)

The current version of the draft is indeed only showing the usage of
the QoS extension within SIP sessions. We are not  proposing new negotiation
mechanism but are relying on the existing mechanisms (e.g. manyfolks, offer/answer).
The negotiation examples are more to clarify why we need QoS extension
and to show how they could be used. Maybe we could agree that  for
the moment the main focus should be on the QoS extensions themselves and
not on the negotiation process, just to allow a quicker progress on this
topic. If there are changes to the existing negotiation processes in SIP,
RSTP, ... we have no problem with putting this in a separate draft.

>Is the QoS information part of the codec definition, a configuration
or a constraint.

This is a good point. In the draft we are only considering the QoS information
being part of the configuration part. It could however be useful to put
the TI (traffic information) set within the codec definition -static information-
and put  the SI (sensitivity information) sets in the configuration
part. Putting QoS information in the constraint part could be useful if
this for instance indicates a maximum allowable TI and SI configuration
(not codec specific). This could be useful information if for instance
the answerer is going to propose an better QoS (other codecs) than the
offerer was offering, this upgrade should not exceed what is specified
in the constraint.

>I'm also concerned about the interaction between the SDPng QoS and
proxies, gateways, and other middleboxes. There would seem to be the >potential
for problems if the QoS as expressed to the middlebox does not match that
that is negotiated by the endpoints.

I'm not sure I correctly understood this question. If the problem is
related to a possible mismatch between the QoS negotiated in SDP with the
QoS provisioned in the network for the session components (through middleboxes,
gateways, ...) then I would say this is covered by the preconditions mechanisms
(e.g. manyfolks). The QoS information carried in SDPng is a helpful tool
to determine the QoS that has to be provisioned in the network but is must
be independent of the actual QoS provisioning protocols.

> There are also extensive security concerns that are not addressed.

There are certainly security concerns related to the QoS negotiation.
However they are not different from the security concerns raised by other
SDP negotiation schemes (e.g. offer/answer model). So in other words the
security models applied to the existing negotiation schemes are applicable
and sufficient.

> Procedural point of view. Parameters must be appropriate and cover
the required range of scenarios. Do a requirements capture set with input
from the working group.

I fully agree with this, that's also why I forwarded this mail to the
list. The parameters we propose are chosen in this way that they are access
independent and as general as possible. Of course we are open to suggestions,
I don't know if you have some scenarios in mind. Could we use the parameters
as they are  in the draft as a kind of basis for discussion?

Regards,

Suresh

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