Re: [tcpm] Partial implementation of AccECN Option logic

[Bob Briscoe <[e-mail]>]

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]> 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
>     Option*s*, 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 Briscoehttp://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 Briscoehttp://bobbriscoe.net/