Re: [tcpm] AccECN and updating RFC3449

[Gorry Fairhurst <[e-mail]>]

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.

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