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

Ian Swett <ianswett@google.com> Tue, 10 July 2018 13:54 UTC

Return-Path: <ianswett@google.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 1CF72130EE3 for <quic@ietfa.amsl.com>; Tue, 10 Jul 2018 06:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Level:
X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ukB0kBYL7fS6 for <quic@ietfa.amsl.com>; Tue, 10 Jul 2018 06:54:20 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1241E130ED8 for <quic@ietf.org>; Tue, 10 Jul 2018 06:54:20 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id j68-v6so7851494ywg.1 for <quic@ietf.org>; Tue, 10 Jul 2018 06:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uqqaOIb1EefjdhSMsj4Z+ts8NWLF6kN5vXqrAT+2dr0=; b=kF4aon83lNejsGCOLL1FKfZ21NGQO/GQJsrljtLlBl+v3B1ik/rMa5Rk5Nnvjgzdu3 yAM32SvUssdfAhbPtGqKwanIHvHaDq0+372reXY853/SPXAilLiF+HBkmpnZeQPBz7gc ET2CZFQ8+tkAGuSuf1ZgjCVJRE7pFLQ2ACW1SvKdJb7r0/4SoHvuhhOt0CgHKol6yWVv 1iGID6MRoL+nlNcNa59u1LBW25Aw58N53yWhleWlOKpL52rIOFex3XlOb3E3MyF/TE2J W9Fu02aA7M0Gg2TyM18A16e1XPlQt3Zj89/jbyVsEsRin0+WbQpAa4K08++cCGyKhQit 8Nlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uqqaOIb1EefjdhSMsj4Z+ts8NWLF6kN5vXqrAT+2dr0=; b=bz99MZX8T9T5ZoQqcYRAs3XiNujHxy8H3eu+njK2e4HDrTUlsNHkU8em5/XliHEmbd WYA5B7+Rv8sn93X0TCJyilGIz7/TU06/C/zwRmh06HeVj5ZioxL7P4WnszMpxg3QQ989 KiC54xn492t1fq0FcL8yMJ0Uj0iNgGFTQiTyskAPa0da7BsEHtx2MKgR/+Ch7abTiXQ4 xGNoux87vYTH+XOuHYgOzBLqx8Nd9fYm9V3604eZioTdjoRK54VoY+xWWYt5X463jIFN HzYMFHXGIHgD3TPpxKIwTm83x+xMu1WAYu5o2GFZY7p7DYj5kzy0rAi8tYGM4bU09tG4 cZog==
X-Gm-Message-State: APt69E0KqkK8CubVrxiSE0La4vyPxKgwq2GnhgrtkECZMnL9hbeVSLPG 5GdSDrkuRRBGCj19dgUPTOm9lBPoukc3MrpbwnW92Q==
X-Google-Smtp-Source: AAOMgpeZEQrSgB183e5YEa5q1JgARh9kqfa/2NneDzyYHq98Uj1KGINQGnoj7GKDThSAFv5+K8oG27vmFKntGuvCN6g=
X-Received: by 2002:a81:b3c1:: with SMTP id r184-v6mr12121403ywh.173.1531230858991; Tue, 10 Jul 2018 06:54:18 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAO249yfZyKpZ+itq7ERGJq34mUXa8iG=+PiEaF1400muc5daNQ@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Tue, 10 Jul 2018 09:54:07 -0400
Message-ID: <CAKcm_gPTzO3F_suNwXVXNuDT+09QHjooUEsDP6rWPwCBe8d4Lg@mail.gmail.com>
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)
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>, Christian Huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000006bdc5c0570a57773"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/9OKf9V57DYyatWHgpUw7H6w6JsU>
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 13:54:22 -0000

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>
wrote:

> On Mon, Jul 9, 2018 at 5:47 PM, Ian Swett
> <ianswett=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
>