Generally agree. That said, the Conex work has suggested that ECN marking or thresholds might operate differently depending on the DSCP. As a manufacturer/implementor, my comment is that all things are possible to him who doesn't have to do it. However, I "get" that for elastic traffic "congestion experienced" might be defined as "delay, or projected delay, exceeded some threshold", while for a class of real-time traffic it might be defined as "octet throughput rate within this class exceeds some threshold".
On Dec 6, 2013, at 7:22 AM, "Robinson, Dave C (Dave)" <[email protected]> wrote: > Jim et al, > > I agree with your comments on Diffserv. I'd go further and characterise > Diffserv as a business tool whereas ECN and general AQMs as network > optimisation tools. By that I mean that Diffserv should be used by an > application to specify a business policy be it low latency for VoIP / gaming > or preferred forwarding for your video service. AQMs can guess at the types > of traffic. For example an isochronous flow of short packets could well be > VoIP which would benefit from expedited forwarding. But it has to be an > operator policy to decide between two VoIP services. > > Same argument for bulk traffic from different video services. One can be a > partner traffic from your internal CDN nodes which you would like to > accelerate through your network. > > ECN is a good tools to use to tell sources the the network is becoming > overloaded and is kinder than dropping packets. But it cannot know the > business policy. Just help manage congestion. > > Regards > Dave > > Sent from my iPad > > On 5 Dec 2013, at 19:50, Jim Gettys <[email protected]> wrote: > >> >> >> >> On Thu, Dec 5, 2013 at 1:13 PM, Bob Briscoe <[email protected]> wrote: >> Fred, Gorry, all, >> >> I promised to suggest text for draft-ietf-aqm-recommendation about allowing >> the AQM's behaviour to be independent for ECN and non-ECN packets. In the >> process, I realised we can't talk about independent AQMs for ECN without >> also including Diffserv. >> >> This gets messy, because I believe a good AQM for BE traffic with and >> without ECN, should remove much if not all the need for Diffserv. But we >> can't ignore Diffserv. >> >> I agree in principle with what Bob is trying to say here (and is very much >> what I've been saying in my blog entry of last summer). >> >> Once you have things under control, the need for Diffserv diminishes >> dramatically (but does not go away). >> >> But as Bob notes, there is still a good use for Diffserv: suitably marked >> traffic may want to contend for access to the channel differently: your >> marked VOIP packets may want to change the priority with which you request >> channel access, so that you get more timely access to the medium. This >> conserves transmit opportunities, which is often the scarcest resource in >> many systems (e.g. 802.11, DOCSIS, etc.). This can be the difference between >> your VOIP working well, and not working well, on a busy 802.11 network as >> well as using the channel as efficiently as possible. >> >> Similarly, if you have packets you know are background, it's helpful to know >> that to ensure that they never contend for access to the medium but will >> always defer to other traffic, and just scavenge available space in other >> transmit opportunities where possible. >> >> I'm a bit loathe though to tie the behavior to queues, however; in >> particular, best effort traffic may want to be sent in the same aggregate as >> higher (or lower) priority traffic, if there is remaining space in the >> aggregate. >> >> In short, the mental model we've had that there is a one-to-one model of >> hardware and software queues (not to mention flows in a given software >> queue) is often incorrect (or at least seriously sub-optimal) in today's >> systems (even if the hardware queues "work" properly, which it appears they >> do not in 802.11). >> >> So I'm not sure Bob's new section 3 here is how to best to state this (or to >> deal with the terminology problem). Certainly, it may be the same instance >> of an AQM algorithm, rather than different instances, for example. And " It >> SHOULD be possible" is more a pious wish than anything else. But I agree in >> spirit with what Bob's trying to say. >> - Jim >> >> >> _________________________________________________________________________________________ >> {In Section 4: add another bullet between recommendations 2 & 3:} >> >> 3{New}. It SHOULD be possible to make different instances of an AQM >> algorithm apply to different subsets of packets that share the same queue. >> It SHOULD be possible to classify packets into these subsets at least by ECN >> codepoint [RFC3168] and Diffserv codepoint [RFC2474] (or the equivalent of >> these fields at lower layers). >> >> {Then a new section to expand on this before the current Section 4.3.} >> 4.3{New}. Independent AQM Instances for ECN and Diffserv >> >> The recommendation to provide a separate instance of the AQM for ECN packets >> goes beyond the assumptions of RFC 3168, which assumed that only one >> instance of an AQM will handle both ECN-capable and non-ECN-capable packets. >> >> >> >> Bob >> >> >> >> ________________________________________________________________ >> Bob Briscoe, BT >> _______________________________________________ >> aqm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/aqm >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
