Re: [tcpm] Possible error in accurate-ecn

Bob Briscoe <ietf@bobbriscoe.net> Tue, 02 March 2021 16:36 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 C2B1A3A1985 for <tcpm@ietfa.amsl.com>; Tue, 2 Mar 2021 08:36:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Level:
X-Spam-Status: No, score=-1.433 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, HTML_MESSAGE=0.001, 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 GpZrObkgmnbK for <tcpm@ietfa.amsl.com>; Tue, 2 Mar 2021 08:36:52 -0800 (PST)
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 CEFEE3A15BA for <tcpm@ietf.org>; Tue, 2 Mar 2021 08:36:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=GF9MJ4VJTYsPqPfxfFRJvgqjOdBgfO+1kNLUzRUsvXY=; b=BUOQNJ1JZ2rIKZ4Uw09Hefdts NOAq+3AyCcmj5kC7PkK0VbGdgZOmfhCP+I1cuF5tWkk28Wl2MM+zmqCU8IfHz57qTd9jL/bi3aDCl l8iSZsoQGfES1lMrHefmG6Q5fcavysv+GrPOm2dNzV4dfwPu/zGnOy21dRj4x1AhZ4KZmIoLYbQgr i6L1c2gY2q1r2O9uRcGhQzdouRAYHuOXb13UB6NVxzFNNbCEE+5FfELaqCQrOWlWJ9hK20diyY74V aQLp0HHprUAbc3/Y3e3HV081//tgI0yCqwGvX8hFkfExA9/Pv276ou9yI4+4GkfARfvPgcqFvWcAS L1H1/YOug==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:42964 helo=[192.168.1.11]) 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 1lH80t-0007Ua-IP; Tue, 02 Mar 2021 16:36:47 +0000
To: Yoshifumi Nishida <nsd.ietf@gmail.com>, "Scheffenegger, Richard" <rs.ietf@gmx.at>
Cc: Mirja Kuehlewind <ietf@kuehlewind.net>, 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>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <ea02b26e-6d10-8a05-4d02-23d2a987310a@bobbriscoe.net>
Date: Tue, 2 Mar 2021 16:36:45 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAAK044RhdAYexcGRj_XDkdY_o6JqB0DDo1X0H2AeFkRcsb0i4A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------22C297BE7C4E69AC99D5DB9E"
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/0ehJtlBy7jqpmvBo-ywmOLwZ1gM>
Subject: Re: [tcpm] 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: Tue, 02 Mar 2021 16:36:56 -0000

Yoshi, Richard,

Am 24.02.2021 um 11:03 schrieb Yoshifumi Nishida:
 > Also, I think it's hard to tell there's no outstanding data from the
 > receiver side.
 > Let's say a sender send some data packets after sending 10 acks, and the
 > receiver sends back 5 acks as the 10 ACKs have CE marks.
 > In this case, they look like dup acks from the sender's point of view.

Let's test whether Richard's suggestion of using SACK is practical. I 
think it is.
As I understand it, the idea would involve:

If SACK has been negotiated.
If an ACK is a candidate for a DupACK (i.e. the ackno has not advanced)
Do not count it as a DupACK if there is no SACK on it.

The question then arises: how do we recommend this extra test in the 
draft? Because it's nothing to do with AccECN itself.
I guess after the bullet about 'n' CE marks, we say something like:

"This raises the possibility that an AccECN implementation will 
sometimes ACK pure ACKs, which in turn might be mistaken for duplicate 
ACKs (in scenarios where TCP peers take turns to send groups of data 
packets). To prevent spurious transmissions in such circumstances, if 
SACK has been negotiated, an implementation could assume that an ACK is 
not a Duplicate ACK if it has no SACK option, which would indicate it 
was an ACK of an  ACK."

That doesn't give a solution if SACK has not been negotiated, but:
     * The AccECN draft already recommends AccECN is implemented 
alongside SACK
     * Not implementing SACK is already unusual;
     * Yoshi's scenario is unusual in itself
     * The impact of Yoshi's scenario would be a spurious retransmission,
So, we have possible spurious retransmissions if an usual traffic 
pattern occurs in an extremely unlikely and not recommended combination 
of implementations. Can't we live with that?


Bob


