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

[Mirja Kuehlewind <[e-mail]>]

We could start a 3168bis doc ;-)

Or start a separate draft for validation. QUIC has already some text on this:

https://www.ietf.org/archive/id/draft-ietf-quic-transport-34.html#name-ecn-validation

See also 

https://www.ietf.org/archive/id/draft-ietf-quic-transport-34.html#ecn-alg

However, this is actually not really QUIC or TCP specific and could go into tsvwg.

For the AccECN, I think it would still be good to at least mention that validation is needed. I would even say that it recommended to be implemented some smarter together with AccECN, given the simple if-SYN-is-CE-marked test doesn’t work anymore if SYN can be ECT marked. Or maybe this is something to say in the ECN++ draft...?

Mirja



> On 21. Mar 2021, at 19:32, Bob Briscoe <[e-mail]> wrote:
> 
> 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/
> 
>