Re: [tcpm] Sender Fallback in draft-ietf-tcpm-accurate-ecn-14

[Bob Briscoe <[e-mail]>]

Mirja, Gorry,

Point taken about mission creep from ECN feedback to setting the IP-ECN 
field in packets as a data sender.

The question is, where would fall-back behaviour like this be defined?
It's not congestion response, so it would not be relevant in each CC 
definition.
It's about mangling detection and fall-back. So it really belongs in 
RFC3168, or an update to RFC3168.
AccECN is now intended to update RFC3168, but its scope is not meant to 
cover fall-back.

I guess this ought to be recorded somewhere as a necessary item for an 
RFC3168bis. I don't think the IETF has a process for such a ToDo list, 
or does it?

As far as the AccECN draft is concerned, shouldn't I just delete this 
para? Rather than include something in AccECN that is out of scope, and 
then weaken it to non-normative, which could be misinterpreted as being 
unimportant, rather than out of scope.


Bob

On 21/03/2021 02:41, Gorry Fairhurst wrote:
> On 16/03/2021 16:25, Mirja Kuehlewind wrote:
>> Hi Bob,
>>
>> I do agree with Gorry that this is actually not about how to provide 
>> feedback but about how to use ECN and I think we were always aiming 
>> to separate the two.
>>
>> Maybe we can change to not normative and say something like disabling 
>> after a small fixed number fo CE marked packets is the easiest way to 
>> address this problem but there might be other, smarter, more flexible 
>> approaches…?
>>
>> Mirja
>
> Yes - that was what I noted.
>
> It would be possible to conjecture other ways to do this, although I 
> am not sure this is helpful. Perhaps the draft could instead say this 
> "this can be done by ..." and explain the method that is being used. 
> That leaves the possibility for a later spec to define a standard 
> sender method, or an alternative, but in the meantime it provides 
> guidance on what might be a useful practical approach.
>
> Gorry
>
>>
>>
>>> On 12. Mar 2021, at 13:23, Gorry Fairhurst <[e-mail]> 
>>> wrote:
>>>
>>> Thanks, see below:
>>>
>>> On 12/03/2021 12:14, Bob Briscoe wrote:
>>>> Gorry,
>>>>
>>>> We added this 'cos we were told it is common practice in production 
>>>> ECN-capable stacks.
>>> That's fine, and can be usefully noted - but then I'll say again - 
>>> this is about how *ECN* is used, not specifically an accurate ECN 
>>> issue!
>>>> I think it would be hard (and inefficient) to check continuously, 
>>>> because changing to or from a long run of CE marks once in progress 
>>>> is perfectly valid behaviour for a good path.
>>>>
>>> I agree that it would seem bad to check continuously, but maybe on a 
>>> path change detected (however that might be determined)?
>>>> Perhaps those who have implemented this could comment?
>>>>
>>>>
>>> That would be great,....
>>>> Bob
>>>>
>>> Gorry
>>>
>>>
>>>> On 12/03/2021 11:58, Gorry Fairhurst wrote:
>>>>> I have questions on the sender fallback in use of ECT(?) - not 
>>>>> because I do not agree with the method, I think the approach is 
>>>>> good. However, the method here is something that impacts the 
>>>>> sender CC method, not the feedback method. Maybe this was 
>>>>> discussed before - if so remind me - my questions relate to this:
>>>>>
>>>>> /Once a Data Sender has entered AccECN mode it SHOULD check whether
>>>>>     all feedback received for the first three or four rounds 
>>>>> indicated
>>>>>     that every packet it sent was CE-marked.  If so, for the 
>>>>> remainder of
>>>>>     the connection, the Data Sender SHOULD NOT send ECN-capable 
>>>>> packets,
>>>>>     but it MUST continue to feed back any ECN markings on arriving 
>>>>> packets./
>>>>>
>>>>> (i) I’m pretty sure this is safe to wait for /the remainder of the 
>>>>> connection/. Is this possibly unnecessarily restrictive - without 
>>>>> explaining why, in that some connections are long-lived and do 
>>>>> experience path changes?
>>>>>
>>>>> - At least I would like some text about path changes to path that 
>>>>> would support AccECN, and what happens.
>>>>>
>>>>> (ii) This isn’t really about AccECN at all, it’s about guidance on 
>>>>> the use of ECT(?) by a TCP sender's CC .
>>>>>
>>>>> I think this is intended here *only* is to apply to TCP senders, 
>>>>> and I think that needs to be made clear? - Although it might also 
>>>>> be valuable (non-normative?) advice for other transports that also 
>>>>> have a similar way of reporting CE?
>>>>>
>>>>> - To me is something that needs to be more explicit, and probably 
>>>>> in a separate sub-section or something?
>>>>>
>>>>> Gorry
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/