Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG?

[<[e-mail]>]

Ken,

my expertise is with QoS. I side with Michael and Bob that your document is not very helpful if it is a list with possible maybe-measures how to deal with congestion for real time applications. As mentioned earlier, PCN offers mechanisms with a scope on real tim,e services at least. So just stating "remark to another DSCP" doesn't seem to bother to provide an argument as we've looked into PCN and don't think it's useful. A review of the state of the art to me seems to be the least a what a reader may expect. Take PCN as an example, there's more to review today if it comes to QoS.

Regards,

Rüdiger


[snip]


[Bob]
> On the other kitchen sink of responses (triggering RSVP, Diffserv, Redundancy, FEC etc), I'm with Michael W. If you're just listing what implementers might do, then it has little value. If you're recommending what implementers shouldn't do or what they should, it would be worth keeping these. But none of these other responses you list seem to be that prevalent, important or practical.

[Ken]
I think what is missing in those sections is more discussion about the pro's and con's of the various approaches.  For example, (a) the need for, and difficulty in achieving, transitive trust between nodes under different administrative control for diff-serv code points, or on the other hand (b) the added value of adding markings to packets that could influence downstream traffic engineering on an as-needed basis.  I prefer to stay away from recomendations because that can be entirely scenario and user-group specific.

[snip]