Hi Michael, On 16.10.2013 09:36, Michael Welzl wrote: > [I'm adding tsv-area: I noticed it was dropped from some part of this > thread, but I think unintentionally? BTW I hope tsv-area is appropriate, > and not tsvwg? I started off to rmcat and tsv-area because I had a > general DiffServ'ish question, yet related to rmcat, and so I thought > this would fit.]
Yes, I'm following this on TSVAREA since I'm not subscribed on rmcat yet. > ...then this someone (flow A) would be better off in the presence of > congestion, as described in the draft. This means that you'll never > decide for a profile as in Flow B in your application because you could > hurt yourself, you might be treated worse than some other users. > > This is what the normalizer fixes, but as long as you don't know it's > there, going for a profile as in Flow B is still risky business. > > "You" in my story here is the application programmer, and it really has > to be the application programmer doing this - the priorities would be > derived from knowledge about the codec, FEC usage etc. What the > application programmer needs is a signal that is definitely going to be > ignored unless it hits a normalizing ingress device. Just some few observations from my point of view: - DiffServ doesn't distinguish between individual flows within a behavior aggregate - it was intentionally designed that way. Per micro-flow unfairness within the same class is not prevented by DiffServ - conceptionally you should only use the first-hop router for this kind of traffic conditioning measures. However, this doesn't help to prevent other aggregation effects inside a DiffServ domain (cf. Per-Hop Behavior vs. Per Domain Behavior). - Following the end-to-end argument, it doesn't make sense to build somewhat complex mechanisms into the network, which may even depend on the particular application (like WebRTC etc.) - so building a "normalizer" (w/o having fully understood the concept) into the network doesn't seem to be the right approach in the long run. - Therefore, I agree very much with your last statement: it's only the application that has the knowledge and context to set any kind of forwarding priority (or drop precendence) for individual packets correctly. Especially, the logic to react on dropped packets should reflect the marking and corresponding dropping behavior. Regards, Roland