On 01/03/2021 21:07, Yoshifumi Nishida wrote:
> Hi Richard,
>
> Thanks for the comments. I also think both a) and b) can mitigate the 
> concerns I mentioned.
> Although I'm not sure if this is the best solution or not yet, it 
> looks certainly better to me than the previous ones.
> --
> Yoshi
>
> On Wed, Feb 24, 2021 at 10:33 AM Scheffenegger, Richard 
> <rs.ietf@gmx.at <mailto:rs.ietf@gmx.at>> wrote:
>
>
>     Hi Yoshi,
>
>     A valid concern. Two ways to remediate these at least to some extent:
>
>     a) used a "n" higher than 2 (e.g. 6)
>     b) refrain from sending the ACK for n CE immediately, but hold off for
>     either the delayed ack timeout, or the n+1'th receipt of CE, or a
>     valid
>     data segment by that time.
>
>     While this would not fully rule out any possibilty of an inadvertend
>     DupAck, it significantly reduces the time window when this may happen.
>
>     Also, if an implementation uses other clues (e.g. TS opt, SACK
>     negotiated but not present in the ACKs incrementing the CE.P ),
>     ambiguity can be further reduced.
>
>     However, I feel that these optimizations may overburden the definition
>     of the mechanism.
>
>     Best regards,
>         Richard
>
>
>
>     Am 24.02.2021 um 11:03 schrieb Yoshifumi Nishida:
>     > Hi Bob,
>     >
>     >
>     > On Mon, Feb 22, 2021 at 4:12 PM Bob Briscoe
>     <research@bobbriscoe.net <mailto:research@bobbriscoe.net>
>     > <mailto:research@bobbriscoe.net
>     <mailto:research@bobbriscoe.net>>> wrote:
>     >
>     >     Mirja, Richard, Yoshi,
>     >
>     >     I just posted a new rev of AccECN for a number of other
>     reasons, and
>     >     realized we hadn't converged on an answer to the tricky
>     problem in
>     >     this old thread from Nov'20. For now, the text says the
>     following
>     >     (which I've justified below, but I don't think it's the solution
>     >     yet), and I've asked Richard & Mirja if we (as co-authors)
>     can act
>     >     as a little design team to thrash out this problem in the
>     next few days.
>     >
>     >     3.2.2.5.1.  Data Receiver Safety Procedures
>     >
>     >         An AccECN Data Receiver:
>     >
>     >         o  SHOULD immediately send an ACK whenever a data packet
>     marked CE
>     >            arrives after the previous 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
>     in the range 2
>     >            to 6 inclusive.
>     >
>     >
>     >     Justification for first bullet: The aim is to trigger an ACK
>     on a
>     >     transition from non-CE to CE, but only when the latest
>     packet is a
>     >     data packet. Cases where the previous packet was a CE-marked
>     pure
>     >     ACK and therefore not ACK'd ought to be picked up by the 2nd
>     bullet,
>     >     not the first. Similarly, if there's CE-marked packets (data
>     or pure
>     >     ACKs) that haven't been ACKd yet, and the next data packet
>     is not
>     >     CE-marked, I think the first bullet is still correct, and
>     the second
>     >     rule will pick up cases with enough CE marks.
>     >
>     >     The second bullet is more tricky. I've added Richard's
>     suggesting of
>     >     flooring 'n' at 2. But made no other changes. That's deliberate,
>     >     'cos I think it's sufficient to allow ACK CC to be added,
>     but not to
>     >     preclude it. And I think the danger of being interpreted as
>     DupACKs
>     >     shouldn't apply if there's no outstanding data. I know I'm
>     wrong in
>     >     those odd cases I mentioned when new data might cross the
>     ACKs in
>     >     the other direction. But I don't think that's going to cause too
>     >     much harm.
>     >
>     > This might be too pathological, but I'm thinking about a certain
>     extreme
>     > example..
>     > In my understanding, let's say a node sends 50 ACKs for some
>     reasons and
>     > all ACKs have CE marks, then its peer sends back 25 ACKs.
>     > If these 25 ACKs have CE marks as well, it can generate another
>     12 ACKs,
>     > and so on.
>     > If this understanding is correct, I'm not sure if this is a good
>     behavior.
>     > I am thinking we had better do something here such as don't send
>     an ACK
>     > if the correspond ACKs carries accecn signals.
>     >
>     > Also, I think it's hard to tell there's no outstanding data from the
>     > receiver side.
>     > Let's say a sender send some data packets after sending 10 acks,
>     and the
>     > receiver sends back 5 acks as the 10 ACKs have CE marks.
>     > In this case, they look like dup acks from the sender's point of
>     view.
>     > I know this is a rare case, though.
>     >
>     > --
>     > Yoshi
>     >
>     >
>     >
>     >     On 17/11/2020 08:48, Scheffenegger, Richard wrote:
>     >>
>     >>     See my suggestion; The critical requirement for the 2nd bullet
>     >>     point is,
>     >>     to have n > 1 for pure, CE-marked ACKs. The exponential decay,
>     >>     after how
>     >>     many ACKs triggered by CE-marked ACKs these ACK-for-ACK stop,
>     >>     strongly
>     >>     depends on "n", so the recommendation should be to use a higher
>     >>     value of
>     >>     n in the case where you only observe a stream of pure ACKs
>     (with or
>     >>     without marks; only those marked would account against "n"
>     though).
>     >>
>     >>     In the case of data packets mixed in, you don't want to delay
>     >>     excessively, thus "n" may be choosen lower...
>     >>
>     >>     Richard
>     >>
>     >>
>     >>
>     >>     Am 10.11.2020 um 17:38 schrieb Bob Briscoe:
>     >>>
>     >>>     Moving on to the second bullet...
>     >>>>>     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?
>     >>>>     [MK] 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.
>     >>>
>     >>>     [BB] By the end of your last para you start to realize
>     that, if
>     >>>     the n'th
>     >>>     CE mark arrives on pure ACK, it doesn't say anything about
>     >>>     whether the
>     >>>     previous (n-1) CE marks were on data or pure ACKs.
>     >>>
>     >>>     Consider another common scenario; a server delivering
>     chunks of
>     >>>     video
>     >>>     over a high BDP path (e.g. 500 packets per RTT), and going
>     idle
>     >>>     between
>     >>>     times (perhaps in response to an "exceeded high watermark"
>     data
>     >>>     packet
>     >>>     from the server). Now consider the possibility that the
>     reverse path
>     >>>     bottleneck builds a queue during each chunk, and starts CE
>     marking
>     >>>     towards the end of each chunk. Then, after the server stops
>     >>>     sending a
>     >>>     chunk, it continues to see a couple of hundred CE-marked
>     pure ACKs
>     >>>     arriving.
>     >>>
>     >>>     However, by your proposed rule, it doesn't send any feedback,
>     >>>     'cos it
>     >>>     has no data to acknowledge. So the client cannot regulate
>     its ACK
>     >>>     stream. That's just tough, 'cos the client will stop
>     sending more
>     >>>     pure
>     >>>     ACKs after it has received the last data, which is before
>     any later
>     >>>     feedback from the server can reach it.
>     >>>
>     >>>     However, if the client later sends a data packet that the
>     server can
>     >>>     acknowledge (e.g. "a low watermark" message), the server's ACE
>     >>>     counter
>     >>>     will have wrapped dozens of times, and the client won't be
>     able
>     >>>     to work
>     >>>     out how many. That doesn't matter if a few round trips have
>     >>>     elapsed -
>     >>>     the congestion info will have become stale. But it does
>     matter if
>     >>>     it's
>     >>>     fairly soon.
>     >>>
>     >>>     Instead, if we keep the text of the second bullet... if the
>     >>>     server's 'n'
>     >>>     was 2, it would send a pure ACK for every other pure ACK it
>     >>>     received.
>     >>>     But, what if these pure ACKs from the server were also
>     CE-marked?
>     >>>     Then
>     >>>     the client would feed back pure ACKs using its 'n'. This
>     regression
>     >>>     would eventually die out, but I don't like it.
>     >>>
>     >>>     This conversation about the second bullet presumes AccECN is
>     >>>     being used
>     >>>     for ACK congestion control. I'm not comfortable with writing
>     >>>     anything
>     >>>     specific about ACK congestion control into a draft on the
>     standards
>     >>>     track. But I don't want to preclude AccECN being used for
>     ACK CC.
>     >>>
>     >>>
>     >>>     I believe the second bullet needs something changed to
>     limit the
>     >>>     ACKing
>     >>>     of pure ACKs. However, before we put effort into wordsmithing,
>     >>>     I'd like
>     >>>     to hear whether you agree with the general idea of not
>     defining
>     >>>     what to
>     >>>     do for ACK CC, but not precluding it.
>     >>>
>     >>>     Cheers
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>     Bob
>     >>>
>     >>>>
>     >>>>     Mirja
>     >>>>
>     >>>>
>     >>>>
>     >>>>>     Thoughts anyone?
>     >>>>>
>     >>>>>
>     >>>>>     Bob
>     >>>>>
>     >>>>>     --
>     >>>>>
>      ________________________________________________________________
>     >>>>>     Bob Briscoe
>     >>>>> http://bobbriscoe.net/ <http://bobbriscoe.net/>
>     >>>>  _______________________________________________
>     >>>>     tcpm mailing list
>     >>>> tcpm@ietf.org <mailto:tcpm@ietf.org> <mailto:tcpm@ietf.org
>     <mailto:tcpm@ietf.org>>
>     >>>> https://www.ietf.org/mailman/listinfo/tcpm
>     >>>>     <https://www.ietf.org/mailman/listinfo/tcpm>
>     >>>
>     >>
>     >>     _______________________________________________
>     >>     tcpm mailing list
>     >> tcpm@ietf.org <mailto:tcpm@ietf.org> <mailto:tcpm@ietf.org
>     <mailto:tcpm@ietf.org>>
>     >> https://www.ietf.org/mailman/listinfo/tcpm
>     >>     <https://www.ietf.org/mailman/listinfo/tcpm>
>     >
>     >     --
>     >  ________________________________________________________________
>     >     Bob Briscoehttp://bobbriscoe.net/ <http://bobbriscoe.net/>
>     <http://bobbriscoe.net/>
>     >
>     >     _______________________________________________
>     >     tcpm mailing list
>     > tcpm@ietf.org <mailto:tcpm@ietf.org> <mailto:tcpm@ietf.org
>     <mailto:tcpm@ietf.org>>
>     > https://www.ietf.org/mailman/listinfo/tcpm
>     >     <https://www.ietf.org/mailman/listinfo/tcpm>
>     >
>

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