Re: [tcpm] Partial implementation of AccECN Option logic

[Mirja Kuehlewind <[e-mail]>]

Sounds good to me. Thanks!


From: Bob Briscoe <[e-mail]>
Date: Thursday, 21. July 2022 at 14:23
To: Mirja Kuehlewind <[e-mail]>, tcpm IETF list <[e-mail]>
Cc: Yoshifumi Nishida <[e-mail]>
Subject: Re: [tcpm] Partial implementation of AccECN Option logic

Mirja,
On 20/07/2022 16:29, Mirja Kuehlewind wrote:
Hi Bob,

The new text looks fine. Regarding your question: If we would go for a MUST, this would be a MUST that we can’t (and don’t want to) enforce from a protocol machinery point of view. So, RECOMMENDED seems still right to me but I’d be happy to add some text to endorse the importance to implement options more!

[BB] I think you're right that what we're trying to say here is not that implementers MUST send options for interop to work, but that they really are strongly RECOMMENDED to. And given "strongly RECOMMENDED" isn't useful, let's add words explaining why, like you suggest. How's this?:

Current:

   Even if a

   developer does not implement logic to understand received AccECN

   Options, it is RECOMMENDED that they still implement logic to send

   AccECN Options to provide richer feedback to those remote peers that

   do understand it.  The logic to send AccECN Options is the simpler to

   implement of the two sides.
Proposed:

   Even if a

   developer does not implement logic to understand received AccECN

   Options, it is RECOMMENDED that they implement logic to send

   AccECN Options.  Otherwise, those remote peers that implement the

   receiving logic will still be excluded from congestion feedback that

   is robust against the increasingly aggressive ACK filtering in

   the Internet.  The logic to send AccECN Options is the simpler to

   implement of the two sides.


I've changed the editor's copy. If no-one objects, I will post the rev (-20) with just this change when the servers reopen on Monday.


Bob



Mirja



From: tcpm <[e-mail]><mailto:[e-mail]> on behalf of Bob Briscoe <[e-mail]><mailto:[e-mail]>
Date: Wednesday, 6. July 2022 at 16:58
To: tcpm IETF list <[e-mail]><mailto:[e-mail]>, Yoshifumi Nishida <[e-mail]><mailto:[e-mail]>
Subject: [tcpm] Partial implementation of AccECN Option logic

Yoshi (and tcpm)

Thanks for reminding me to get the AccECN draft finalized.

In the last tcpm meeting, I listed two things we're still planning to update:
    https://datatracker.ietf.org/meeting/113/materials/slides-113-tcpm-draft-ietf-tcpm-accurate-ecn-18-00
I'll deal with each in a separate email:

This email is about switching round the recommendation on what is 'least worst' to leave out of an initial implementation in §3.2.3:
    https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#section-3.2.3
as below.

Current:
Even if a developer does not implement sending of the AccECN Option, it is
RECOMMENDED that they still implement logic to receive and understand any
AccECN Options sent by remote peers.
Proposed:
Even if a developer does not implement logic to understand received AccECN
Options, it is RECOMMENDED that they still implement logic to send AccECN
Options to provide richer feedback to those remote peers that do understand it.
The logic to send AccECN Options is the simpler to implement of the two sides.

Question for the list: Ought this to be a MUST, rather than just RECOMMENDED?
If there's disagreement, we won't make it a MUST.

____________
Rationale for the change: After Ilpo implemented the AccECN Option, he told me:
* the logic to receive an AccECN Option was more tricky, because it includes heuristics to estimate the counters if ACKs arrive without the option.
* whereas the logic to send them was fairly straightforward (now that the recommended default option size is constant). It essentially involves implementing:
   - the byte counters,
   - choosing the field order,
   - building and sending the option fields,
   - checking whether sending the option puts the connection into a black hole (and optionally caching this knowledge).



Bob




--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-b0108c2709550a3a&q=1&e=64505613-1863-49c3-9d39-da4dd8624196&u=http%3A%2F%2Fbobbriscoe.net%2F>



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-b0108c2709550a3a&q=1&e=989f7da3-dd23-462b-a5a0-8a2e78ac95a6&u=http%3A%2F%2Fbobbriscoe.net%2F>