>>> - How do you motivate codecs to indicate packet priorities if they have to >>> fear that video flows with some packets marked "low priority" would >>> ultimately see more packets dropped than flows without any "low priority" >>> indications. For that we've got draft-lai-tsvwg-normalizer-02.txt >> >> Well, but here we're talking about a marking that only means "relative >> priority, within the same connection". So there shouldn't be any risk in >> setting low priority, really. > > But you need an intelligent dropping mechanism, and unless you would > do a per-flow subqueue, you could not do relative dropping relative within > the flow). And per-flow queuing is expensive. So our draft tries to explain a > scheme > that replaces per-floq queuing with per-flow priority remarking to allow > dropping in a common queue.
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... 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. Cheers, Michael
