Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)

Christian Huitema <huitema@huitema.net> Sat, 30 June 2018 18:11 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484D3130DE2 for <quic@ietfa.amsl.com>; Sat, 30 Jun 2018 11:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 88TFlJSPedqX for <quic@ietfa.amsl.com>; Sat, 30 Jun 2018 11:11:20 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 222C8130DDB for <quic@ietf.org>; Sat, 30 Jun 2018 11:11:19 -0700 (PDT)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx64.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1fZKL7-0001xO-Hn for quic@ietf.org; Sat, 30 Jun 2018 20:11:18 +0200
Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1fZKL4-0002yS-Q5 for quic@ietf.org; Sat, 30 Jun 2018 14:11:15 -0400
Received: (qmail 19951 invoked from network); 30 Jun 2018 18:11:11 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.74]) (envelope-sender <huitema@huitema.net>) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 30 Jun 2018 18:11:11 -0000
To: Praveen Balasubramanian <pravb@microsoft.com>, "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>, "kazuhooku@gmail.com" <kazuhooku@gmail.com>
Cc: "quic@ietf.org" <quic@ietf.org>
References: <CANatvzwoHL1_MtkHM53+PKhR8Rs52Y2y=mVt+f5kFwpDGTNn2Q@mail.gmail.com> <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> <MW2PR2101MB109824376095324090AA42A7B64D0@MW2PR2101MB1098.namprd21.prod.outlook.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <c4a5f518-36c9-516f-6d8a-b3896bafb8de@huitema.net>
Date: Sat, 30 Jun 2018 11:11:09 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <MW2PR2101MB109824376095324090AA42A7B64D0@MW2PR2101MB1098.namprd21.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------27E8BDA3D3BFD28B4B7C47D6"
Content-Language: en-US
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)
X-Originating-IP: 168.144.250.231
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.11)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5rUD4Qp9YjVuqOEEgZNs8pV602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViG63qURdim96QkovyzVpSTM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBmePYa3CQqb9L6x2mHOMrWx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpXjCYqLkE/yXcDWRb/BCaEznnXm95a0vRtjH3/UwFOlrcpXK5uK/uyK 9WFAc2ArGWK3B+q+bUHXAsYFgsNREGhlzTFYPIyr5voE3ggyv83xvYRfyCMB4QZToA5YKb0SaS5E llm5CBzrwBATJ22MAarYF38+1Ld/o5jGCpWO7tD53U7k+vjbEFIODONvVl7uk83g5QZjLCEoUg1Y y5V2RcC564a1VhBkCngjhrK9f8csxNfH1yALUGC6BHMPRvkcc+0pHUcSPzy/ctQSmDKsmcj89R/2 gMGq0KWAzmMf+ibVDq3MNIorKOYgvz2LkLDi/veqWKEc9MBxZCWS72/wjopIVAY+3RHRetx4B6Z4 Ei5woFss+n2ffnQxt6aJ7klZab+5U3mWTJPTqb+xVIKqgeO7n3iwosDmKSszPVW9RecIRsxn9uie 2n4+ooHGqAOWILQxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/UL2NaSVMsQVpnL8posPoIgzOtVI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jun 2018 18:11:23 -0000


On 6/29/2018 11:26 PM, Praveen Balasubramanian wrote:
>
> All out of order packets elicit an immediate ACK, this applies to QUIC
> the same way it applies to TCP.
>
>  
>
> Section 3.4 of recovery spec:
>
>  
>
>    Out-of-order packets SHOULD be acknowledged more quickly, in order to
>
>    accelerate loss recovery.  The receiver SHOULD send an immediate ACK
>
>    when it receives a new packet which is not one greater than the
>
>    largest received packet number.
>

Yes, but I don't think this is what Ian is looking for. Ian is looking
for something mechanical, "if you receive this signal please send an ACK
right now."

The paragraph that you quote does not achieve that. In it, "SHOULD"
stands for something like "SHOULD unless you think you are smarter than
that." For example, a receiver that experiences lots of out of order
deliveries might replace the last sentence by "when it receives a new
packet which is not X greater than the largest received packet number",
where X is based on an estimate of current out of order deliveries.

Besides, the sender might wish for an immediate ACK for other reasons
than managing out of order deliveries. Precise time management or
checking for connectivity come to mind.

-- Christian Huitema