IETF Logo Mail Archive

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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 10 July 2018 04:56 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 3370B130DDB for <quic@ietfa.amsl.com>; Mon, 9 Jul 2018 21:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ddr9W6iHYfGG for <quic@ietfa.amsl.com>; Mon, 9 Jul 2018 21:56:20 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2605E130EF8 for <quic@ietf.org>; Mon, 9 Jul 2018 21:56:19 -0700 (PDT)
Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2E2522786CF for <quic@ietf.org>; Tue, 10 Jul 2018 13:56:18 +0900 (JST)
Received: by mail-it0-f54.google.com with SMTP id y124-v6so13749336itc.0 for <quic@ietf.org>; Mon, 09 Jul 2018 21:56:18 -0700 (PDT)
X-Gm-Message-State: APt69E1s3obYtpkFBEZZpJwuJV+iOPj+K9hRv8veANP2z5rpNra57VPB yEhSxIw9nyl1Cvzwkvb63mDfttHbGjij02f5c/k=
X-Google-Smtp-Source: AAOMgpeTp1aPuZgifSn9iq30pVt9uC+g3D2ynp4zTRQYONA72XKr6qubwm8qe6TZDqxvVfsi9uSbVFHyAyCcpjRhpeY=
X-Received: by 2002:a24:7893:: with SMTP id p141-v6mr9839304itc.20.1531198574069; Mon, 09 Jul 2018 21:56:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 21:56:13 -0700 (PDT)
In-Reply-To: <CAKcm_gPVzpo0ES8eSNdNaLxqbN_p1O9a=Qes=hMNf0Yw0ZWuLA@mail.gmail.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>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Mon, 09 Jul 2018 21:56:13 -0700
X-Gmail-Original-Message-ID: <CAO249yfZyKpZ+itq7ERGJq34mUXa8iG=+PiEaF1400muc5daNQ@mail.gmail.com>
Message-ID: <CAO249yfZyKpZ+itq7ERGJq34mUXa8iG=+PiEaF1400muc5daNQ@mail.gmail.com>
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Cc: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, pravb=40microsoft.com@dmarc.ietf.org, "Lubashev, Igor" <ilubashe@akamai.com>, Christian Huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/LIjlzl7JYBYIL1itadel8_bNKVU>
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 04:56:23 -0000

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

v2.23.0 | Report a Bug | By Email