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

Ian Swett <ianswett@google.com> Tue, 10 July 2018 00:47 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 6236B127148 for <quic@ietfa.amsl.com>; Mon, 9 Jul 2018 17:47:42 -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 UVAEplGWnEWb for <quic@ietfa.amsl.com>; Mon, 9 Jul 2018 17:47:40 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 59B32130DD6 for <quic@ietf.org>; Mon, 9 Jul 2018 17:47:40 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id s1-v6so7955101ybk.3 for <quic@ietf.org>; Mon, 09 Jul 2018 17:47:40 -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=AoZqM5+P8AGlqZ/MRvYS8rjDmv2p9lItDw1dKkuJotc=; b=bNbsjsvxKXPN7v47b/CnIk1JOS7s1u3cgkV4UM8nL8ZUEfLS+afsTDSa4Zx3RRvVMF sz7LgCXegXJYgdw8WdWcR+GUXbvZ7lWk0PpQhIhfpQBxeoR4H9BAYUS7hsX9CwzVB/Br yrHk4Us8Wrjp4V4uKBYiD7mgw4SH0QGUM4pdDKZdYpbIgXfnr06zC7gWT8aIUasBLhWg 3XHBdx35EMXsX5jBBZNTuAA1GfHrSdoSCGsu5ghLIki0BvgVJBLeUHz/uL0hrMr+1fll K8RO599OLH2Nh5WBPYldIOWndeYLrRzo2sL2dRC6icKNdzh33iCRa8zODRRLtFJdjzfL WYVQ==
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=AoZqM5+P8AGlqZ/MRvYS8rjDmv2p9lItDw1dKkuJotc=; b=GxlG8SlsAoNUGGU+L5ESDxJQQ129s9O5EQIcpr1JIK0l0Zjfp2Na8YZdCLiRtZ5ukb eAnHkZAJpIdZKUF5ex7ZXBA53m8FLvKggUy6ZL/kMf+GcQliNDaZxuvLS36DHmeIU7CJ 2ZSpeZyKseix74cQO5rMR2i6dqjSGG7zYP3oaGuKccOfnRdon3Mhnst9JDwSzCfIX4NQ r954TPPL8cUc4W/c1tRXkmfuagnlY56jTd8R/3ghPICvFVUneYNHtrq+mxBtL/LY1QD1 lQ7ERMOEckGjFihH1nVV0K9Sabg1+OdGlsZ8YzW+SmH5yEQXEWqgXXhmYbAoV7Neyf0Y RJKQ==
X-Gm-Message-State: APt69E3W2JyIwSjnCRoGLesEc6M1XcJa8UeAVpow9Xwb3jR9ztaBWz0D NVSFtUvgAbrf8TkGTF0rDDNJhtvApQTigOIbIsVYGKVn
X-Google-Smtp-Source: AAOMgpfYvcNSnEYIgReW4lHl+VSQLdxqyLHGRumiwaLiJqcLcWZhkteqoT8gU+Fz62lw29PbHDoab+HwSSnl+rEt05A=
X-Received: by 2002:a25:b3c1:: with SMTP id x1-v6mr11864488ybf.241.1531183659321; Mon, 09 Jul 2018 17:47:39 -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>
In-Reply-To: <CAN1APdeb49OyOYSfviOqTuEow53aEGT7czt9jY4Cn0chaBKJyQ@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Mon, 09 Jul 2018 20:47:28 -0400
Message-ID: <CAKcm_gPVzpo0ES8eSNdNaLxqbN_p1O9a=Qes=hMNf0Yw0ZWuLA@mail.gmail.com>
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Cc: pravb=40microsoft.com@dmarc.ietf.org, "Lubashev, Igor" <ilubashe@akamai.com>, Kazuho Oku <kazuhooku@gmail.com>, IETF QUIC WG <quic@ietf.org>, Christian Huitema <huitema@huitema.net>
Content-Type: multipart/alternative; boundary="0000000000001a5f2e05709a7a55"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Wju6x6xPYDjDDuUvYCLij5wY_Lo>
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 00:47:43 -0000

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.

One option would be to recommend sending an ACK quickly in response to a
PING, unless a PING has been acked within the last RTT.  This would provide
a natural rate-limit to immediate ACKs.


On Sun, Jul 1, 2018 at 1:20 PM Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
wrote:

> On 1 July 2018 at 18..32.56, Praveen Balasubramanian (
> pravb=40microsoft.com@dmarc.ietf.org) wrote:
>
> Doesn’t the PING frame serves this purpose? The language in the transport
> draft isn’t very clear:
> The receiver of a PING frame simply needs to acknowledge the packet
> containing this frame.
>
>
>
> No, I asked for this several times, but there was no traction. It is
> ACK’ed as any packet which the consensus considers soon enough. But I dont’
> think this takes into account use cases with delayed ACK and congestion
> algorithms that can tolerate longer delays.
>
> It’s simply useful to ping in order to get a roundtrip time on the
> connection, aside from what has already been mentioned.
>