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

[Bob Briscoe <[e-mail]>]

Gorry,

We added this 'cos we were told it is common practice in production 
ECN-capable stacks.

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.

Perhaps those who have implemented this could comment?


Bob

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

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