Re: [tcpm] Possible error in accurate-ecn

"Scheffenegger, Richard" <rs.ietf@gmx.at> Wed, 24 February 2021 10:03 UTC

Return-Path: <rs.ietf@gmx.at>
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 8C0AC3A1352 for <tcpm@ietfa.amsl.com>; Wed, 24 Feb 2021 02:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 XuQ-ICq9WuHt for <tcpm@ietfa.amsl.com>; Wed, 24 Feb 2021 02:03:37 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 D35B43A1333 for <tcpm@ietf.org>; Wed, 24 Feb 2021 02:03:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1614160959; bh=YvRj7v3gniIBF2PTJRISF6mRiVEoNo4d6lRzCQzR/II=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=D2FdJ34wGz0PMvQfSFqX3AV+T4O3t4/in7uCvLtaY3hswpx9OKwzXY+IEYL38BZ38 dISm71elxmofgxKneDzZgY9FKIvijYbkY1AMN/C3m29EwM0O+sBbgB5lfiAbeBDbpv T7KORm33fr6qnhqLgJB412X9lAxMR1wW9YWbCWWg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.199] ([178.165.130.59]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N0G1d-1m06C80xSZ-00xNcB; Wed, 24 Feb 2021 11:02:39 +0100
To: Bob Briscoe <research@bobbriscoe.net>, Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: tcpm IETF list <tcpm@ietf.org>, Richard Scheffenegger <rscheff@gmx.at>, Yoshifumi Nishada <nishida@sfc.wide.ad.jp>
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>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <042d369a-ac8e-4b4a-df36-a3dc7811f64a@gmx.at>
Date: Wed, 24 Feb 2021 11:02:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <bd6ab65d-ccd5-9fa9-58be-6d9fea4af870@bobbriscoe.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:laze/FOM3o0mkNeCzSlWwdScEchTtOGAah8U8lA4VXf70eCjwdk bdMYojzDFYxKd0txXleUovdUJtmSheQWMJtQWwt2kY5vis1SwYSxARwB5/kCjbv2vHB05lm lO+/512Fq16zBwgzMFqt6dL2vEYsyPMZW8KvsnhGOksy6i5IQL9NL5rHmuk7AICSPaLMKY4 gmiUBH1zMgPuet2werklg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:OATqHj+lnZ8=:MAtPR6o8HsUKA6lfy1apFn Mx+DpcPIrOahg9+GIQixnV+NDO3ZGrezPvPurnVb6Kh+klAaMeO9N9ByiHlM+MvyPan1lOeYl T7AcPPbUCxpf40Qf90GW/SBOtPEM4MJxAQf4jyuomFTuoMD9G+LjY7xbPbnfIKNmy7KrvRvA2 yuHWJezpICyQsD4JdGRqeQMoYM2MyNAOf7/VGeU7UvNCHAJ0iXw+mv4Y2PaFlp8LX2G5hzAdx 5K+7Q+JXGIphvSY0We0LVK2wGu1T7PPLgEeZeQHi6m9hdBY4CueCnKpjZaOQ2PodBgt2HPtz6 /mlSXAMJmqiPadHIqHBTMx1QorlPSEmsfh9QrOFL7OLtQRgE+u9p1FLnEpPgaf6vYvngnsr92 S63i3FNxdLkvKrbgOift3wMYEx/HFtxOwbORdITamFLoDzjWrGxbAeBWncYMziWRpgn0AYQXv pdS9Fw+MYCPWACRjIVF86rVPezpdmW2LOEC7ze7/n7B6MxV6slVJsM6UTb5xV/vH/++HSNG06 B+jghueNpA/1QiDiyymvMxgxJQptc6nRwy3FB0bzlBS1mUYY6Hx3reXEUpSDEX9ASh7Fdb8NS ESK4n+Z6nxQUuc+X0hkR2EGjcVGc3L1aNPB6I+jy7z9HIGDG56eGIzXz7E4+0VFWlmLOQdtpO ARR8im64w0XWrtOxhLlMHP7QJX1csq1R7r90YAbbKROhSUvfSICwcJvNAg7n+pm66bQRxswQn 5oCf0VclZZx/2Gq63dApWqt7xLZe0YChKFA8LWmHOjcfoTegaj5UpnpLhhy/oRBXPLQmMkOye V2xHtNtopYSJKUxWjCkFOeMjZCsDR/UsMPGUDUqq0ILb/0Yr/ABqaLh3QydukidGSMSNPYSor EVq7npy6fcTHpadyOwNg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/B0i-JYo2ZhVTXFwlJGbiGbw9cTA>
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: Wed, 24 Feb 2021 10:03:45 -0000

Hi Bob,

unless there is ACK duplication going on, I don't see how the current
text would cause any issues.

The only aspect I would emphasize is, that in the 2nd case, "n" MUST NOT
be as low as one, as that may cause a ACK-triggering-ACK when the path
exhibits a pathological misconfiguration, where all packets get CE
marked. As long as a smaller numer of ACKs ("n" >= 2) carry a sum of CE
marks seen from received frames, any such pathological paths would
possible trigger a few rounds of ACKs, but these will eventually die
down, correct?


Do you have a different scenario in mind?

Richard



Am 23.02.2021 um 01:12 schrieb Bob Briscoe:
> 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.
>
> However, I'm probably very wrong. Somehow I feel we haven't got a good
> model to check all the possibilities.
>
>
> Bob
>
>
>
> 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/
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> --
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/
>