Re: [tcpm] Possible error in accurate-ecn

[Yoshifumi Nishida <[e-mail]>]

On Tue, Nov 10, 2020 at 2:08 AM Mirja Kuehlewind <[e-mail]>
wrote:

> Hi Bob,
>
> Please see below.
>
> > On 10. Nov 2020, at 01:31, Bob Briscoe <[e-mail]> wrote:
> >
> > Mirja, Richard, Ilpo, tcpm list,
> >
> > I've just been reading through the accurate-ecn draft to double-check. I
> think there's a problem with the following text...
> >
> > 3.2.2.5.1.  Data Receiver Safety Procedures
> >
> >    An AccECN Data Receiver:
> >
> >    o  SHOULD immediately send an ACK whenever a data packet marked CE
> >       arrives after the previous [data] packet was not CE.
> >
> >    o  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.
> >
> > ...
> >    For the avoidance of doubt, the change-triggered ACK mechanism is
> >    deliberately worded to solely apply to data packets, and to ignore
> >    the arrival of a control packet with no payload, because it is
> >    important that TCP does not acknowledge pure ACKs.
> >
> >
> > In the first bullet, I think it doesn't matter whether the previous
> packet marked CE was a data packet or a pure ACK (i.e we should remove the
> second occurrence of 'data' that I have put in [square brackets].
>
> I believe it does matter. If the previous packet was a pure ACK and was CE
> marked, you didn’t send an ACK and so you should immediately send one now.
> If the previous packet was a data packet and CE marked, you don’t need to
> send an immediate ACK because you already did this with the previous
> packet. However, it text might be a but ambiguous because what is meant is
> “if the previous packet was a data packet and CE marked”. So this does not
> apply if we e.g. have a CE-marked data packets, then a pure ACK that is not
> CE marked, and then another CE-marked data packet.
>
> >
> > The second bullet doesn't consider the possibility that the 'n'th  CE
> mark might arrive on a pure ACK. Then, the wording as it stands says the
> Data Receiver MUST immediately ACK a pure ACK. I know TCP never ACKs a pure
> ACK, but I'm not actually sure it does any harm to do so in this case (it
> cannot cause an infinite loop of ACKs). However, given it would be
> unorthodox, we maybe ought to rule it out by rewording anyway?
>

even though it won't cause an infinite loop, can they be dup acks? If so,
it doesn't look good to me especially when early retransmit is activated.


> I think we also can leave this as it is because if that ’n’ packet is a
> pure ACK that still means that you have unacked data packets with CE marks
> and you should trigger an ACK for those packet now (rather than waiting for
> the delayed ACK timer to expire). However this case is less important. Also
> we should probably make sure that this doesn’t apply if there are only pure
> ACKs with CE marks, maybe by add “if unacknowledged data are outstanding”
> or something.
>
>
"can send a pure ack on a pure ack when the ack value advances"?
--
Yoshi