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

["Rodney W. Grimes" <[e-mail]>]

David, Wes, etc al,

	Though RFC5033 may of been written at a time when only end node
changes to protocols had been occuring I think its spirit is that of
a "functional system".  L4S as an IP modification makes zero since
without the existance of a transport (TCP Prague) to use with it.

	It is, IMHO, imperative for the sucess of any congestion
mechanism that both the Internet and Transport layers be considered
in unision and that critera such as RFC5033 be applied to the system
as a whole.

	This is not unique to L4S, SCE and even RFC3168 ECN is
in this same sitution.  CE is usless without the likes of ECE,
which doesnt exist until you couple the two layers.

	More in line.
Regards,
Rod
	
> 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).

A seperate document that sites the place that each RFC5033 critera is
addressed was offered as an option in Jake's request.

> 
> 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.

+1, there is no way to unlink them.  Some of the current issues in the tracker are probably transport issues already.

> In contrast, the SCE folks appear to have successfully modified a number of congestion-controlled transport protocols.

I find this wording important enough to repeat it "Congestion-controlled transport"i, for me that shows how tight the 2 layers are coupled when working in this area.

> 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).
> > 
> 
> 
> 

-- 
Rod Grimes                                                 [e-mail]