IETF Logo Mail Archive

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

Praveen Balasubramanian <pravb@microsoft.com> Tue, 10 July 2018 16:15 UTC

Return-Path: <pravb@microsoft.com>
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 85162131008 for <quic@ietfa.amsl.com>; Tue, 10 Jul 2018 09:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 Jjf6vUTPj6oU for <quic@ietfa.amsl.com>; Tue, 10 Jul 2018 09:15:35 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0101.outbound.protection.outlook.com [104.47.36.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C46B131012 for <quic@ietf.org>; Tue, 10 Jul 2018 09:15:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VQiBW/TzpJb+zUhkF0zTz+F2BFpOxlsL661ZjtUIJII=; b=k/yGNR9Ba+GOQbLVbxWidxDXMO5qbtqKrFGu44oIXIxb4TL6lLK8BR1acAhynUdIH1RYrYP0yGYekar5P7bMCpn4cAZmgLamFiaQUf7iirrdmXAyBG0ZK+8K3yPyF+DOiI0l2hmWA/SiGcfw63K1efL+DWvtcaMfnadBQey1Mlk=
Received: from MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) by MWHPR21MB0639.namprd21.prod.outlook.com (10.175.141.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.6; Tue, 10 Jul 2018 16:15:32 +0000
Received: from MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::9433:e5c:b9af:1b72]) by MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::9433:e5c:b9af:1b72%9]) with mapi id 15.20.0952.017; Tue, 10 Jul 2018 16:15:32 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Ian Swett <ianswett@google.com>, "nishida@sfc.wide.ad.jp" <nishida@sfc.wide.ad.jp>
CC: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, "Lubashev, Igor" <ilubashe@akamai.com>, huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Subject: RE: Speeding up tail loss detection (Re: Congestion control algorithm questions)
Thread-Topic: Speeding up tail loss detection (Re: Congestion control algorithm questions)
Thread-Index: AQHUECByHqG/zftGOUq9fkJj1zXpE6R4KKgAgAJn9ICAAAA6YIAADpYAgA0PegCAAEWAgIAAlkmAgAAm+6A=
Date: Tue, 10 Jul 2018 16:15:31 +0000
Message-ID: <MWHPR21MB0191444EDC54BDB409AF728AB65B0@MWHPR21MB0191.namprd21.prod.outlook.com>
References: <CANatvzwoHL1_MtkHM53+PKhR8Rs52Y2y=mVt+f5kFwpDGTNn2Q@mail.gmail.com> <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> <CANatvzy5JvUOqkhdFzutskWC9fpKxdByHXjaW5AhCo78BX69GA@mail.gmail.com> <MW2PR2101MB1098869CB84F0FD75A52E961B64C0@MW2PR2101MB1098.namprd21.prod.outlook.com> <CAN1APdeb49OyOYSfviOqTuEow53aEGT7czt9jY4Cn0chaBKJyQ@mail.gmail.com> <CAKcm_gPVzpo0ES8eSNdNaLxqbN_p1O9a=Qes=hMNf0Yw0ZWuLA@mail.gmail.com> <CAO249yfZyKpZ+itq7ERGJq34mUXa8iG=+PiEaF1400muc5daNQ@mail.gmail.com> <CAKcm_gPTzO3F_suNwXVXNuDT+09QHjooUEsDP6rWPwCBe8d4Lg@mail.gmail.com>
In-Reply-To: <CAKcm_gPTzO3F_suNwXVXNuDT+09QHjooUEsDP6rWPwCBe8d4Lg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:2:f034:4043:b2ae:fd53]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0639; 7:jbk3QVyZ7SadpC4V6/Qqf382kaK8MOx1Mm+eSF5xMO9YQOYMciPPUvVagAVRIXqJqE2MwF6SK9lVWUvNZSe8TJxEzQm9s3PbiJ/+HIF4pwwBNumIicjLrxBiCB7nwYW1N93coDrILqeqdD9uXQmwOnyPZlxzm2vL4IC6S6Kh09KUjQEOxzLxUh95mtwUgq+przJIuQvfn4ytM/08uy5V5EmpvB83Vo1A0mkKqrvGyUzdPgEK/Exhuq+6bkibNnS9
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: dd7596a7-ac0e-4ca3-dfaa-08d5e6805c40
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:MWHPR21MB0639;
x-ms-traffictypediagnostic: MWHPR21MB0639:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <MWHPR21MB0639084479778B75194D0C25B65B0@MWHPR21MB0639.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(211936372134217)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(2018427008)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR21MB0639; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0639;
x-forefront-prvs: 0729050452
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(136003)(366004)(376002)(39860400002)(346002)(189003)(199004)(51854002)(7696005)(86362001)(2501003)(53546011)(4326008)(6506007)(6246003)(76176011)(46003)(102836004)(25786009)(53936002)(256004)(105586002)(93886005)(22452003)(316002)(97736004)(10090500001)(54906003)(14444005)(110136005)(86612001)(186003)(99286004)(2900100001)(106356001)(5250100002)(39060400002)(8936002)(10290500003)(2906002)(476003)(790700001)(229853002)(68736007)(6116002)(478600001)(33656002)(446003)(9686003)(81156014)(8676002)(81166006)(236005)(19609705001)(7736002)(14454004)(6436002)(55016002)(6306002)(54896002)(8990500004)(11346002)(5660300001)(74316002)(486006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0639; H:MWHPR21MB0191.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 9YT0Sjd3DllX1PurkoOBICDadlDHoXZku7/jriZ/SW80MpROsiLpOmKicKgG+rHHjqTMtJT8ZYMXSQtk9xGYCz6a9GBc+NzJCK4JvwRn5/lhFZWRCCydoqD8csCwPgs87untQ/pW7KwuBM7PQ3pP/x8kAhS3U5y0qjwuGpAfpYiCapCl284Ilp+aEZNYpWEE/fRq3O7yFGMryWXifMHsFb/6pwRtnU4fkxBbMoJP/+tCjwe+3K+/JVjGLFzA58HWoVIRCftc75ZW6Y7hl6AdS1Gz/17wJIeQCM/hsGxcB5iUNHGqR9F7R+aaN8HtMH8fnMRH+radWo6byPSKveN990rZP3DM7gDLd+URVusutFw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0191444EDC54BDB409AF728AB65B0MWHPR21MB0191namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd7596a7-ac0e-4ca3-dfaa-08d5e6805c40
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2018 16:15:31.9860 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0639
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_RurGs_65_T7SL-AsE3MqFC33KE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 10 Jul 2018 16:15:39 -0000

Requiring immediate (not explicitly delayed) ACK for PING frame at least once per RTT (or even always) seems fine to me. In the crucial recovery cases TLP will be out of order and will elicit an immediate ACK anyways. If there are ways to speed up recovery let’s experiment and bring them to the draft, they might help TCP as well.

From: Ian Swett [mailto:ianswett@google.com]
Sent: Tuesday, July 10, 2018 6:54 AM
To: nishida@sfc.wide.ad.jp
Cc: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; Lubashev, Igor <ilubashe@akamai.com>; huitema <huitema@huitema.net>; IETF QUIC WG <quic@ietf.org>; Kazuho Oku <kazuhooku@gmail.com>
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)

