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

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

> 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
>> 
> 
> 