Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

[Simon Barber <[e-mail]>]

I've been looking at all the recommended DSCPs recently. CS1 is 
explicitly mentioned as 'low priority'. The AF1 class might also work 
well for 'background' or 'bulk' traffic. Reading RFC4594 it's 
recommended for high throughput applications, and all the applications 
described don't seem to have any interactive, or very time sensitive 
component. This to me means it's more of a background queue. The code 
points are 10, 12 & 14 (for AF11, AF12 and AF13).

Simon

On 5/18/2015 10:52 AM, Jonathan Morton wrote:
>> On 18 May, 2015, at 20:18, Dave Taht <[e-mail]> wrote:
>>
>> Since dart I have basically come to the conclusion we need at least
>> one new diffserv priority class for scavaging traffic.
> Scavenging traffic is, of course, the rationale behind assigning CS1 to the background class (which has lower priority than best-effort) in Cake.  If another DSCP is recommended in future for this purpose, it would be straightforward to assign that to the background class as well.  Something in the 000xxx range might be more compatible with legacy equipment.
>
> I’m therefore disappointed that existing recommendations for practical Diffserv deployment ignore the Low Priority class.
>
> But it’s important to note that assigning traffic to separate queues - whether by FQ or Diffserv - only matters at bottlenecks.  Even if there is legacy equipment on the path that happens to interpret CS1 as “elevated priority”, it will have no effect if that isn’t a bottleneck link.  Likewise, AQM only makes a difference at a bottleneck.
>
> It may be worthwhile to emphasise that deployment of AQM should be prioritised on links which are regularly saturated (on timescales of seconds, not minutes).  Over-provisioned links can usually look after themselves, as well as probably presenting the most difficult technical challenge to implementing good AQM.  Saturated links are usually slow enough (10Gbps and down) for AQM implementation to be a tractable problem, even in software.  The most visible problems are usually at or near the last mile, which so far is 1Gbps and down, with the most important deployment locations involving 100Mbps and under.  In fact, the lower the bandwidth of the link, the more important *and* the easier the implementation and deployment of good AQM.
>
> For most traffic patterns, Diffserv isn’t even necessary.  The combination of AQM and FQ does an excellent job - *unless* there is a saturating application that uses many flows.  In that case, FQ ends up giving that application a large share of the bandwidth, and can starve latency-sensitive applications that use only one flow.  It is that scenario - which is exercised by the likes of BitTorrent - which convinced me to add Diffserv support to Cake.  Then, whether the latency-sensitive application sets a high-priority DSCP or the many-flows saturator sets CS1 (or, preferably, both), the problem is resolved satisfactorily.
>
>   - Jonathan Morton
>