Subject: Re: [tcpm] AccECN and updating RFC3449

From: Bob Briscoe <[email-masked]>
Date: Mon, 21 Mar 2022 00:04:04 +0000

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/

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 21 Mar 2022 09:07:11 +0100

On 21/03/2022 01:04, Bob Briscoe wrote:
>> - 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:
Yes it was.
> 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:
And I have concerns with recommending one of those and I don't see the 
value of the second.
> [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.
>
> 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.

> implementers. This second bullet merely explains the concern. I 
> thought that's what you want.
>
>>
> [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.
Describe the effects, and estimate their significance.
> 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.
>
No, I don't think we need to do this, until we know what we recommend.
> **                   writing an AccECN TCP Option into a packet does 
> not necessarily **

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

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 21 Mar 2022 09:19:18 +0000

Gorry,

One response inline, tagged [BB2]...

On 21/03/2022 08:07, Gorry Fairhurst wrote:
>>> I found the ID complex spec to read, as it digs into multiple ways 
>>> to perform accurate ECN reporting, so when thinking about ACK 
>>> be accepted into a BCP. That concerns me, so I'm directing my 
>>> comment to the requirements line, 
>>
>> that there will be two different ECN schemes using the same TCP 
>> header bits:
>>> 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 
>> packet is using, then yes we don't need bullet #1. Is this what 
>> you're saying?
>>

[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

>>> think it is correct and proper to indicate that the use of AccECN 
>>> can be impacted by routers that manipulate/thin ACKs.
>>
>>> what the text advocates when a queue of accurate ECN ACKs build at 
>>> an intermediary.
>>
>>> 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?
>>

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 21 Mar 2022 14:42:05 +0100

Thanks - see GF2:
>> And I have concerns with recommending one of those and I don't see 
>> the value of the second.
>>>> 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.
>>>
>>> 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?
>>>
> 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]."
> 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.
>

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 
>>>> 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.
>>>
>>> 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.
>>>
>>> [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.
>>>
>>> [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:
>>>
>> I am also not yet convinced this describes something specific that 
>> has been tested across different platforms and actually is the best

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 22 Mar 2022 10:27:24 +0000

Gorry,

I'm going to post a new rev (-18) without any changes to the ACK 
filtering section.
Then we can focus solely on getting the ACK filtering section right for 
the next rev (hopefully in days not weeks).

Before this ACK filtering conversation started I had planned to post 
other recent changes on Monday morning, to give people time to read 
before the meeting.
I'd rather not delay this any more. Also, the ACK filtering changes 
won't be helped by being rushed.

Bob

On 21/03/2022 13:42, Gorry Fairhurst wrote:
>>>>> - 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, 
>>>>
>>>>> ACK processing, and therefore less predictable behaviour. This 
>>>>> does not feel like it is a "SHOULD" or is necessarily good practice.
>>>>
>>>> each packet is using, then yes we don't need bullet #1. Is this 
>>>> what you're saying?
>>>>
>> 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.
>>
> 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:
>>>>>
>>>>> I think it is correct and proper to indicate that the use of 
>>>>> AccECN can be impacted by routers that manipulate/thin ACKs.
>>>>
>>>> Given RFC3449 doesn't use normative language, where the AccECN 
>>>> draft updates RFC3449, I would be happy not to use normative 
>>>> language either.
>>>> **                   note that logic to read an AccECN TCP Option 
>>>> is optional to **
>>>> **                   writing an AccECN TCP Option into a packet 
>>>> does not necessarily **
>>> I suggest you do not try to fix this inside a document that is 
>>> mainly about how to implement TCP.
>>>