Re: [Bloat] [aqm] [iccrg] AQM deployment status?

[Bob Briscoe <bob.briscoe@bt.com>]

Mikael,

The shallow marking theshold is not the most significant feature of 
the AQM in DCTCP. More importantly, it does not delay congestion 
signals by averaging them over a period equivalent to a worst-case 
RTT (about 100ms), like all other AQMs do (RED, PIE, CoDel etc).

The shallow marking threshold certainly keeps standing queuing delay 
low. However, that's only under long-running constant conditions. 
During dynamics, not waiting a few hundred msec to respond to a 
change in the queue is what keeps the queuing delay predictably low. 
Dynamics are the norm, not constant conditions.

For instance, the AQM in DCTCP signals to a flow in slow-start as 
soon as it crosses the threshold. So a flow with 20ms RTT will get 
the signal in 20ms, and a flow with 3ms RTT will get the signal in 
3ms (e.g. to or from a CDN cache). Whereas all other AQMs will delay 
all signals for of the order of 100ms, even if the flow has a much 
shorter RTT (because all these other AQMs don't know the RTT of each 
flow, so they use a nominal worst-case RTT).

The source can use the signal as soon as it arrives (which it does at 
the end of slow-start), or it can smooth the signal itself (which it 
does once it's in congestion avoidance phase). But it can smooth the 
signal over its own RTT, rather than guessing a worst-case RTT.

CoDel taught us that the best line-rate auto-tuning an AQM can do is 
to use service time. DCTCP teaches us that the best RTT auto-tuning 
an AQM can do is /not/ to try to guess the RTT in the first place. 
Instead it is best to defer anything to do with RTT to the end-system.

We should learn from both lessons.



Bob

At 08:04 28/09/2013, Eggert, Lars wrote:
>Content-Language: en-US
>Content-Type: multipart/signed;
>         boundary="Apple-Mail=_19C08185-C4A7-46F5-925E-BA32C00EB99A";
>         protocol="application/pgp-signature"; micalg=pgp-sha1
>
>On Sep 28, 2013, at 9:01, Mikael Abrahamsson <swmike@swm.pp.se>
>  wrote:
> > So in datacenter one wants to start marking ECN on packets very 
> soon into buffer depth, hoping sender will get feedback and 
> throttle back the speed way before one gets taildrops?
>
>Yep. There have been a bunch of papers on datacenter TCP variants 
>recently (look through the last 2-3 years of SIGCOMM papers, all online.)
>
>Lars
>
>
>_______________________________________________
>aqm mailing list
>aqm@ietf.org
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT