Hi Michael and all, Am 16.10.2013 10:49, schrieb Michael Welzl: >> - 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
Thanks for the pointer, I quickly read over it. My understanding is: if we have an example flow of AF41:AF42:AF43 80:20:0 the normalizer would reassign those packets to 40:20:20 (or whatever the configured proportion is). Is this perception correct? Regarding the e2e argument: - you said "it only says that whatever can be done in the application should be left up to the application" - I don't think this catches the gist of it: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible". => especially, application knowledge is often required when reacting on failures, i.e., the right decision cannot be made when implemented within the network. Thus, dropping packets according to the markings set by the application is fully in accordance with the e2e argument, whereas building marking mechanisms into the network that require application knowledge is usually not in accordance with it. - if I understood the normalizer proposal in draft-lai-tsvwg-normalizer-02 correctly, it is not in line with the e2e argument since it reassigns drop precedences without application knowledge. Thus, it may make the wrong decisions about the importance of packets, not knowing how apps react to loss. >> - 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... Thanks, I think I understand the rationale now. However, I see several potential problems with this approach and have some thoughts to share as well: 0) I think an application with a 40:20:20 assignment has no real problem if it experiences loss in PHBs AFx2, AFx3 since it was designed that way. Whether it's "unfair" w.r.t. to other streams doesn't really matter. Remember that QoS support is usually managed unfairness anyway. Fairness within AF usually matters for the "yellow" packets, e.g., AFx2. This excess bandwidth should be fairly shared among all streams in this AF class if possible. 1) reassignment of drop precedences w/o application knowledge 2) how can one find the right default proportions suitable for different streams or applications? 3) Is this AF PHB class restricted to forward this special kind of encoded video streams? If so, we already have the problem of knowing that this is actually the case in the particular DS domain/region... 4) Normalizing other (non video) streams within the same AF class may cause adverse effects to the application behavior. 5) Aggregation effects within a domain in interior nodes may cause a different proportion than what the normalizer is configured for. Thus the normalizer may not cause the desired effects for a whole domain. 6) The AF PHB group per se is difficult to handle, since drop precedences may be even inconsistenly configured within a DS domain or DS region (see RFC 2597, sec. 4 at the end: "Inconsistent discard behaviors lead to inconsistent end-to-end service semantics and limit the range of possible uses of the AF PHB in a multi-vendor environment."). Furthermore, packets of lowest drop precedence may suffer from packets with higher drop precedences waiting before them in the queue. 7) For an AF class you basically need a sort of admission control for the assured (let's say "green") AFx1 packets to guarantee the low loss probability. Every usage of excess bandwidth is purely optional for which the application must be prepared. Regards, Roland
