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

[Sebastian Moeller <[e-mail]>]

> On Nov 4, 2019, at 09:19, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 03/11/2019, 13:08, Jonathan Morton wrote:
>>> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst<[e-mail]>  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
> 

Question: Since the ABE RFC is marked experimental while RFC3168 is a proposed standard, why should tcpsce fall-back to RFC8511 instead of RFC3168? 
I ask as in the discussion of L4S it was (IMHO rightfully) argued that including a requirement on another experimental RFC (RACK in that case) was problematic as it would link basically independent experiments (and introduce undesired fate-sharing).

Sebastian