Re: [tcpm] Possible error in accurate-ecn
Bob Briscoe <research@bobbriscoe.net> Wed, 11 November 2020 23:18 UTC
Return-Path: <research@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 16ED63A11E2 for <tcpm@ietfa.amsl.com>; Wed, 11 Nov 2020 15:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 qdCor2gp-tvY for <tcpm@ietfa.amsl.com>; Wed, 11 Nov 2020 15:18:10 -0800 (PST)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 932183A11E1 for <tcpm@ietf.org>; Wed, 11 Nov 2020 15:18:09 -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=rnVSJ+MAq3lzBuKg0b3hlcElIRAe5tP8UP8wqhUITrg=; b=GH1YKvBYYoZ1dH5BIlKLIgVfq mHf2u+F0F1ufn2KX4sfuM0giJcQCIa7OgLYhOhKi5iuXE+fNOnUiLxLsxZRSOSOAzvG52TAt7g775 /NPV5/iq5JzV8A+HHIffWOO3tSZPpeETYTufOvxZ6l8QBemT38VRCYdSyAQiVfyTyPXg9Km2OcxFK vb8ZkUkxe08+dDlVWxk77+9KJD51Wv5efYuTjN32zbW5ttsoIT5ikj7SjPlBjjHEEvub85wCeAVvC /fVXTD9sx3/zTzzzAljTWnciz+kIsV74wxouyOmBSf2PkDIl5QD6lJwnRYwkayA7pNZCFrQdxBDmP c+7e9X1zw==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:52594 helo=[192.168.1.11]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <research@bobbriscoe.net>) id 1kczNO-00G3EN-Dy; Wed, 11 Nov 2020 23:18:08 +0000
To: Yoshifumi Nishida <nsd.ietf@gmail.com>, Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: tcpm IETF list <tcpm@ietf.org>, Richard Scheffenegger <rscheff@gmx.at>
References: <47df9b8b-515e-d40d-3473-599b0a3e3876@bobbriscoe.net> <6031BE2B-4D33-426F-BA17-DDF15CF821DE@kuehlewind.net> <CAAK044SDbJHGYrzyv4ipMojEdxPEH4Rnr0AKpGC-n141SuRBYg@mail.gmail.com>
From: Bob Briscoe <research@bobbriscoe.net>
Message-ID: <c194f80a-77ee-a98a-dc5f-a8cbcc5ee49e@bobbriscoe.net>
Date: Wed, 11 Nov 2020 23:18:05 +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: <CAAK044SDbJHGYrzyv4ipMojEdxPEH4Rnr0AKpGC-n141SuRBYg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------9E7A6EE86E3F269E27DD4191"
Content-Language: en-GB
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
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: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/vrdAONqNSJCjVrI2fOMG-Sp8acE>
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, 11 Nov 2020 23:18:13 -0000
Yoshi, On 11/11/2020 09:37, Yoshifumi Nishida wrote: > > > On Tue, Nov 10, 2020 at 2:08 AM Mirja Kuehlewind <ietf@kuehlewind.net > <mailto:ietf@kuehlewind.net>> wrote: > > Hi Bob, > > Please see below. > > > On 10. Nov 2020, at 01:31, Bob Briscoe <research@bobbriscoe.net > <mailto:research@bobbriscoe.net>> wrote: > > > > Mirja, Richard, Ilpo, tcpm list, > > > > I've just been reading through the accurate-ecn draft to > double-check. I think there's a problem with the following text... > > > > 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 [data] 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 no greater > > than 6. > > > > ... > > For the avoidance of doubt, the change-triggered ACK mechanism is > > deliberately worded to solely apply to data packets, and to > ignore > > the arrival of a control packet with no payload, because it is > > important that TCP does not acknowledge pure ACKs. > > > > > > In the first bullet, I think it doesn't matter whether the > previous packet marked CE was a data packet or a pure ACK (i.e we > should remove the second occurrence of 'data' that I have put in > [square brackets]. > > I believe it does matter. If the previous packet was a pure ACK > and was CE marked, you didn’t send an ACK and so you should > immediately send one now. If the previous packet was a data packet > and CE marked, you don’t need to send an immediate ACK because you > already did this with the previous packet. However, it text might > be a but ambiguous because what is meant is “if the previous > packet was a data packet and CE marked”. So this does not apply if > we e.g. have a CE-marked data packets, then a pure ACK that is not > CE marked, and then another CE-marked data packet. > > > > > 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? > > > even though it won't cause an infinite loop, can they be dup acks? If > so, it doesn't look good to me especially when early retransmit is > activated. [BB] I'm not expert in TCP loss recovery but, surely if TCP A has nothing outstanding, it cannot consider receipt of dup acknowledgements from TCP B as a sign of loss? Nonetheless, there would be a chance that such a dup acknowledgement might be in flight when TCP A happened to have just sent some more data, and they crossed in flight. To avoid this case, it would be possible for TCP B to send pure ACK(s) with SEG.SEQ = SND.NXT-1 (using the same trick as keepalive probes). Being out of window, each of these pure ACKs would elicit a further pure ACK from TCP A. However, that would acknowledge SND-NXT, so the loop would stop there. Nonetheless, if TCP B started sending data again, and if TCP B's data crossed the pure ACKs that it had recently elicited from TCP A, once these pure ACKs arrived at TCP B, I think it would treat them as DupACKs. It's seems possible for TCP B to recognize that it elicited these DupACKs from TCP A, and to therefore work out that it could ignore them. I've kept on digging into this particular obscure corner of ACK congestion control, only 'cos I wanted to see if there was a useful end to this hole (so it would be worth the AccECN RFC allowing others to dig there later, rather than ruling it out). Nonethless, the AccECN draft itself doesn't have to go anywhere near this subject - it can leave all that for a potential future draft about using AccECN for ACK congestion control. > 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. > > "can send a pure ack on a pure ack when the ack value advances"? [BB] Yes. That's a fairly safe thing to require. I think the best strategy here is to require an immediate ACK in response to a data packet if there are at least 'n' CE marks to be reported. And to extend that requirement to immediately ACKing a pure ACK if the ACK value has advanced since the last ACK. But just to say nothing about ACKing pure ACKs in other cases, so we don't preclude a case that can be made safe in future (e.g. with something like the keepalive approach above). If you (Yoshi), Mirja and others agree, let's try to work out the wording of this second bullet. Bob > -- > Yoshi -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
- [tcpm] Possible error in accurate-ecn Bob Briscoe
- Re: [tcpm] Possible error in accurate-ecn Mirja Kuehlewind
- Re: [tcpm] Possible error in accurate-ecn Bob Briscoe
- Re: [tcpm] Possible error in accurate-ecn Yoshifumi Nishida
- Re: [tcpm] Possible error in accurate-ecn Bob Briscoe
- Re: [tcpm] Possible error in accurate-ecn Yoshifumi Nishida
- Re: [tcpm] Possible error in accurate-ecn Scheffenegger, Richard
- Re: [tcpm] Possible error in accurate-ecn Scheffenegger, Richard
- Re: [tcpm] Possible error in accurate-ecn Scheffenegger, Richard
- Re: [tcpm] Possible error in accurate-ecn Mirja Kuehlewind
- Re: [tcpm] Possible error in accurate-ecn Bob Briscoe
- Re: [tcpm] Possible error in accurate-ecn Scheffenegger, Richard
- Re: [tcpm] Possible error in accurate-ecn Yoshifumi Nishida
- Re: [tcpm] Possible error in accurate-ecn Scheffenegger, Richard
- Re: [tcpm] Possible error in accurate-ecn Yoshifumi Nishida
- Re: [tcpm] Possible error in accurate-ecn Bob Briscoe
- Re: [tcpm] Possible error in accurate-ecn Yoshifumi Nishida
- [tcpm] Seeking WG opinions on ACKing ACKs with go… Bob Briscoe
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Martin Duke
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Scheffenegger, Richard
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Bob Briscoe
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Mirja Kuehlewind
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Martin Duke
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Martin Duke
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Vidhi Goel
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Yoshifumi Nishida
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Yoshifumi Nishida
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Scheffenegger, Richard
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Mirja Kuehlewind
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Mirja Kuehlewind
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Vidhi Goel
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Mirja Kuehlewind
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Scheffenegger, Richard
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Jonathan Morton
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Yoshifumi Nishida
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Scheffenegger, Richard
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Bob Briscoe
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Bob Briscoe
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Mirja Kuehlewind
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Yoshifumi Nishida
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Bob Briscoe
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Yoshifumi Nishida
- Re: [tcpm] Seeking WG opinions on ACKing ACKs wit… Scheffenegger, Richard
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Praveen Balasubramanian
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Vidhi Goel
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Jonathan Morton
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Praveen Balasubramanian
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Jonathan Morton
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Vidhi Goel
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Jonathan Morton
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Yoshifumi Nishida
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Bob Briscoe
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Christian Huitema
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Bob Briscoe
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Christian Huitema
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Neal Cardwell
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Bob Briscoe
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Ilpo Järvinen
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Neal Cardwell
- Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on … Bob Briscoe