Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this?

[<[e-mail]>]

Gorry,

the topic in general is relevant for IETF, I think. draft-carlberg
mentions that recently the RTP Media Congestion Avoidance Techniques
(rmcat) working group has been set up. It would be useful to understand
how draft-carlberg is related to the scope of the rmcat WG (e.g.
whether draft-carlberg only suggests a basic real time congestion
control mechanism and leaves all further work to rmcat).

Side-note: If congestion control is a chartered task of TSVWG, then there
might be a question whether there's an overlap ov TSVWG and rmcat.

Notes on the draft (in adddition to Bob's ones):

5.1.2 Differentiated Services

   As in the case of RSVP, applications could rely on the reception of CE
   feedback to initiate a subsequent setting of diff-serv code points to
   provide additional protection or explicit association of forwarding
   characteristics of a given flow of packets.  In addition, the setting of
   diff-serv code points would be done on an as-needed basis in reaction to
   CE feedback.  Recommendations concerning specific diff-serv values are
   outside the scope of this document.

It is common to use words like "DiffServ Codepoint" to mean "a QoS class"
(correct DiffServ wording "a PHB <-Group>"). The authors here want to
use an IP QoS class and should say so. There's no standard relation of
DiffServ Codepoints to IP QoS classes (PHB <-Groups>).

Apart from that, I wonder whether an application which had used class X
so far can instantly and seemlessly flip to class Y. Especially, if
there's an expectation of admission control features in a traffic
class, it won't be done with simply marking traffic differently.
Admission Control doesn't mean RSVP to me, it could be measurement
based as well. PCN defines and discussed relevant mechanisms. The
issue here is, that admissiion control is performed prior to setting
up a media session, whereas here, the authors seem to suggest to change
the class of a media session to avoid packet loss and queuing delay.

Regards,

Ruediger



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, October 19, 2012 2:49 PM
To: tsvwg
Cc: [e-mail]
Subject: [tsvwg] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this?

I'll update the status. I also changed the subject - so hopefully people
will see this draft and start to look at this.

I'm keen that we get some feedback from people, and then see this sort of
work progress.

Has anyone on the TSVWG list read this ....

- do people think we should be working on this topic at the IETF?
- what sort of recommendations are needed - and who needs these?
- do you have other ideas or experience that may be relevant?

Gorry

P.S. Ken let's discuss off-line with the co-chairs about the next steps.

> Hi Gorry,
>
> Thanks for sending the update out to the list.  just a couple of minor
> corrections on the following...
>
>> draft-carlberg-tsvwg-ecn-reactions
>> Reactions to Signaling from ECN Support for RTP/RTCP
>> -00 presented IETF-82
>> Not yet requested to become a work item.
>> - This draft is related to the new rmcat work.
>> DUE: Please comment on list.
>
> at past meetings, we've have made requests for the document to become a
> working group item.  However, at the same time, since its been a work in
> progress, we kept finding things to modify/update/clarify.  And while part
> of the draft is somewhat related to the new rmcat work, its more closely
> related to rfc-6679 (ECN for RTP over UDP).
>
> So if there are no objections or concerns, I'd like to make a request (on
> the list this time :-) to make this individual contribution into a working
> group document.
>
> cheers,
>
> -ken
>