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

[Gorry Fairhurst <[e-mail]>]

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
>