Re: [tcpm] AccECN and updating RFC3449

[Bob Briscoe <[e-mail]>]

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

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/