Mat,
At 11:56 22/10/2013, Matthew Ford wrote:
On 22 Oct 2013, at 00:40, Bob Briscoe <bob.bris...@bt.com> wrote:
> There's more to it - I've asked to present the whole story in Vancouver.
Cool, looking forward to it. I'll prime the question pump now if I may:
Does the transport need to know that it is connected to a network
that will signal ECN in this fashion?
Here's the outline of the talk I'm planning, that I sent to Martin
originally. Most of the second half addresses your question.
Exec summary
* Early tests show promise that we may have found a way to make the
ultra-low queuing delay of data centre TCP incrementally deployable
on the public Internet
* For rtcweb, we need to address
a) cc for r-t media [rmcat w-g in progress]
b) Making TCP nicer
c) minimise ability of TCP to bloat queues [AQM w-g now in progress]
This addresses b) & c)
The problem
* All AQMs delay dropping for about one (hard-coded) worst-case RTT,
in case a burst dissipates (allegedly a 'good queue' according to Van Jacobson)
* For a flow with 1/10 or 1/100 of this RTT (e.g. from a CDN or your
home media server), any congestion signal is delayed tens or hundreds
of its own RTTs by these AQMs.
* A TCP flow in slow-start doesn't need the burst smoothed anyway
- delaying the signal just makes slow-start overshoot more
- a TCP in slow-start knows that it won't allow the burst to
dissipate anyway
The solution: make ECN also mean "Immediate Congestion Notification"?
* For ECN-capable packets, shift the job of hiding bursts from network to host:
- the network signals ECN with no smoothing delay
- then the transport can hide bursts of ECN signals from itself
- the transport knows
o whether it's TCP or RTP etc,
o whether its in congestion avoidance or slow-start,
o and it knows its RTT,
o so it can know whether to respond immediately or to smooth the signals,
o and if so, over what time
- then short RTT flows can smooth the signals with only the delay
of their /own/ RTT
o so they can fill troughs and absorb peaks that longer RTT flows cannot
- a TCP only needs to smooth the signals if in congestion avoidance
o in slow start, it can respond immediately, thus reducing overshoot
Incremental Deployment:
* Immediate congestion notification doesn't need new AQM implementation
- it can use the widely implemented WRED algorithm with an
unexpected configuration
* The network classifies packets for this AQM treatment based on
their ECN-capability
- Without ECN, it smoothes the queue before signalling drops
- With ECN, it signals immediately, without any smoothing delay
- (as today, the operator can still use WRED with the Diffserv field too)
* For TCP apps, the stack will use 'DCTCP' (we've tweaked it), if the
ends negotiate ECN with the accurate feedback capability.
* It should 'just work' if an RTP app or a Reno TCP uses ECN.
The request:
* Much more evaluation to do, but first we want to know:
- if the idea works, would the IETF have an appetite for tweaking
the definition of ECN so it is merely equivalent to drop in the long
term, but the dynamics need not be equivalent.
Much better than the ECN that didn't get deployed
* This is Explicit and Immediate Congestion Notification (EICN?)
- same wire protocol, much greater benefits
* The advantage of the original ECN (avoiding congestive loss) was
too small to be worth the deployment hassle
* Predictable ultra-low latency without loss too (similar to
DCTCP-ECN) would be worth deploying
* But we all thought DCTCP could only be deployed in isolation (e.g.
data centres)
- we all thought DCTCP traffic would starve alongside today's TCP traffic
- because in a DCTCP queue, the ECN threshold is lower than you
would trigger drop
- and we thought ECN & drop had to be equivalent.
* We believe we've found a way to ensure DCTCP-ECN traffic doesn't starve
- we still make DCTCP-ECN equivalent to drop in the long-run, but
not in its dynamics
More info
A paper with early results is under submission (available on
request). It shows neither this approach nor legacy traffic can
starve the other under a wide range of conditions, but we have a lot
more work to test the limits.
Bob
Mat
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
