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 <[email protected]> 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
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
