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

[Gorry Fairhurst <[e-mail]>]

See in-line.

On 02/11/2019, 23:26, Rodney W. Grimes wrote:
> Rod Grimes                                                 [e-mail]
> Alex,
> With respect to draft-ietf-tcpm-accurate-ecn and
> draft-grimes-tcpm-tcpsce compatibility:
>    When accurate ecn (AccECN) fails to negotiate an AccECN capable session
>    it falls back to RFC3168 conformance, leaving a state that is fully
>    compatible with SCE, hence they are compatible.
I was expecting this to fall-back to RFC8511, treatment at the 
endpointrs, since that is the most recent spec. Does that make any 
difference to your thoughts abiout what you expect an endpoint to do 
when it receives ECN-marking without Accurate ECN?

Gorry
>    I am currently working on a revision to draft-grimes-tcpm-tcpsce and
>    hopefully can cover this "compatible" situation in the draft itself.
>
> With respect to "There are no IANA considerations":
>    You are correct, reworking that in several respects, hope to remove
>    references to the NS bit for most parts and simply state that this
>    draft for "IANA considerations" is requesting a bit, with the former
>    NS bit prefered.
>
> Regards,
> Rod
>
>>   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
>>>>
>>
>>
>>