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

Yoshifumi Nishida <> Fri, 19 March 2021 08:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67A753A16E6 for <>; Fri, 19 Mar 2021 01:25:02 -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 09dE295uAyFZ for <>; Fri, 19 Mar 2021 01:25:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E4B63A16E5 for <>; Fri, 19 Mar 2021 01:25:00 -0700 (PDT)
Received: by with SMTP id s2so6112354qtx.10 for <>; Fri, 19 Mar 2021 01:25:00 -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=JvfizKFfetmPDi/nyWXH1TEUp4qHF2Y7ig9ex9khH0A=; b=cr4A3Lak2Bq8lURdGoafUFhqgpLHlk4yAoOV3vp3gBFQMPru0b4H3x+QHKzVRJx32n w44dCu6HlOzvkzVCLijzFPfrrDCPNzJM5ML8xMgN0uSeq7V5QaiA+ELtZuBnmubBNu9m dV0gBZLkJwz+YH8rnK4SqworY57EQDArF9i23pQwwpawj3+ChqJ3c3qVbhrKiISYUje2 j0Gy55+EZEMOLQwJdfKP5fSXRm2Ho8GuUqHfkBqmRE/P/JIbGJBPnhMM2+X9HA763yCh D/0pC4WlnJkQzK3FcEN6uLblFdQqQ8SE/7mf1pSvXsxyTeS+O5WazPUC8a794Mn3ILWl PLVg==
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=JvfizKFfetmPDi/nyWXH1TEUp4qHF2Y7ig9ex9khH0A=; b=a45Z+c2saXbGGnkJaaMQg2rudgav7ZMQwdKgUFJqOFj2CADSDMGVRCrbQggXppLNye 62mq9Sm/M7Ra/s1X9VNmW9EnUTbnDemAeIWljXtyYGDfItWfxfezEdVgxumJGhUaZVPf bQPRQir9gjCaO39iXXm7hucOQbLgvnue8DKqzmE4fGCclYL6rt2oZd/mfDdNMH4l7i9l Q6YHkP0LdSJv8Y8FrrFSbwWCi6QOD4f8nrryEQLum250d9J14tYjkRMIZbRzNni3saG4 BDolWldG5wrcuWOGNjf+LxuOv6RYztP7o5A1T9+7uwMFyIlwqr9WJUR+MQ+BvcINxIST IO7A==
X-Gm-Message-State: AOAM530idtMUf2zh6k5hHhFXPSmsEyNASDDvdNlT6XV8SqkHRn4Wsw20 L+14A3TQZ9KmV0WjDt+TtYIYRPHF/trikknWLCU=
X-Google-Smtp-Source: ABdhPJyw3WfT8jJxQ5kYGg5rnOnpgy6m+EYYb6VJ01voRbRCDBYT0QVwwLksFTOAtfZS/Gp59eq1vrYm8ZgYhfmixIQ=
X-Received: by 2002:aed:2e62:: with SMTP id j89mr7182215qtd.310.1616142299071; Fri, 19 Mar 2021 01:24:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Fri, 19 Mar 2021 01:24:47 -0700
Message-ID: <>
To: "Scheffenegger, Richard" <>
Cc: Mirja Kuehlewind <>, Yoshifumi Nishada <>, tcpm IETF list <>
Content-Type: multipart/alternative; boundary="000000000000a4882305bddf734a"
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: Fri, 19 Mar 2021 08:25:02 -0000

Hi Richard,

On Wed, Mar 17, 2021 at 1:02 AM Scheffenegger, Richard <>

> First RFC5681 states (for completeness):
>     DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a
>        "duplicate" in the following algorithms when (a) the receiver of
>        the ACK has outstanding data, (b) the incoming acknowledgment
>        carries no data, (c) the SYN and FIN bits are both off, (d) the
>        acknowledgment number is equal to the greatest acknowledgment
>        received on the given connection (TCP.UNA from [RFC793]) and (e)
>        the advertised window in the incoming acknowledgment equals the
>        advertised window in the last incoming acknowledgment.
>        Alternatively, a TCP that utilizes selective acknowledgments
>        (SACKs) [RFC2018, RFC2883] can leverage the SACK information to
>        determine when an incoming ACK is a "duplicate" (e.g., if the ACK
>        contains previously unknown SACK information).
> So, there is already the strong advice, that existing SACK information
> shall be considered for DupACK detection.
> Also, I still believe, that we give this particular corner case more
> stage time than warranted.
>  > 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 (B)
>  > 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
>  > implementations.
> Lets work this example:
> A used to be the sender of 60 segments.
> B is  ACKing all the above segments with 30 segments.
> The network is suddenly having a pathologic state, where each and every
> of these ACKs is CE marked.
> B is now transmitting D1.
> A ACKs every 3rd CE-marked ACK with another ACK,no SACK, TSecr reflects
> the TSval of these ACKs
> A ACKs D1 (no SACK, TSecr of D1)
> B observes ACKs, with a TSecr indicating they are sent before D1 could
> arrive. And they don't contain SACK. However, ACE increments, thus a CC
> reaction is needed *in this window*.
> Or, B ignores the indications from TSopt/SACK - reduces cwnd (either due
> to ACE incrementing, or the dupack trigger and retransmits D1.
> If B does ignore TSopt - it likely has no notion of the Window during
> non-data flights of segments. Thus a cwnd reduction due to DupAck is
> probably the ONLY trigger for the required CC reduction.
> Or B does use auxilliary information like TSopt, flight in
> segements/expected ACKs, to drive the AccECN-based CC-reduction - and
> would not mistake these ACE-incrementing ACKs as dupacks, as they belong
> to a flight before D1 could have arrived.
> However, from a CC perspective, the outcome (actual cwnd reduction) is
> correct. Only from a efficiency perspective, an undue retransmission
> could have been saved.
> (And we are still talking about a pathological situation, where suddenly
> a significant fraction of small ACK packets all get CE marked. In the
> environments analysed for step-marking, the CE-marking during steady
> state is 2 marks per window, which is lower than the threshold of 3 in
> (B). Using a higher n in (B) would further reduce the risk of spurious
> retransmission, as the higher risk of desynchonization of the CE.p
> counters between the endpoints

Yes, I think the logic works.
My point was that we had better have something to mitigate dupack effects
caused by acking pure acks.
Since the logic above does the job, I am fine with the logic if it's
mentioned in the draft.

Also, I think we might want to mention that this logic overwrites the
presumptions in RFC5681 in the draft.
Because RFC5681 suggests receiving a dupack packet can be considered as an
indication of arrival of data
segment at the other side.