Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt
From: Gorry Fairhurst <[email-masked]>
To: Jonathan Morton <[email-masked]>
Cc: "Rodney W. Grimes" <[email-masked]>, "[email-masked]" <[email-masked]>, "Rodney W. Grimes" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 04 Nov 2019 08:19:50 +0000
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>

On 03/11/2019, 13:08, Jonathan Morton wrote:
>> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst<[email-masked]>  wrote:
>>
>>> 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?
> RFC-8511 doesn't change the signalling on the wire relative to RFC-3168.  That was the sense intended here.
>
>   - Jonathan Morton
RFC3168 describes both endpoint behaviour and network functions. To me, 
this sentence is about
how you receive indications of incipent congestion, the sender can 
change from using only CE to using CE plus
the accurate information -or fall back to using just CE - ultimately it 
falls back to just detecting congestion (loss,delay).
So yes, the CE signal could be regarded as input to SCE.

The endpoint behaviour, I think, should fall back to RFC8511.

Gorry