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

[Gorry Fairhurst <[e-mail]>]

On 04/11/2019, 09:11, Sebastian Moeller wrote:
>
>> 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?
Because, that is why the WG publishes EXP RFCs.

My own understanding, is that to publish a PS update to TCP, it is good 
to have deployment experience.
To get there, you need to alreday have completed detailed experiments in 
labs, etc, and show safety
there and then have a proposal that has been accepted by the WG and 
developed into an RFC
- The EXP RFC. Next comes the deployment, and decision about what to do 
next - many TCP RFC's remain EXP.

In this case, the purpose of the RFC8511 experiment is to "collect experience with the deployment of ABE
and confirm acceptable safety in deployed networks that use this update to TCP congestion control"
and then to "propose it as a Standards-Track document in the future".  (Section 6).

> 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).
That can indeed be an issue, if a new proposal comes along that depends 
on one of the existing experiments. That needs careful thought.
> Sebastian
Gorry