Re: [tcpm] Summary of updates in draft-ietf-tcpm-accurate-ecn-17

[Yoshifumi Nishida <[e-mail]>]

Hi Richard, Bob,

Thanks for the responses.

On Sun, Mar 20, 2022 at 6:08 PM Bob Briscoe <[e-mail]> wrote:

> Yoshi,
>
> On 20/03/2022 09:50, Yoshifumi Nishida wrote:
>
> Hi Bob,
>
>    - 'that acknowledges new data' -> 'if any byte counter has incremented
>    since the last ACK' {*includes new markings on retransmssions*}
>
> Does this mean when you retransmit a packet, the acc option in the packet
> should be updated to contain the latest info?
> If we do this, wouldn't it be hard for the receivers to tell which packet
> contains the most recent info when there's reordering?
>
>
> [BB] Yes and No (I don't think so, but perhaps I misunderstand your
> question).
>
> For first question: see end of §3.2, which has been there since the start
> of AccECN:
>
>    Whenever a host feeds back the value of any counter, it MUST report
>    the most recent value, no matter whether it is in a pure ACK, an ACK
>    with new payload data or a retransmission.  Therefore the feedback
>    carried on a retransmitted packet is unlikely to be the same as the
>    feedback on the original packet.
>
> For second question, when you say "the receiver"
> * if you mean the Data Receiver (i.e. the sender of the feedback), it
> doesn't need to know. It just increments its counters in whatever order
> markings arrive, whether on retransmissions or not, and feeds back the
> latest counter.
> * if you mean the Data Sender, see A.1 or A.2.1 where the example
> algorithms at the Data Sender check whether a packet is superseded (based
> on ackno, sack & timestamps if available) before using the feedback.
>
> Does that answer your questions?
>

Yes. Thanks for the explanation.
I've thought about the case where there's large re-ordering,
But, given that accecn option has 24bits fields as Rechard pointed out, I
think the possibility of the risk would be pretty low.

Thanks,
--
Yoshi

>