Re: [tcpm] Possible error in accurate-ecn

"Scheffenegger, Richard" <> Tue, 17 November 2020 08:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDAAD3A09D4 for <>; Tue, 17 Nov 2020 00:49:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1OFD8j0GAL0z for <>; Tue, 17 Nov 2020 00:49:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 96F493A09CC for <>; Tue, 17 Nov 2020 00:49:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1605602917; bh=xwu0iXqJHP+Xd5uskTjFYjNxiH1/nzsh11gMcf1tKvQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=YGRhimzuq48y+1X2KCcNBJGKkTV+rKH17a9QpUjc3PHwfOfCsVXsKq2wS6qHAWU5h 4+eudtPxlOzfUV5vzPWj8XJ6VbbSSzxbLnaii+O7Nf31fbBbvRomTScqA2HOb/BjuH DaSoIy+4Q6/YTQKRUSXPRy707dTyDyvc1Tjot6Q8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1MsYqp-1kOdw62SMN-00u3wK; Tue, 17 Nov 2020 09:48:37 +0100
To: Bob Briscoe <>, Mirja Kuehlewind <>
Cc: tcpm IETF list <>, Richard Scheffenegger <>
References: <> <> <>
From: "Scheffenegger, Richard" <>
Message-ID: <>
Date: Tue, 17 Nov 2020 09:48:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:rcQYiq6JKbF6q8nJpW71oaMXAqvP7ZY9EmR/iBMcVkfTQRef4Al yRlY7Skx9iaudKfFqADDoHgJj9iXZkXADiEkg7QzEOuRuSLWPl7LHx07cgydJl7zZHoE+vU rKanT6e+KZDxr/vQPZnWuo6ICmQOYR2Sv0OjbfYwPk39PpoTGfgp+T8xa4CpzQ+P7MTijOd 4jkY8tDfoPhTsAUQ2r6GQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:93U8DJeBd3s=:SBtf/0kY9vDB4sbjRG0LmS pfDF6m7FxyLEpNCTdahAQqx7IQsrMSlVANYFGyNJ1aoaCfUzDi++uqJ0ZGOfTyRaL87j0t7EG shRB7Yht3blWFhhMIEfO1GQJxekb1ZxG4PPu6ioV7mS3qVqFHHGTRbluMZRPRXONS/hJi4p1I L24/JHHI1qUz1WqewAL76NT5G3i95u/qi+PzdRjnB4W03KX1JJAPRE8F42C42q3rnt9KQZu6N OmCZENZ8umJmSykbPD7Sno3YS6T5mTbL3DRQN/rJXRDo9zWdzqVaxxqxAOn+RHeXPM1E4SzPt MB4r1EPFiDBgDDfNmss9DbYIvSdz88IH1zPKGOyolWtjQxOkPPwtJW7gJsL4oTdApvoALb0jg DB+sTXzllrOhNUbw1m6dzXd32hQkNd/yjUbz+39i2N3ZMH9PQuA4zgxWs1jaSKcKWJ5hRciHd pOCUVKpWqvqWGuXhIWt991OL5UYdcDLbJBSRSWtNYHSfhnnXWWJSqbJtNzLXjith9P0fvnhJu zBApYFurNRVAXrxaUJhJZSuuGosHs502+mPJwZvskk+jM7rKiSN4L9ovcuvKaxzEMCV7NfkfT YN7Mo+ZQbSUzNELuJUfwC14UEQOwMZBPcB24gdiBPKoBpkuA5sfUMSdBfc4N/yyrOSW+GRBVZ u/RK933ty38Du2w8rm/oSEk1LZPDECfWhajf7sYOP/sBTy4S/ctvXtIMw3gIggAiu9Cf3fHAU iGwXhSZxNxQ0HnQDVwDQgHl4yz7UAOtN5x83SopoYpRjxK7ZIpLvoY0rgO4lFu82mF0/7macG QaKESL6dPrpatueoC8rWKHTVLwQN1F8zrnFCDEzFHXN0HJFhtgvDN/puRrrAKU9rmbsyHF/w1 eaoMIWi+/wYp0aAwTX1A==
Archived-At: <>
Subject: Re: [tcpm] 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: Tue, 17 Nov 2020 08:49:26 -0000

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...


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
>> _______________________________________________
>> tcpm mailing list