Re: [tcpm] Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)

Yoshifumi Nishida <> Wed, 17 March 2021 05:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08B453A1B51 for <>; Tue, 16 Mar 2021 22:47:56 -0700 (PDT)
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 JvG6X4ixzhtK for <>; Tue, 16 Mar 2021 22:47:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D6B13A1B50 for <>; Tue, 16 Mar 2021 22:47:54 -0700 (PDT)
Received: by with SMTP id h3so859545qvh.8 for <>; Tue, 16 Mar 2021 22:47:54 -0700 (PDT)
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=4F+p1BrujG/BPsbPWvgF8wsUS4+GCjjMvODALRHNd/E=; b=DJEZGKHs0tsrYXAWYT8CJhmXbaEPSvr9RObZDYg01I3UXQPOcTn4VD/mleLiP+GXR5 gea+0wnbVIJO/VDFjI+y5B2QKDShoNtrLHS9lriCCk8Vlve+eRJzokwNgiftrPfIW9Ij VUAXxjxWEQKs+AUKycB3z/rbaOkiYD5Q81xMSXnCoRMISCe+6sRUL+UmrHgKft0WVSa6 ZnHJXA8TMmerNqAhfNRZB9AviNA+U8T99JROE7SXRUJxeqJ66QPTX7NYCZK+41J7iJVN q2bCFACoEwCJTMp+FC+pq9R0phlUCn6pad7MRioFYqjtVTuJ9GaPRhe65KcanifVQ/Ws zHNA==
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=4F+p1BrujG/BPsbPWvgF8wsUS4+GCjjMvODALRHNd/E=; b=G3iCLUqu5jFwFH0STcPPsPwsSg5kGIDjY4HyzBRBwG9jBrtVT9CZOKQkAGPv0E26lO uTdON01m/XS9ue8sienLrAtLRF1LdETfMWaK2LutuViLi+KORnH17VZpy1UXrzCWMNhx R+7nexho6fugriom3XsXK4eu17gFxHfcNG43z0CFAvQl8utHJShtW5nSjmNcidxyitnb 8LWT1xM/Ua9rp0IifwcxEXKKHFaUrFd+dfbLL0S08LSHjwzgMnv+YXoAH230Fn3xW2JU gr6TVUV/gM6YYDUMZFv1OWk8WKc9OeDm6rkWP51JsjJzapeh+lVnjDbVpkfhN51HmEZO Hk5Q==
X-Gm-Message-State: AOAM530/tVrZdqxxo4cxFDdse4Kz5KNOW7IGWHWcrx8f+nFq3AgUBpW0 bMT7N4mnifIvAeFbyXBGZUP4hvmMsvxMmxiXWOo=
X-Google-Smtp-Source: ABdhPJyVBcpxfovQv7vgh8ba3IJ1+FPMzeqPmJXkffkqbQRqbG8EeQRVqLQMXdEuCSXMr8zcCxnB6/oNO+7to0sBWJ8=
X-Received: by 2002:ad4:5d46:: with SMTP id jk6mr3460086qvb.22.1615960072603; Tue, 16 Mar 2021 22:47:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Tue, 16 Mar 2021 22:47:41 -0700
Message-ID: <>
To: Mirja Kuehlewind <>
Cc: Bob Briscoe <>, Yoshifumi Nishada <>, tcpm IETF list <>
Content-Type: multipart/alternative; boundary="000000000000194c2f05bdb50635"
Archived-At: <>
Subject: Re: [tcpm] Seeking WG opinions on ACKing ACKs with good cause (was: 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, 17 Mar 2021 05:47:56 -0000

Hi Mirja,

On Tue, Mar 16, 2021 at 9:50 AM Mirja Kuehlewind <>

> Hi all,
> Actually I think there is no problem if a ACK on an ACK is misinterpreted
> as dup ACK. What happens if a dupACK is detected? The cwnd is decreased and
> lost data is retransmitted. However, the cwnd was either already decreased
> with the first ACK and would not be decreased again for the next RTT (in
> case of Reno-like cc), or should be decreased anyway because the ACK
> carries a new CE feedback. I guess we could note that one should not
> decrease twice because if the information in the same ACK (being dup and CE
> counter). However, there will be no retransmission because there is no
> outstanding non-acked data given the received ack'ed only an ACK and no new
> data. So in summary, there is no problem here with dupACK generated in
> response to a pure CE-marked ACK that needs to be addressed in any way.

I personally am not very fine with dup acks is being misinterpreted
This might be another corner case, but here's an example I've thought.

When a sender sent one data packet D1 and bunch of acks (say 30), and D1 is
lost, all acks have CE marks.
In my understanding, this will generate 10 dup acks that request D1 with
In this case, sender retransmits D1 after 3rd dupacks and it will still
receive 7 dupacks.
These 7 dup acks might trigger another transmission of packets on some
This is because RFC5681 states:

.  For each additional duplicate ACK received (after the third),
       cwnd MUST be incremented by SMSS.  This artificially inflates the
       congestion window in order to reflect the additional segment that
       has left the network.

RFC5681 also states:

   since the receiver can only generate a
   duplicate ACK when a segment has arrived, that segment has left the
   network and is in the receiver's buffer, so we know it is no longer
   consuming network resources.

But, I think this doesn't fit the logic in the doc very well. We might
want to add some texts for this if we choose (B)