On Tue, Oct 15, 2013 at 10:06:32AM +0200, Michael Welzl wrote:
> So now I finally read http://tools.ietf.org/html/draft-lai-tsvwg-normalizer
> and I must say I like it a lot! It is indeed exactly what we need - but one
> issue with it is compatibility. Actually this could become a show-stopper, as
> this is all about getting the incentives right: why would my application
> ever set a higher drop precedence for some packets when I don't know if this
> normalizer is in place or not? And this decision would have to be taken by
> the application...
if we wouldn't try to stadardize this behavior with DSCP marking but only with
RTP markings then that definition could also include the clear requirement
that network devices MUST NOT interpret these markings in a way that
would penalize a flow against other flows with no or differnt markings. Aka:
clear state that these are intra-flow priority markings and must be interpreted
by the network as such.
> I could imagine a scenario where an application inserts the RTP extension
> header that you mentioned, and then a flow-aware edge device which knows that
> this traffic is going to traverse a path where your normalization marker is
> in place marks packets into an AFx PHB group based on the RTP extension
> header. Then we have an architecture that is incentive-compatible AND scales.
Right.
Cheers
Toerless
