IETF Logo Mail Archive

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

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Sun, 01 July 2018 17:20 UTC

Return-Path: <mikkelfj@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 7E48112F1A2 for <quic@ietfa.amsl.com>; Sun, 1 Jul 2018 10:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wPqAkz-pOEm2 for <quic@ietfa.amsl.com>; Sun, 1 Jul 2018 10:20:44 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 0BD09126CC7 for <quic@ietf.org>; Sun, 1 Jul 2018 10:20:43 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id p7-v6so371816ioh.13 for <quic@ietf.org>; Sun, 01 Jul 2018 10:20:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Lh8JCuIUO4yR6PInwpCb3wwOKSaRKQscqLRoYN2AlRU=; b=G9sq1fppx5GmZvZEo1pzRQWOvwUJycVD6tUtQDcTtz+1Pz07NoBnscbEovlgI1EPq5 09Ac4M1nqaVb2ZTHZrCr1x2WWsdOqcOyFUpaqOsmBmcUO/EP+HNXSmeotaVVHj3qD1gb gCmHFqAveCHau2LTi6iqaHbOwwG5c5dHpTSvLAf8tgxbHRYvXuuzpzFqnpbD866UW39l cH+VjNX3cbM9BfRP3CXus4u+0Ne5+eEHzE+i1Ag17zITEoSX86GzJybb9HCmQgs5n6P8 l94gTUsiKUEu1PYADu8rYQz2awnkfLEK8mYbbox9QBSgLYnUz+ne2DP71TkyPhgclf29 8M+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Lh8JCuIUO4yR6PInwpCb3wwOKSaRKQscqLRoYN2AlRU=; b=HnWo4j7fnkAR3RiKQNQ50va64R5ogtdf3DkryJ+S9V2NrpUR7AsGQE5cKZjebH1LwY +fTevcU6E58buwfJjf/vTonNWiUd4lzBxlj/uOjE3p0ZIjeols8RqOid4xu154qm2WPi TN4g8VKeeFqIhzUA7gb+wFEXPZ+QdeZYwrYStxDaeKwLP0aeG0HNDhF4n9qLDqGObpDB X8QNUjdPSJk/R83E2ObzNh+uo7Nze4B/r402oowYaOUPDUNdgAtVwsAGZyNt4ssBMu/6 KGf7yk56/JkamUOMdde5HLvgT2K00g5ByJQQfynno3xyf9ZTDIIVCFcG/pFYCpIQxaFM kH3Q==
X-Gm-Message-State: APt69E0IkZ47AnV8LmIx6DUrv4WrF3nYE8cIpDUieXW9vSvijK5QqFl3 V2IcN4Oxd92ZQ1ZFwoxHnS0Zt2hNJI0gbTPHUf0=
X-Google-Smtp-Source: AAOMgpdXzJoghSdBbnU7FaMkuYoPPql1yKydQhRD1LdxmdP3rEFUjBE1I0SPeyQRe3ZvYtiD/Wg4bO74X9/riebPJus=
X-Received: by 2002:a6b:b685:: with SMTP id g127-v6mr18193091iof.209.1530465643336; Sun, 01 Jul 2018 10:20:43 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 1 Jul 2018 10:20:42 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <MW2PR2101MB1098869CB84F0FD75A52E961B64C0@MW2PR2101MB1098.namprd21.prod.outlook.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>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sun, 01 Jul 2018 10:20:42 -0700
Message-ID: <CAN1APdeb49OyOYSfviOqTuEow53aEGT7czt9jY4Cn0chaBKJyQ@mail.gmail.com>
Subject: RE: Speeding up tail loss detection (Re: Congestion control algorithm questions)
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>, "Lubashev, Igor" <ilubashe@akamai.com>, Kazuho Oku <kazuhooku@gmail.com>
Cc: huitema <huitema@huitema.net>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000031d2e056ff34d85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/lHHwTS817bkIAMMYZ9BA8zulXoo>
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 17:20:46 -0000

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.

v2.23.0 | Report a Bug | By Email