To summarize my current thinking: I'd like to add/change something in QUIC that allows experimentation in this space.  Ideally this would be in the near future(before v1), so we can understand if it's valuable and provide a well-reasoned recommendation in the recovery doc.

The fast ACK after PING approach seems simple enough to me, but I'm open to other suggestions as well.

On Tue, Jul 10, 2018 at 12:56 AM Yoshifumi Nishida <nishida@sfc.wide.ad.jp<mailto:nishida@sfc.wide.ad.jp>> wrote:
On Mon, Jul 9, 2018 at 5:47 PM, Ian Swett
<ianswett=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>> wrote:
> This has been discussed on and off for a few years now, even prior to the
> IETF process.  It's never been clear that adding a frame for this purpose,
> or altering the behavior of an existing frame(ie: PING or STREAM) is
> valuable.
>
> I'm about to start an experiment to send an ACK more quickly(ie: 1ms delay)
> if it's been over an RTT since an ACK has been sent, which may help, but is
> largely aimed at the TLP and RTO use cases.  One use case that's been
> discussed is sending a fast ack frame/signal when entering an app-limited
> phase.  This seems fairly promising to me, but I have no experimental
> evidence it actually helps.

If it's mainly aimed at the TLP and RTO, I'm not very sure if this is
really effective.
For TLP and RTO cases, I guess the speed will depend on how fast
sender sends a probe packet (while avoiding redundancy) rather than
how fast receiver sends an ack.
--
Yoshi

v2.23.0 | Report a Bug | By Email