Re: [tsvwg] TCP Prague's RFC 5033 guidelines status?

["Black, David" <[e-mail]>]

Wes,
[still as an individual]

For now, I'm going to agree to disagree, as I have a different perspective on:

> If really needed, it seems like the 5033 guidelines could be mapped to
> sections of the L4S documents where the topics are discussed, but I'm
> not sure how meaningful it could be without regard to specific scalable
> end-host algorithms (e.g. Prague).

My current (individual) view is that the L4S experiment requires TCP Prague, so I view those two activities as inherently linked.  If anyone disagrees and wants to continue the discussion ;-), please identify another congestion-controlled transport protocol that meets the L4S low latency service requirements.  In contrast, the SCE folks appear to have successfully modified a number of congestion-controlled transport protocols.

Thanks, --David

> -----Original Message-----
> From: Wesley Eddy <[e-mail]>
> Sent: Monday, November 11, 2019 5:12 PM
> To: Black, David; [e-mail]
> Subject: Re: [tsvwg] TCP Prague's RFC 5033 guidelines status?
> 
> 
> [EXTERNAL EMAIL]
> 
> On 11/11/2019 11:06 AM, Black, David wrote:
> > Well, L4S imposes strict requirements on end-host algorithms for traffic that
> uses the low-latency service.  TCP Prague is the only known transport protocol
> that satisfies those requirements, i.e., no other existing TCP or DCTCP code
> satisfies those requirements, as far as I am aware (please correct this statement
> if it's wrong).
> >
> > For that reason, decisions about deploying L4S and TCP Prague appear to be
> linked, as it would be silly to deploy a network service (L4S) that cannot be used
> by end-systems, and end-system usage of L4S appears to require TCP Prague.
> 
> 
> I believe you're referring to the congestion response requirements in
> the L4S ID draft.  I think those are a start to requiring an end-host
> algorithm to have good properties with regard to 5033 guidelines, rather
> than requiring some bad behavior (e.g. the first one is "MUST coexist
> safely with Reno" which speaks right to 5033 guideline 1 "Impact on
> Standard TCP, SCTP, and DCCP").  So, I'm not sure why those are a
> concern (i.e. which L4S ID congestion response requirements do we have
> 5033 concerns with?).
> 
> If really needed, it seems like the 5033 guidelines could be mapped to
> sections of the L4S documents where the topics are discussed, but I'm
> not sure how meaningful it could be without regard to specific scalable
> end-host algorithms (e.g. Prague).
>