Re: [tcpm] Possible error in accurate-ecn

[Yoshifumi Nishida <[e-mail]>]

Hi Bob,

On Wed, Nov 11, 2020 at 3:18 PM Bob Briscoe <[e-mail]> wrote:

> Yoshi,
>
> On 11/11/2020 09:37, Yoshifumi Nishida wrote:
>
>
>
> 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.
>
>
> [BB] I'm not expert in TCP loss recovery but, surely if TCP A has nothing
> outstanding, it cannot consider receipt of dup acknowledgements from TCP B
> as a sign of loss? Nonetheless, there would be a chance that such a dup
> acknowledgement might be in flight when TCP A happened to have just sent
> some more data, and they crossed in flight.
>
> To avoid this case, it would be possible for TCP B to send pure ACK(s)
> with SEG.SEQ = SND.NXT-1 (using the same trick as keepalive probes). Being
> out of window, each of these pure ACKs would elicit a further pure ACK from
> TCP A. However, that would acknowledge SND-NXT, so the loop would stop
> there. Nonetheless, if TCP B started sending data again, and if TCP B's
> data crossed the pure ACKs that it had recently elicited from TCP A, once
> these pure ACKs arrived at TCP B, I think it would treat them as DupACKs.
>
> It's seems possible for TCP B to recognize that it elicited these DupACKs
> from TCP A, and to therefore work out that it could ignore them.
>
> I've kept on digging into this particular obscure corner of ACK congestion
> control, only 'cos I wanted to see if there was a useful end to this hole
> (so it would be worth the AccECN RFC allowing others to dig there later,
> rather than ruling it out).
>
> Nonethless, the AccECN draft itself doesn't have to go anywhere near this
> subject - it can leave all that for a potential future draft about using
> AccECN for ACK congestion control.
>

I personally prefer not to specify very detailed logic for ACK CC here
unless it is crucial for the doc.
Since the doc is aiming to be a PS, I think it would be better to avoid
risks for nasty corner cases caused by some tricky techniques.

> 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"?
>
>
> [BB] Yes. That's a fairly safe thing to require.
> I think the best strategy here is to require an immediate ACK in response
> to a data packet if there are at least 'n' CE marks to be reported. And to
> extend that requirement to immediately ACKing a pure ACK if the ACK value
> has advanced since the last ACK. But just to say nothing about ACKing pure
> ACKs in other cases, so we don't preclude a case that can be made safe in
> future (e.g. with something like the keepalive approach above).
>
> If you (Yoshi), Mirja and others agree, let's try to work out the wording
> of this second bullet.
>

Works for me. If you could have proposed texts, I will take a look.
--
Yoshi