Subject: [aqm] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)?

From: Bob Briscoe <[email-masked]>
Date: Fri, 19 Feb 2016 13:28:09 +0000

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/

---

From: John Leslie <[email-masked]>
Date: Fri, 19 Feb 2016 13:23:59 -0500

> DualQ and solutions to the TCP Prague Requirements.

   This feels like it belongs as a non-WG-forming formal BoF.

   It describes work spanning at least three WGs; and could benefit from
formal scheduling to avoid conflicts with those WGs and others.

   OTOH, it really isn't to the point where a WG charter can reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

   However this may turn out, I wish to participate remotely.

--
John Leslie <[email-masked]>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 22 Feb 2016 08:54:09 +0000

John,

>     However this may turn out, I wish to participate remotely.
OK, we'll see if the secretariat can help us with that.
Unfortunately we ran out of time for the formal BoF deadline on Friday.

Bob

> _______________________________________________
> tcpPrague mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpprague

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 22 Feb 2016 11:21:24 -0600

Just to try to be helpful ...

> OK, we'll see if the secretariat can help us with that.

I believe that happens at http://www.ietf.org/meeting/amreq.html. If you
put "TSV" in as "type of meeting", your happy TSV ADs would see the request.

Thanks,

Spencer