Re: [tcpm] AccECN and updating RFC3449

[Bob Briscoe <[e-mail]>]

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


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

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

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

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