[Bloat] [aqm] [iccrg] AQM deployment status?
Bob Briscoe
bob.briscoe at bt.com
Sat Sep 28 21:16:28 EDT 2013
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 at 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 at ietf.org
>https://www.ietf.org/mailman/listinfo/aqm
________________________________________________________________
Bob Briscoe, BT
More information about the Bloat
mailing list