Re: [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

["[e-mail]" <[e-mail]>]

 Rod, Jonathan,
 I could be wrong, but it appears to me that this draft does not merely not make use of draft-ietf-tcpm-accurate-ecn,it's incompatible with it. Is this the case? Of course SCE is a competitor to L4S, but the accurate-ecn draft also asserts that there are other uses for accurate-ecn besides L4S (DCTCP and ConEx) . It would be useful if you (the TCPSCE authors ) could state your position on those other uses, for the record. 

Also, presumably it is incorrect that "There are no IANA considerations", since IANA would need to change the NS bit.

Regards,
Alex

Rodney W. Grimes" <[e-mail]> wrote:
> > Rod,
> > 
> > This draft appears to be focused on obtaining a TCP header bit for SCE.
> 
> Yes, that is correct.
> 
> > As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consider how that functionality might (or might not) be usable with SCE. 
> 
> I specifically did not do what Accurate Ecn attempts as that requires
> a TCP option negotiation at connection establishment to negotiate the
> overloading of other TCP header bits.  SCE only needs 1 new bit, and
> does not alter the behavior of any current bits.
> 
> This proposal (TCPSCE) does not in any way effect the current use of
> any of the other bits, and use of the NS bit should be fully backwards
> compatible and ignored by pre SCE implementations and does not require
> a TCP option negotiation.
> 
> I have to get additional data but have been lead to understand that
> adding a tcp option and doing that negotiation is going to cause a
> great deal of pain in the ability to deploy accurate ecn as it is
> currently designed due to middle box inspection and handling.
> 
> Regards,
> Rod
> 
> > Thanks, --David
> >