On 16. okt. 2013, at 10:21, Bless, Roland (TM) wrote: > 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.
... and dropping tsv-area was a mistake, as your message shows :( 'cause we've been around this block I think... >> ...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). Sure- > - 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. I disagree with what you say about e2e, see: http://www.ietf.org/mail-archive/web/rmcat/current/msg00519.html but anyway that's a separate debate, as the normalizer draft works on aggregates and is really compliant with DiffServ as far as I can tell. That's the draft we're debating here: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02 > - 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. Yeah, the issue we're debating is that an application won't have an incentive to go for the profile of Flow B (page 4 of the draft) unless it knows that the normalizer is there, because otherwise it could get treated in the normal DiffServ way and that would make it worse off than Flow A (page 4 of the draft). Thus you need a way for the application to signal intra-flow packet priorities to an edge without "standard DiffServ" operating on that signal. The signal must be ignored unless the normalizer is there. I hope that helped to clarify the discussion a bit... Cheers, Michael
