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

Kazuho Oku <kazuhooku@gmail.com> Sun, 01 July 2018 16:27 UTC

Return-Path: <kazuhooku@gmail.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 2D0E4130DC8 for <quic@ietfa.amsl.com>; Sun, 1 Jul 2018 09:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OJsTGAjChWg7 for <quic@ietfa.amsl.com>; Sun, 1 Jul 2018 09:27:42 -0700 (PDT)
Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::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 710EE12F1A5 for <quic@ietf.org>; Sun, 1 Jul 2018 09:27:42 -0700 (PDT)
Received: by mail-pl0-x230.google.com with SMTP id s24-v6so6769252plq.6 for <quic@ietf.org>; Sun, 01 Jul 2018 09:27:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=os+OhHKUZubWC6gnApdUQmcYYvGirSAwoIGybUTo0s8=; b=oJPLUMhKtrvbNZ1i9qFhX4SoDMA2XLp4J/QKkTcLi4nJAhbWUdG4jTQYHJbJbko4uq MF1z5KTe6R1PGm38uZeiEsC5NdKLoqB8b892EVqK9pXnrdfpaAiUeFGGrk7IlJUuHGSK fO4s1IAkv9wg3EAcvxOL9U8n52QXJCAm/2SGV0mX/RT4Oy2pnAnyIckmeFdefkiVl1Ed aebA7NKMANjNNWcUIkRrnzfnb8kR4YiIhJz3hmR58tGKf5fIDW1hUGnUnExP3kC+4NRw Fad1gJh7baDa0fM8q/IknRzdLY8pXYTD4M7dMwHqm6oR7t7CdxC/SnOXc7lvlzEhFfr0 6qKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=os+OhHKUZubWC6gnApdUQmcYYvGirSAwoIGybUTo0s8=; b=TSgBsFqPxVX1Vgxdg+osmNwnOK/+ZTccRQMXOcuREJNBE3qxYtHX9XGeURw5h1MrCs 8IVUklwa2k+rQ2/E8pg8zwQqZ5UM4ZTmUYA4fTnTtWn/l4RUNVTLILb9bi57jlm9dwbt dlpFndnbSdjEzjK00QptkC7kRtK/zR8jhzH15ZxG38duvzdVJbzEW0o820kKVejlMmmz +vdLxCJplOYF/AFtyj56m30B2jn0rOEqSSv90hws3ZpJPXeNJ2JoGC8NjlmASgyNE4wm r7i7YZnyLDxaX4oRfrn2Q5awX9UlZcEYWiUhiFDZlv6vr4SiQ1mTKGj82R8DvMGWAPB0 PtYg==
X-Gm-Message-State: APt69E0DFdOcNU58b9KzHHtPSVA04dmOAN/S2GEu0hFH9y75qrKk/rj0 o/Bx+Rsxtcw114B7MdC5YlfX2iock+Z3tRIzY54=
X-Google-Smtp-Source: ADUXVKLOJnowwuOeIPjHM2fPzlJkCQ7LrVt4PN8cnLiAmh4mYNeQbUrAs9i8otzfbrZgjgHgitUu6qvEvArOvPtOcSc=
X-Received: by 2002:a17:902:3041:: with SMTP id u59-v6mr22722936plb.208.1530462462001; Sun, 01 Jul 2018 09:27:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Sun, 1 Jul 2018 09:27:41 -0700 (PDT)
In-Reply-To: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <CANatvzwoHL1_MtkHM53+PKhR8Rs52Y2y=mVt+f5kFwpDGTNn2Q@mail.gmail.com> <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Mon, 02 Jul 2018 01:27:41 +0900
Message-ID: <CANatvzy5JvUOqkhdFzutskWC9fpKxdByHXjaW5AhCo78BX69GA@mail.gmail.com>
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)
To: "Lubashev, Igor" <ilubashe@akamai.com>, Praveen Balasubramanian <pravb@microsoft.com>
Cc: "huitema@huitema.net" <huitema@huitema.net>, "quic@ietf.org" <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/sY6beradzYuUgiv2snQCHRJui0s>
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: Sun, 01 Jul 2018 16:27:44 -0000

2018-06-30 12:43 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com>:
> It would make sense to define PING to require an ACK as soon as possible.
> The need for an immediate ACK is not just in tail loss probes. It is also
> PMTU probes. Come to think of this, PATH_CHALLENGE should require an
> expedited ACK as well.

That approach would work well.

In my view, there are two ways; i) define a frame that requests
immediate ACK, and bundle that frame with other frames if immediate
ACK is required, ii) define which frames trigger immediate ACK. I
think either of the two are workable.

Re Praveen's comment, my understanding is that there are cases that a
sender wants to trigger immediate ACK even if gap is not observed on
the receiver side. In case of TLP, such behavior is desirable because
it gives the peers to recover earlier from the loss of a previous
packet that contained an ACK.

>
> - Igor
>
>
> -----Original Message-----
> From: Kazuho Oku [kazuhooku@gmail.com]
> Received: Friday, 29 Jun 2018, 11:14PM
> To: Christian Huitema [huitema@huitema.net]
> CC: IETF QUIC WG [quic@ietf.org]
> Subject: Speeding up tail loss detection (Re: Congestion control algorithm
> questions)
>
> I know that the recovery draft defines TLP, but it does not provide a
> way for a sender to request client to send an ACK immediately. I think
> that there should be a way to request that, because it would help the
> sender detect the loss at the earliest moment.
>
> One way is to specify a TLP frame, which is identical to a PING frame
> with only one difference: it suggests the peer to send ACK
> immediately. A sender sending a TLP will include the frame in the
> packet to evoke the peer to send ACK without waiting for the delay.
>
> Searching the mailing list archive told me that Christian raised the
> issue about a year ago (in the mail cited below), but it seems to me
> that the issue has not been resolved yet.
>
> 2017-08-25 14:52 GMT+09:00 Christian Huitema <huitema@huitema.net>:
>
>> 3) Can the senders do something to speed up retransmission?
>> In the absence of continuous traffic flow, the previous decision tree
>> degenerates to timer based retransmission. To speed things up,
>> implementations can generate extra traffic. For example, if no
>> acknowledgement is received after a short timer, they can send a
>> gratuitous packet that may trigger a further acknowledgement. That's the
>> essence of the "tail loss probe" algorithm of TCP, but things are really
>> simpler with monotonously increasing packet sequence numbers. There are
>> various plausible ways to send a gratuitous packet -- a Ping, a Max Data
>> Update, or repeating the oldest packet will all work.
>>
>> Of course, implementations should avoid sending too many gratuitous
>> packets, because it can cause congestion. The typical implementation
>> will wait one min-RTT before sending the first tail loss probe, then
>> just wait for the regular timer based retransmission. But we may start
>> being creative. For example, if packets are waiting and the
>> implementation is sending a naked ACK for whatever reason, it does not
>> cost much to add a Ping to that.
>>
>> This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it is
>> very easy to implement.
>>
>> --
>> Christian Huitema
>>
>>
>
>
>
> --
> Kazuho Oku
>



-- 
Kazuho Oku