Re: [tcpm] Possible error in accurate-ecn

Yoshifumi Nishida <> Wed, 11 November 2020 09:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 818C43A0FE2 for <>; Wed, 11 Nov 2020 01:37:41 -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 VAKQSNDQJR_C for <>; Wed, 11 Nov 2020 01:37:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E3A43A0DC4 for <>; Wed, 11 Nov 2020 01:37:40 -0800 (PST)
Received: by with SMTP id v143so1096722qkb.2 for <>; Wed, 11 Nov 2020 01:37:39 -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=ZybdvdgbiNSNk5n4j78yCN4HNaQfetsRYsn45xT4w4o=; b=OWIZNgOy4IjCBnVqnj0+vLLqMcpx8XDdz/4O6vK1V403YYcyNMmgVeUl2ZXMKEgxTv CZbxKtk/2+Ky3F2u7jCQavvKYQI8S3Y8mr00zD9FKUraYiLjwADHXm6HcjmcduT/zkCa HQF8O8C64WXkS9t93pdVhft5RO2gmwwOm7lS4P2jFWioi8OimQWH3Kw0vfvFLpsFKwL1 +az2+wFEOyTQQyiAgi0NEyXDN4zEiXj/gGPSBL7Ou2DWAOA00Q0ydTiGNlIvxz0+a6JQ X4/b/fGQ+hMsuUpydLVMEQhORbgnHuH+G0qU4adIPWSBZlDyKRKGdscD6pYLC3OWLT3O czlA==
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=ZybdvdgbiNSNk5n4j78yCN4HNaQfetsRYsn45xT4w4o=; b=PsEM4t4JLuLNIPadOQaLdgzumNgEURdNSYf0LTBfxROQXYMZOw1/oO7ssDFSwwtaQA kWGRkvdGR51BWhf0g255kok+jmEaUJt+ALVtdVFdDpjfCq5vvtd3Ljk5RTW5GhQg2aUL 06epJwSZShPTpV0xQ8PzapGaUWUsTJUhLdNVnF7t4IIh3OcnBDBgWL7MgdAfXuPrnQ+L 6CKWY56wACgx9GxB7qdQkZuEsRs8YuIUbzHnQQFbTsJ7HTYAVXzYHARq9PX5cPHulgzf Fv/Sbz7gIB/aLnt/kKXT2eVXg3cuAR+f0/gzjC9+LI3b5AW/ecv7/3SuDXMiop7fU+nu tQ2A==
X-Gm-Message-State: AOAM531/L9bDSLfNMhNM4lob5SartyFhPO+IhKJ/JnMnD51DeSaWYOfF bhb4hBa3TsPoVqnsMhO4r7BZHnYlBAOlPI3L8RM=
X-Google-Smtp-Source: ABdhPJxDdReUvhgSMnqP8dsjEDUU9zDQm8BjAvH7VnfCq2YLLTxfAdIZmhu/af1a1NSNXoS+8i1+wC7MBcToL0WkRrA=
X-Received: by 2002:a05:620a:11a4:: with SMTP id c4mr14569637qkk.8.1605087458986; Wed, 11 Nov 2020 01:37:38 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Wed, 11 Nov 2020 01:37:27 -0800
Message-ID: <>
To: Mirja Kuehlewind <>
Cc: Bob Briscoe <>, tcpm IETF list <>, Richard Scheffenegger <>
Content-Type: multipart/alternative; boundary="000000000000d38e5a05b3d18bbf"
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: Wed, 11 Nov 2020 09:37:42 -0000

On Tue, Nov 10, 2020 at 2:08 AM Mirja Kuehlewind <>

> 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.

> 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"?