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

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 <gorry@erg.abdn.ac.uk> 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
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>