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

[ken carlberg <[e-mail]>]

Ruediger.

Thanks for your comments.

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

ok, the previous email I sent out on whether the Reactions draft should be in TSVWG or RMCAT should address this point.

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

several thoughts had come to mind in writing the original text above that were to a degree scenario dependent.  if we're talking about interactive voice/video, one possibility existed in terms of adding EF to the packet when congestion was occuring and potentially incuring an additional "charge" for maintaining the minimal delay characteristics.  This was based on the assumption that the unmarked traffic was still being forwarded with acceptable end-to-end delays during non-persistant congested conditions.  Or, another possibility could be a switch from EF to the EF-admit code point to reflect the added admission control attribute associated with the flow/packet.

Another thought was to possibly use an AF code point for voice/video traffic that was associated with a non-interactive broadcast type of flow that could support a greater end-to-end delay while at the same time trying to minimize loss.  But as we stated in the text, we didn't want to focus on one particular recommendation because these may very per scenario and environment (e.g., public carrier/provider versus private LMR).

cheers,

-ken

ps, my comments to Bob's email will eventually hit the list.  I sent it from another email address, so it will have to be resent by the list monitor.  mea culpa.