Re: [tcpm] Partial implementation of AccECN Option logic

[Mirja Kuehlewind <[e-mail]>]

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!

Mirja



From: tcpm <[e-mail]> on behalf of Bob Briscoe <[e-mail]>
Date: Wednesday, 6. July 2022 at 16:58
To: tcpm IETF list <[e-mail]>, Yoshifumi Nishida <[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>