Re: [tcpm] Possible error in accurate-ecn

Yoshifumi Nishida <> Thu, 12 November 2020 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36F553A0E8F for <>; Thu, 12 Nov 2020 14:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cqQ4m-uAmjLm for <>; Thu, 12 Nov 2020 14:42:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D69B3A0E8E for <>; Thu, 12 Nov 2020 14:42:01 -0800 (PST)
Received: by with SMTP id 11so7152982qkd.5 for <>; Thu, 12 Nov 2020 14:42:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cm/RDn+iyXC6UlL1dScw+6u5DbZN29R4KaEA5+0EhXI=; b=WPt7X8k0x+BSlBdKGYYXke0wo4B2kxYrBkSTi1sbWwqzXOg9MwgEMPVlG/mfvJOloa CkNBRsfbQ9ULZAMul78/rx2ES+n4YNRjnBle8nsqvBIDqwsk2Y+nABcRa3D9lolx33F+ lH/c2ORsaQmPXiOJXYt1UFCkx03V+s8vN7ByixV1OlfAjOL41b/Hf77cS0+iCZBDB/MA S+23XsXcYUkqHhkNny8GtI0Y2yqoig+Qd8iT48vZcLacOAqF8v1K6llFb1TJ4e+J37SV ybBnWSpnbtyHtmur1cjwzJCKCDwQc9xueKCKqjuTwr5Dr3gIuN7ulRlJw1mXAhnZV7m+ hz/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cm/RDn+iyXC6UlL1dScw+6u5DbZN29R4KaEA5+0EhXI=; b=LcP/lQoyoInYpaQxc4Xrq/daskxOnBUNU0OKt1Ubvy3dOhJb3knqUWTsdqAIm6PYZj Vu6k2ym9tqH6ZRQrC6j8Z0GQoEmWRYR7U1OdnoMkIVO0EJSZ034CcnMEy6cda7D9mGLE RQuO/Elis6MPcMtkjxwUHH1l9cn0lD9Ns+ox6q3x40IeN6I+glrKiLLMLgmJgk+ED6T6 j8xghO9rda0g0kF3clv9GkvkBPkhiLnWg83oXeGsgMA3PL39joURFMXt+cCx4n4i6LCU fEViJB425PxrkRUcc5CyL5Crw0RIj8sHdeAiVH3HFXQqt3BPqIpxKkxCxzqpvM/fn9vw yWPw==
X-Gm-Message-State: AOAM532p4So6uVLrYbSCrUWRz7UfUyc+w4rD7Y9a+irYO295AYdWe1LO YrTwHfUPuiGq7lf1e/VruTpy0x23HF0T4AYA2Jo=
X-Google-Smtp-Source: ABdhPJzT9qsY6PIZD6+rPC/M+adCKlQTyhokB+tWdPGVDZ2pPDhP7sFxOgVEUrYWYLEv0teDME5nmAfRYmDRo3tLnRI=
X-Received: by 2002:a37:87c5:: with SMTP id j188mr2275647qkd.476.1605220920178; Thu, 12 Nov 2020 14:42:00 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Thu, 12 Nov 2020 14:41:49 -0800
Message-ID: <>
To: Bob Briscoe <>
Cc: Mirja Kuehlewind <>, tcpm IETF list <>, Richard Scheffenegger <>
Content-Type: multipart/alternative; boundary="000000000000bbba6605b3f09ed0"
Archived-At: <>
Subject: Re: [tcpm] Possible error in accurate-ecn
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Nov 2020 22:42:03 -0000

Hi Bob,

On Wed, Nov 11, 2020 at 3:18 PM Bob Briscoe <> wrote:

> Yoshi,
> On 11/11/2020 09:37, Yoshifumi Nishida wrote:
> On Tue, Nov 10, 2020 at 2:08 AM Mirja Kuehlewind <>
> wrote:
>> Hi Bob,
>> Please see below.
>> > On 10. Nov 2020, at 01:31, Bob Briscoe <> 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...
>> >
>> >  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.