Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-13.txt

[Yoshifumi Nishida <[e-mail]>]

Hi Bob,

On Fri, Nov 6, 2020 at 5:01 AM Bob Briscoe <[e-mail]> wrote:

> Yoshi,
>
> On 06/11/2020 10:28, Yoshifumi Nishida wrote:
>
> Hi Mirja,
>
> It seems to me that we don't have much freedom for the frequency of the
> feedback.
> The draft says:
>       MUST immediately send an ACK once 'n' CE marks have arrived since
>
>       the previous ACK, where 'n' SHOULD be 2 and MUST be no greater
>       than 6.
>
> Or, options are not applied to this?
>
>
> [BB]
> Section 3.2.2 about the ACE field, which is in the main TCP header feeds
> back the count of CE-marked *packets* .
> Section 3.2.3 is about the AccECN TCP Option, which is optional and feeds
> back a count of *bytes* for each marking.
>
> If there are any places in the draft where this isn't clear, we can fix
> them. But, in this case, the  text right under your quote says:
>
>    These rules for when to send an ACK are designed to be complemented
>    by those in Section 3.2.3.3 <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-13#section-3.2.3.3>, which concern whether the AccECN TCP
>    Option ought to be included on ACKs.
>
>
> Also, even though traffic flows one direction, I think you might want to send back SACK options, etc.
>
>
> Last para of the Introduction:
>
>    It is recommended that the AccECN protocol is implemented alongside
>    SACK [RFC2018 <https://tools.ietf.org/html/rfc2018>] and ...
>
>
> Also, interactions with SACK are raised where necessary throughout the
> draft. In particular this one:
>
>       If the smallest allowed AccECN Option would leave insufficient
>       space for two SACK blocks on a particular ACK, the Data Receiver
>       MUST give precedence to the SACK option (total 18 octets), because
>       loss feedback is more critical.
>
> I see. Thanks for the clarification.

Another thought is bulk flow traffic tends to send full MSS packets. I
feel 1 byte granularity might not be very efficient.
>
> In any cases, I just thought saving option space won't be a bad thing if it's not overly difficult.
>
>
> [BB] If efficiency is needed, field(s) (or the whole option) can be
> omitted.
> During the history of this draft we have proposed different ways to encode
> information more efficiently, but WG discussion decided that simple
> omission or inclusion of fields gives optional efficiency with minimal
> complexity.
>
> I'm not saying the act of reducing the granularity of each field would be
> particularly complex.
> Rather, complexity comes from the resulting ambiguity. Here's an example:
> * The Linux code currently uses the byte counters to help disambiguate
> wrap of the 3-bit packet counter.
> * If for instance the byte counters were truncated by 8 bits for
> efficiency, it would add many more ambiguous cases for this code to have to
> take into account.
> * Such complexity introduces misunderstanding and bugs.
>
> The design has gone round and round many times. We have tried to converge
> on the best tradeoffs.
>
>

OK. I have some concern that mitigating ambiguity by the using option may
require a certain high frequency,
but if the results from implementations look good, I don't have much things
to say here.

Thanks,
--
Yoshi