Re: [tcpm] AccECN and updating RFC3449

[Gorry Fairhurst <[e-mail]>]

On 21/03/2022 10:19, Bob Briscoe wrote:
> Gorry,
>
> One response inline, tagged [BB2]...
Thanks - see GF2:
>
> On 21/03/2022 08:07, Gorry Fairhurst wrote:
>> On 21/03/2022 01:04, Bob Briscoe wrote:
>>> Gorry, [cc'ing tcpm, given this is a tcpm draft]
>>>
>>> On 18/03/2022 19:31, Gorry Fairhurst wrote:
>>>> I have problems with the proposal for AccECN update to RFC3449.
>>>>
>>>> I found the ID complex spec to read, as it digs into multiple ways 
>>>> to perform accurate ECN reporting, so when thinking about ACK 
>>>> modification in a router, it's not easy too see what level of 
>>>> transport processing is desirable.
>>>>
>>>> The method seems robust to loss, and ought to work with tunnels, etc.
>>>>
>>>> RFC3449 references RFC3168, which is itself updated. That seems oK 
>>>> to me.
>>>>
>>>> The latest rev. of the AccECN ID says in the abstract:
>>>> “The document also specifies the
>>>>    treatment of this updated TCP wire protocol by middleboxes, 
>>>> updating
>>>>    BCP 69 with respect to ACK filtering.”
>>>>
>>>> - I did not find a specification in 3.3.3 that looked like it would 
>>>> be accepted into a BCP. That concerns me, so I'm directing my 
>>>> comment to the requirements line, 
>>>
>>> [BB] The original requirement regarding ACK filtering and ECN in 
>>> RFC3449 was equally brief and high level:
>>>     Appropriate treatment is also needed to preserve correct operation of
>>>     ECN feedback (carried in the TCP header) [RFC3168].
>>>
>> Yes it was.
>>> Section 3.3.3 in the AccECN draft 
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#section-3.3.3> 
>>> says the two minimal normative things that are surely necessary now 
>>> that there will be two different ECN schemes using the same TCP 
>>> header bits:
>>>     A node that implements ACK filtering (aka. thinning or coalescing)
>>>     SHOULD determine if an ACK is part of a connection using AccECN and
>>>     SHOULD then preserve the correct operation of AccECN feedback.
>>>
>> And I have concerns with recommending one of those and I don't see 
>> the value of the second.
>>>> and the following the two bullets:
>>>>
>>>> Bullet 1:
>>>>
>>>> This bullet motivates that routers seek to detect the use of 
>>>> accurate ECN ("SHOULD determine if an ACK is part of a connection 
>>>> using AccECN"), I think that needs to be qualified if kept. For me 
>>>> there seems a possibility that this add more "complexity" to the 
>>>> ACK processing, and therefore less predictable behaviour. This does 
>>>> not feel like it is a "SHOULD" or is necessarily good practice.
>>>
>>> [BB] Presumably you agree that it is reasonable that ACK filtering 
>>> ought to preserve the correct operation of ECN (as in RFC3449). And 
>>> now that AccECN introduces a second different ECN feedback scheme 
>>> using the same bits, surely you agree that ACK filtering ought to 
>>> preserve correct operation of AccECN as well.
>>>
>>> If you think that an ACK filtering function can (or at least might) 
>>> preserve the operation of both schemes without knowing which one 
>>> each packet is using, then yes we don't need bullet #1. Is this what 
>>> you're saying?
>>>
>>> We also need to bear in mind the subsequent para, which says that 
>>> AccECN hosts have to be robust in the face of *existing* ACK 
>>> filtering, whether or not it preserves the correct operation of 
>>> AccECN. I believe what we're trying to do here is ensure that ACK 
>>> filtering preserves its intention to *improve* performance - then 
>>> merely functioning would be OK, but not the goal.
>>>
>> I think much more work is needed to write this update to a BCP.
>>
>
> [BB2] RFC3449 is a BCP with one sentence about RFC3168 ECN and ACK 
> filtering, which gives no guidance on what the problem is or what to 
> do. It just says
>     "Appropriate treatment is also needed to preserve correct 
> operation of ECN feedback (carried in the TCP header) [RFC3168]."
> If that sentence wasn't there, it wouldn't need to be updated. But it 
> is. So surely it does.
>
> One possible way forward: RFC3449 is structured as a number of 
> sections on each topic, with discussion then a concluding paragraph 
> always headed 'RECOMMENDATION:' In the RECOMMENDATION section about 
> ACK filtering, all it says about ECN is: "Suitable algorithms to 
> support IPSec authentication, SACK, and ECN remain areas of ongoing 
> research."
>
> So, given the sentence about preserving correct operation of RFC3168 
> is not in a section headed RECOMMENDATION, presumably it is not 
> normative. If so, we wouldn't need to formally update RFC3449. Then we 
> could rephrase the sentences with the two SHOULDs as discussion (using 
> your other responses further down the email), rather than normative. 
> Although these are only bureaucratic changes, that do nothing about 
> actual performance, at least they would satisfy your desire not to 
> update RFC3449.
>
> To deal with actual performance, we could say that, from the PoV of 
> end systems, the sure-fire way to be robust against existing ACK 
> filtering would be to implement the AccECN TCP Option. I would add 
> this where it says the AccECN TCP Option is optional to implement. 
> Then refer to it from the ACK Filtering section.
>
> Is this moving towards what you are asking for?
>
>
> Bob

GF2: I like both of these proposals, and would be happy with this.

Gorry

P.S. To be fully clear, *IF* AccECN is deployed, which I really hope, 
and people start using it, e.g. for L4S, and then I expect the IETF will 
know  what to recommend, I'd hen be really happy to see an RFC that 
updates RFC3449 by adding "appropriate" procedures to the BCP.
>
>>>>
>>>> Bullet 2:
>>>>
>>>> This second bullet raises a concern that was motivated in 2.3, and 
>>>> I think that the text is useful as it warns, but does not propose. 
>>>> I think it is correct and proper to indicate that the use of AccECN 
>>>> can be impacted by routers that manipulate/thin ACKs.
>>>
>>> 2.3 talks about what Data Receivers need to watch for. It doesn't 
>>> mention middleboxes.
>>> 3.3 collects together all the items of interest to middlebox 
>>> implementers. This second bullet merely explains the concern. I 
>>> thought that's what you want.
>>>
>>>>
>>>> At the moment, the related requirement as written is:
>>>> "SHOULD then preserve the correct operation of AccECN feedback.", 
>>>> which I didn't see specified.I think it could also be useful 
>>>> perhaps as you do to speculate that it might be beneficial to 
>>>> update these routers, however the current text does not seem to be 
>>>> best current practice, at best it seems too vague.  For instance: 
>>>> I'm not clear what the text advocates when a queue of accurate ECN 
>>>> ACKs build at an intermediary.
>>>
>>> [BB]  I don't really understand what you want us to do. You seem to 
>>> want us to be less specific and more specific.
>>> You seem to want us to warn not propose (which I agree with), and 
>>> that's what I thought we were doing.
>>> But then you seem to want us to say how an ACK filter should 
>>> actually work with AccECN, which is surely beyond the scope of this 
>>> draft.
>>>
>>> Can you perhaps hint towards the text you are hoping for?
>> Describe the effects, and estimate their significance.
>>>>
>>>> In summary, I think I don't understand the need for the Updates 
>>>> line, and I do not see a BCP-style recommendation emerging yet. 
>>>> Maybe we just need experience and a short draft could write down 
>>>> what the IETF recommendation is, if there is finally a need for a 
>>>> change?
>>>
>>> [BB] It's problematic, because RFC3449 is a BCP, but it only says 
>>> the bare minimum (quoted above) about ACK filtering with ECN. 
>>> However, that bare minimum needs to be updated because ensuring the 
>>> correct operation of RFC3168 is no longer enough.
>>>
>>> Given RFC3449 doesn't use normative language, where the AccECN draft 
>>> updates RFC3449, I would be happy not to use normative language either.
>>> But I think it would still have to update RFC3449. Wouldn't it?
>> No, I don't think we need to do this, until we know what we recommend.
>>>
>>> [BB] Finally, during this conversation I've noticed the following 
>>> two lines. If they remain after we complete this conversation, I 
>>> suggest they are clarified as below:
>>>
>>>           ACE field wrap is of less concern if
>>>           packets also carry the AccECN TCP Option
>>>
>>>           ACE field wrap *might**be* of less concern if
>>>           packets also carry the AccECN TCP Option. *However, **
>>> **                   note that logic to read an AccECN TCP Option is 
>>> optional to **
>>> **                   implement (albeit recommended   see Section 
>>> 3.2.3).  So one end **
>>> **                   writing an AccECN TCP Option into a packet does 
>>> not necessarily **
>>> **                   imply that the other end will read it.*
>>>
>>> Bob
>>>
>>>>
>>>> Gorry
>>>>
>>>>
>>>
>>> -- 
>>> ________________________________________________________________
>>> Bob Briscoehttp://bobbriscoe.net/
>>
>> I suggest you do not try to fix this inside a document that is mainly 
>> about how to implement TCP.
>>
>> I am also not yet convinced this describes something specific that 
>> has been tested across different platforms and actually is the best 
>> practice. I think if the WG wants to do this work, then they should 
>> decide what is needed and show that it works across the different 
>> possible use cases, asking people to deply extra code that modifies 
>> packets on a path is not something I think we should encourage in 
>> general.
>>
>> Gorry
>>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/