Subject: [tsvwg] Does L4S requirement to use RACK prohibit running code?

From: Bob Briscoe <[email-masked]>
Date: Thu, 1 Nov 2018 16:47:01 +0000

David,

Repeating the question, but cc'ing list as agreed...

-------- Forwarded Message --------
Subject: 	Re: [tsvwg] Planning for TSVWG in Bangkok - please speak to 
chairs if you think it would help to make a presentation
Date: 	Thu, 1 Nov 2018 13:33:48 +0000
From: 	Bob Briscoe <[email-masked]>
To: 	Black, David <[email-masked]>, [email-masked] 
<[email-masked]>, Wesley Eddy <[email-masked]>
CC: 	De Schepper, Koen (Koen) <[email-masked]>, marcelo 
bagnulo braun <[email-masked]>

David,

Regarding your point that [by adding the RACK requirement 
<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-03#section-2.4.1>] 
we are prohibiting a lot of running L4 code (e.g. DCTCP) from using L4S, 
I think there are two cases (tell me if another one is in your mind). I 
can certainly raise these during the meeting:

  * On the public Internet, the IETF will require L4S traffic to comply
    with the 'TCP Prague Requirements', but we mention (and therefore
    implicitly bless) initial trials with straight DCTCP. The lack of
    support in a lot of running transport layer code for any of the
    Prague requirements is no different to its lack of support for the
    RACK requirement. It's an aberration that we expect to be temporary.
  * In controlled environments, a transport complying with the 'TCP
    Prague Requirements', including the RACK requirement, might be
    ideal. However, we recognize that admins can more readily juggle
    host and network requirements than the IETF can. So, they might
    start off without RACK in the hosts, and only introduce it when they
    want to take advantage of it on links.

Have I understood your concern correctly?

Bob

On 29/10/2018 13:03, Black, David wrote:
>
> Bob,
>
> We do need to discuss the RACK/ordering/link design implications in 
> TSVWG, to the extent that we can, as prohibiting a lot of running 
> transport protocol code from using the low latency L4S service is not 
> something to be done lightly.  Thanks for relaying your acceptance of 
> a speaking slot in the Saturday-after-IETF IEEE 802/IETF 
> Transport/Congestion workshop - that should be a good opportunity to 
> talk to link designers, at least for Ethernet.
>
> The WGLC on the two ECN encapsulation drafts misfired, due in part to 
> my not paying enough attention (increasing demands on my time from the 
> day job are a contributing factor, but not an excuse).   Please submit 
> a version bump of the expired draft so that we can try again …
>
> Thanks, --David
>
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/