Speeding up tail loss detection (Re: Congestion control algorithm questions)
Kazuho Oku <kazuhooku@gmail.com> Sat, 30 June 2018 03:14 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 86370130E7F for <quic@ietfa.amsl.com>; Fri, 29 Jun 2018 20:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 vRxDMUOq6cya for <quic@ietfa.amsl.com>; Fri, 29 Jun 2018 20:14:02 -0700 (PDT)
Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (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 A0308127332 for <quic@ietf.org>; Fri, 29 Jun 2018 20:14:02 -0700 (PDT)
Received: by mail-pl0-x22c.google.com with SMTP id s24-v6so5314127plq.6 for <quic@ietf.org>; Fri, 29 Jun 2018 20:14:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=nwfQyyHTAtuT0Sre10q5YBgzJJ+78M98HG+7vHwFIEc=; b=FpH5OpkvRulgFCtOY35Hrev789K3Z19KXafOSmxinVnF057gf2H5lHMsT1Yymru2RG 0nQDQ1k1dhpmtJcARa3jQBwvmuYCJK5a4sXjR0vqrpme1JsmRSdUBIT5kMPKkcOAesZI ZrbQkLXU2ByCa66FYX//ILs3BuEzgkv5Tag6hVMS94lYNeQTKj3oVMRIZwZeQAhgaons gLtKBRPEX3XhMHmrNfKZ0NBKOlA5dDKIdv+xQEg+P6H4DqmdCJMHp1VnjgCkxB2Wo4l+ NFGw6K0h3lXZWjxlV580PmVaWaPH700BA6fQoVaajaiNXPWf1LbwOrjak24jquFQYyX7 sY1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=nwfQyyHTAtuT0Sre10q5YBgzJJ+78M98HG+7vHwFIEc=; b=tsqAlZYQUtcKRYc0Fn9Z2dS5aFl1T4nViwNYDxd2X1cfNmR6X12N05VBGj/c/DQ5J5 9VHdRMdJrnsqBhLupA70o9UmQYIpn4bmh0WMRDI0/THvBjC/UgjnW2YAp28wYcZgvJbK XjgAq8VUeqh5ZiMJExDW7fCZgOb0lZ3IAGe1kqxvj8hR3JkCdwAexG3ozctIyjJLrFPS qrgaIFX5c9qgbvy5EcJvagmdHjxhqu0zutfPx7LedybYEnSpD8Xi/IW9tRLqh5hDlKkH RKSuq4TW9Ah65cVGwLX4SA2I3J55p7uzs1n+y2s/DlUuq05k3DRMBUuRWrrpl0sE9OfS ua3g==
X-Gm-Message-State: APt69E3abylVydPtG0UkC7UPDI5jBlMC/Pe0x3zk4+IZAgREXQ9BrwVD G47KiW8zEexELOBa+Yjvr9N6XxklD7r32dHnVhA=
X-Google-Smtp-Source: AAOMgpdjZvw9FbwUZYsOtzgD+hwG/pdmaUtngfQ8Z601Ue9pHV1MZ4m9yZEheyiI6z2x3Ww8t+zox0Cwecsv/THrHtM=
X-Received: by 2002:a17:902:1e6:: with SMTP id b93-v6mr4935003plb.149.1530328442067; Fri, 29 Jun 2018 20:14:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Fri, 29 Jun 2018 20:14:01 -0700 (PDT)
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Sat, 30 Jun 2018 12:14:01 +0900
Message-ID: <CANatvzwoHL1_MtkHM53+PKhR8Rs52Y2y=mVt+f5kFwpDGTNn2Q@mail.gmail.com>
Subject: Speeding up tail loss detection (Re: Congestion control algorithm questions)
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_BaQ3QuBznTDwNGkUEhI7rCo-zI>
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: Sat, 30 Jun 2018 03:14:05 -0000
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
- Re: Speeding up tail loss detection (Re: Congesti… Ian Swett
- Re: Speeding up tail loss detection (Re: Congesti… Ian Swett
- Re: Speeding up tail loss detection (Re: Congesti… Yoshifumi Nishida
- RE: Speeding up tail loss detection (Re: Congesti… Praveen Balasubramanian
- RE: Speeding up tail loss detection (Re: Congesti… Lubashev, Igor
- Speeding up tail loss detection (Re: Congestion c… Kazuho Oku
- Re: Speeding up tail loss detection (Re: Congesti… Christian Huitema
- Re: Speeding up tail loss detection (Re: Congesti… Christian Huitema
- RE: Speeding up tail loss detection (Re: Congesti… Mikkel Fahnøe Jørgensen
- RE: Speeding up tail loss detection (Re: Congesti… Praveen Balasubramanian
- Re: Speeding up tail loss detection (Re: Congesti… Kazuho Oku
- RE: Speeding up tail loss detection (Re: Congesti… Praveen Balasubramanian
- Re: Speeding up tail loss detection (Re: Congesti… Yoshifumi Nishida