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

Bob Briscoe <ietf@bobbriscoe.net> Fri, 19 March 2021 17:07 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039CC3A1A80 for <tcpm@ietfa.amsl.com>; Fri, 19 Mar 2021 10:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Level:
X-Spam-Status: No, score=-1.434 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHd74RtBeOAf for <tcpm@ietfa.amsl.com>; Fri, 19 Mar 2021 10:07:44 -0700 (PDT)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB3A3A1A7F for <tcpm@ietf.org>; Fri, 19 Mar 2021 10:07:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ALhRAjnzKXHmAVb56ixP2cP39y9XhSac2wTtA02B9Mw=; b=5wHZwD14p83k60P3tVb2XBmD45 TkzSELr+QmcnHMmcr9QrjctvoElMAkx+k4GGz9M43LRmDYbtZJoaNSyroDz177RRcm2USz1kM5zxl aCn7VjqbvNAq5wqcJgOLEQ8cc//MhMGVI4//OuE4lVzB3EM0mYFzE+yzjW7XoPQ5Ww27yO2PRCKBl h71JhoxgVGqnPOfD2yo+nyEhC+vt5iEoTYe4Pv3/UK091GiNrlM1zEj8eY354c1iaVVrGpksm1YrB 4FAjcY4bBzlS4YI77ZusqNcheQL1Rp3wHiPl6d3bNKto0IMQEFM5loIBIx2oXQJu/J6n3dVsp5+g0 915PI1NQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:40622 helo=[192.168.1.9]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1lNIb4-0008Aa-Vn; Fri, 19 Mar 2021 17:07:39 +0000
To: Mirja Kuehlewind <ietf@kuehlewind.net>, Yoshifumi Nishida <nsd.ietf@gmail.com>
Cc: Yoshifumi Nishada <nishida@sfc.wide.ad.jp>, tcpm IETF list <tcpm@ietf.org>
References: <47df9b8b-515e-d40d-3473-599b0a3e3876@bobbriscoe.net> <6031BE2B-4D33-426F-BA17-DDF15CF821DE@kuehlewind.net> <060c8bd8-d64b-3e46-7874-742e35e6d114@bobbriscoe.net> <221e58f3-ada0-c880-db72-d98af84fedb8@gmx.at> <bd6ab65d-ccd5-9fa9-58be-6d9fea4af870@bobbriscoe.net> <CAAK044QgF4pz5Wamnxkobthou5ac4_LBxh8=nBYWyOxQUtcW-Q@mail.gmail.com> <8151fdef-ae78-80f3-adfc-d40db878ac8e@gmx.at> <CAAK044RhdAYexcGRj_XDkdY_o6JqB0DDo1X0H2AeFkRcsb0i4A@mail.gmail.com> <48c5910d-5340-acd6-8fd9-fff1b7758310@bobbriscoe.net> <CAM4esxTiw7_es60DDK2E1wa3-c1nUD2W_Rf7Fhw5u0qJ0bFQpg@mail.gmail.com> <8275e3ff-24af-7f0c-d251-867673503741@gmx.at> <631a3f3d-52e1-68c0-8b5f-ce41b30d2e7f@bobbriscoe.net> <48BF06D1-F362-450F-9F89-6DAC6E96B1AC@kuehlewind.net> <CAAK044Q4NOMM2ymuCY4n-HwJOCSFsso4DTkpGgLN=cJUAyW1Vw@mail.gmail.com> <847A6D2D-F532-4C87-9AE1-25A11F33CE87@kuehlewind.net>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <2686f6f8-740e-a648-5f97-8adb3b15dc88@bobbriscoe.net>
Date: Fri, 19 Mar 2021 17:07:38 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <847A6D2D-F532-4C87-9AE1-25A11F33CE87@kuehlewind.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/U0yaa2FKPJJC9gd98HtP0uj0mak>
Subject: Re: [tcpm] Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Mar 2021 17:07:46 -0000

Yoshi & Mirja,

On 17/03/2021 18:01, Mirja Kuehlewind wrote:
> This is a corner concern case; and you shouldn’t retransmit a second time if more dupACK are received within the next RTT.
>
>
>> On 17. Mar 2021, at 06:47, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
>>
>> Hi Mirja,
>>
>> On Tue, Mar 16, 2021 at 9:50 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
>> 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 (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.
>> 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)

[BB] To summarize, the picture is something like slide 6 here except one 
of the early CE-marked ACKs from Y to X is a data packet:
https://datatracker.ietf.org/meeting/110/materials/slides-110-tcpm-draft-ietf-tcpm-accurate-ecn-00#page=6
We'll call the left and right hosts X and Y.

Unlike in the previous case that you described, in this case Y receives 
more DupACKs than the number of packets it sent since its last ACK'd 
data packet. I started thinking of ways to check for this, but I quickly 
came to the conclusion that we should not try to add logic to check for 
that.


Before we say this is a corner-case, I'd like to try to generalize it, 
to understand how broad it might be.

* It might involve one or more packets from Y to X being lost (or delayed).
* And there might have been some data packets from Y to X delivered 
after the gap, which would each have triggered a (genuine) DupACK of the 
seqno before the gap.

Also, all these cases generalize to loss detected in time (like RACK) 
not just counting DupACKs. When data from Y to X ends, ACKs from X to Y 
continue for a round trip. If many are CE-marked, rule (B) triggers ACKs 
of the ACKs later in the round. For instance, if RACK tolerates 
reordering for RTT/8 (say) then ACKs of ACKs in the last 7/8 of the 
round could be considered DupACKs, if the conditions of these corner 
cases are in place.

I still think we can categorize all these as corner cases. but we are 
finding quite a few corners.

Nonetheless, I think it is still simpler to use the wording of alt (B) 
as it is, and leave these corner cases as potential cases where DupACKs 
might occasionally be wrongly detected. But just live with that.



Bob

>> --
>> Yoshi
>>
>>
>>   

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/