... and RFC 4774 describes how ECN interpretation can change based on DSCP.
Gorry On 06/12/2013 15:51, Fred Baker (fred) wrote:
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] <mailto:[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] <mailto:[email protected]>> wrote:On Thu, Dec 5, 2013 at 1:13 PM, Bob Briscoe <[email protected] <mailto:[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] <mailto:[email protected]> https://www.ietf.org/mailman/__listinfo/aqm <https://www.ietf.org/mailman/listinfo/aqm>
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
