Folks,
I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.
We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
If you don't know what all these buzzwords mean, pls read 'Background'
at the end first.
If you don't know what a Bar BoF is, see https://www.ietf.org/tao.html
At least two purposes:
i) Updates so everyone can see progress on design, implementation,
evaluation, specification of the different parts, who is working on what
etc.
Note: You might be working on, say, an improvement to DCTCP without
being motivated by all this L4S stuff, but it might be relevant.
ii) To discuss how best to standardise all the different parts
iii) Anything else? Perhaps interop testing, but it's probably too early
for that
Shout now, if you think this should be a real BoF, not just a Bar BoF,
cos the deadline for BoF proposals is about 11 hrs from now: UTC 23:59
2016-02-19 (Friday).
Also shout - either on or off list - if you have something relevant you
would like to present at item (i)
Regarding item (ii) on how best to standardise all this, we've been
talking with the Transport ADs and relevant WG chairs, and there are two
possible routes forward:
* Proposal #1: Standardise the pieces in their relevant existing WGs. Ie:
- the IP packet identifier for the L4S service in tsvwg, e.g.
<draft-briscoe-tsvwg-ecn-l4s-id
<https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id>>
- the AQM mechanism in the aqm wg, e.g.
<draft-briscoe-aqm-dualq-coupled
<https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled>>
- The essential TCP Prague requirements
<https://mailarchive.ietf.org/arch/msg/tcpprague/mwWncQg3egPd15FItYWiEvRDrvA>
in the tcpm wg (the essential requirements happen to all be applicable
to regular TCP congestion avoidance as well)
- The 'optional' TCP Prague requirements
<https://mailarchive.ietf.org/arch/msg/tcpprague/mwWncQg3egPd15FItYWiEvRDrvA>
(performance improvements) in perhaps the IRTF iccrg or tcpm, whichever
is most appropriate.
* Proposal #2: A new WG to do all the above.
Discuss!
*Background**
*Back in July'15, at the IETF AQM wg in Prague, we presented the DualQ
Coupled AQM. <draft-briscoe-aqm-dualq-coupled
<https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled>>
And we demonstrated it later that week at IETF bits-n-bites exhibition.
The message is, once you partition off the queuing delay of 'Classic'
TCP congestion control (Reno, Cubic, etc), it's really easy to get
ultra-low queueing delay with the family of TCPs that includes Data
Center TCP (DCTCP).
The DCTCP family is more aggressive, so normally they would starve a
Classic TCP flow. This coexistence problem is why it hasn't so far been
possible to release DCTCP on the public Internet.
The DualQ solves this coexistence problem. it is like a semi-permeable
membrane: it partitions delay, but flows share bandwidth across the
divide as if they are all the same type of TCP.
So, as a fortunate side-effect, DualQ also solves the problem of scaling
TCP throughput long term. {Note 1}
We are proposing that senders will identify packets for this new L4S
queue with the ECT(1) codepoint. <draft-briscoe-tsvwg-ecn-l4s-id
<https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id>>
We call the service offered by this new queue 'L4S' for 'Low Delay, Low
Loss, Scalable throughput'
DCTCP works OK as it is, but it will need some safety features. There
was a lot of energy in an ad hoc session in Prague back last July, which
produced a prioritised list, including performance improvements (see TCP
Prague Requirements
<https://mailarchive.ietf.org/arch/msg/tcpprague/mwWncQg3egPd15FItYWiEvRDrvA>)
but then everyonr went home, went on summer holidays, returned to their
day jobs and it all went quiet...
If you missed all the above, we've pulled together videos of demos,
short papers, I-Ds etc here: https://riteproject.eu/dctth/
Incuding this particularly useful 2-pager: “Ultra-Low Delay for All
<http://www.internetsociety.org/publications/ietf-journal-november-2015/ultra-low-delay-for-all>”
IETF Journal, Nov 2015.
Cheers
Bob Briscoe & Koen De Schepper
{Note 1} As the window scales, the number of congestion signals per RTT
remains the same, whereas with classic TCPs it gets smaller.
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
