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

[<[e-mail]>]

Ken,

it's not relevant which QoS class is used in particular (EF or AF).
My comment didn't relate to a specific QoS class, it relates to QoS
usage in general.
The point is, it's not simply done by setting DiffServ codepoints
in all operational environments. All those where e.g. admission
control is applied will have a mechanism to decide whether an
additional flow can be admitted prior to remarking. This
mechanism must be addressed

You further assume that nothing like QoS aware routing is deployed
(i.e. you assume packets of a flow take the same path independant
of the DSCP). That holds today I guess, but it may not hold
in future.

Wireless 4G networks (on which I'm not an expert!) may neither
allow you to simply change DSCPs nor offer the same delay
properties in different traffic classes.

To sum up: simply changing DSCPs may help in a limited set of
operational environments. Your text should reflect that.

Regards,

Ruediger


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