Re: [tcpPrague] Draft L4S deliverables list

[Bob Briscoe <[e-mail]>]

Michael, Koen, all,

Could people give a URL for any open source code (or failing that, 
binaries). Then I will add a link to this list:
https://riteproject.eu/dctth/#code
In addition to Koen's list, you will see there a link to Mirja's TCP 
AccECN code.

It may not have been clear from what Koen said, but DCTCP as-is{Note 1} 
already "works" alongside Classic TCP on the public Internet with either 
of the AQMs Koen has implemented{Note 2}.
However, the definition of "works"  is currently good enough for 
performance and functional testing of DCTCP alongside Classic TCP, but 
not sufficient for full safety in all circumstances.
Items 3-1) to 3-7) address safety in the various specific cases described.

The phrase "TCP Prague" is being used for a (currently hypothetical) TCP 
that implements sufficient of these features to be safe for use on the 
public Internet.
One aim is for the IETF to determine which of these safety features are 
MUSTs, which are SHOULDs, etc.



Bob

{Note 1}: Tested with Linux and Windows versions of DCTCP
{Note 2}: With either Curvy RED or PI2 as the AQM for Classic traffic.


On 19/05/16 10:00, De Schepper, Koen (Nokia - BE) wrote:
>
> For the AQM part (2) we have running code. Our latest DualQ-PI2 
> supports both ect(0) and ect(1), doing classic ecn and L4S ecn 
> respectively (covering topic 1 from the network). For 3.1, MS Windows 
> has running code and we tested that it is responding correctly to drop 
> (we didn’t test FreeBSD). Maybe others have more implementations?
>
> Regards,
>
> Koen.
>
> *From:*tcpPrague [mailto:[e-mail]] *On Behalf Of 
> *Scharf, Michael (Nokia - DE)
> *Sent:* woensdag 18 mei 2016 19:34
> *To:* Bob Briscoe; TCP Prague List
> *Subject:* Re: [tcpPrague] Draft L4S deliverables list
>
> Is there running code?
>
> Thx
>
> Michael
>
> *From:*tcpPrague [mailto:[e-mail]] *On Behalf Of 
> *Bob Briscoe
> *Sent:* Wednesday, May 18, 2016 6:19 PM
> *To:* TCP Prague List
> *Subject:* [tcpPrague] Draft L4S deliverables list
>
> Folks,
>
> Here's the table of potential deliverables that I presented in Buenos 
> Aires. I've started to add volunteer's names.
> Pls continue...
>
> Each should probably be divided into implementation and drafting the 
> spec, but let's assume any volunteer will do both/either.
>
>
> 	
>
> *Description*
>
> 	
>
> *Draft(s)*
>
> 	
>
> *Volunteers*
>
> 	
>
> *Target WG*
>
> 1)
>
> 	
>
> L4S identifier
>
> 	
>
> draft-briscoe-tsvwg-ecn-l4s-id
>
> 	
>
> authors on draft
>
> 	
>
> tsvwg?
>
> 2)
>
> 	
>
> The DualQ AQM
>
> 	
>
> draft-briscoe-aqm-dualq-coupled
>
> 	
>
> authors on draft
>
> 	
>
> aqm?
>
>
> 	
> 	
> 	
> 	
>
> *3)*
>
> 	
>
> *Scalable Transport*
>
> 	
> 	
> 	
>
> 3-1)
>
> 	
>
> Fall back to Reno/Cubic on loss
>
> 	
> 	
> 	
>
> Linux / tcpm
>
> 3-2)
>
> 	
>
> TCP ECN Feedback
>
> 	
>
> draft-ietf-tcpm-accurate-ecn
>
> 	
>
> authors on draft
>
> 	
>
> tcpm
>
> 3-4)
>
> 	
>
> Scaling TCP's Congestion Window for Small Round Trip Times
>
> 	
> 	
>
> Bob Briscoe, Marcelo Bagnulo Braun
>
> 	
>
> tcpm?
>
> 3-5)
>
> 	
>
> Reduce TCP / SCTCP / TCP Prague RTT-dependence
>
> 	
> 	
> 	
>
> tcpm?
>
> 3-6)
>
> 	
>
> Smooth ECN feedback over flow's RTT, not RTT hard-coded for DC
>
> 	
> 	
> 	
>
> tcpm?
>
> 3-7)
>
> 	
>
> Fall back to Reno/Cubic if classic ECN bottleneck detected
>
> 	
> 	
> 	
>
> tcpm?
>
> 3-8)
>
> 	
>
> Faster-than-additive increase
>
> 	
> 	
>
> Marcelo
>
> 	
>
> tcpm?
>
> 3-9)
>
> 	
>
> Less drastic exit from slow-start
>
> 	
> 	
>
> Marcelo, Bob
>
> 	
>
> tcpm?
>
>
> 	
> 	
> 	
> 	
>
> 4)
>
> 	
>
> “TCP Prague” (for the Internet)
>
> 	
> 	
> 	
>
> tcpm?
>
> 5)
>
> 	
>
> DCTCP bis (for data centres - may be the same as TCP Prague)
>
> 	
>
> draft-ietf-tcpm-dctcp (bis)
>
> 	
> 	
>
> tcpm?
>
> 6)
>
> 	
>
> "SCTP Prague"
>
> 	
> 	
> 	
>
> tcpm/tsvwg?
>
> 7)
>
> 	
>
> “RMCAT Prague”
>
> 	
> 	
> 	
>
> rmcat?
>
>
> *Notes:
> *A line can be drawn somewhere around 3-7) to indicate that everything 
> above is an essential safety feature (preventing starvation etc), 
> while everything below (up to 3-9) is a performance improvement.
>
> 4,5,6) are essentially wrap-ups of the relevant elements from 3-1) to 
> 3-9) for each different transport
> 7) might require one draft for Nada, one for SCREAM, etc or it might 
> be possible to describe one simple delta for all RMCAT approaches.
>
> Whether we need all the bitty pieces 3-1) to 3-9) or whether we should 
> go straight for the wrap-up solutions, is up for discussion.
>
>
> Bob
>
> -- 
> ________________________________________________________________
> Bob Briscoe http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/