Re: [quicwg/base-drafts] loss recovery of crypto packets is less aggressive, not more aggressive (#2435)
Marten Seemann <notifications@github.com> Mon, 11 February 2019 15:33 UTC
Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28405130EDE for <quic-issues@ietfa.amsl.com>; Mon, 11 Feb 2019 07:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 idY2lL0S2cZK for <quic-issues@ietfa.amsl.com>; Mon, 11 Feb 2019 07:33:44 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0A71271FF for <quic-issues@ietf.org>; Mon, 11 Feb 2019 07:33:44 -0800 (PST)
Date: Mon, 11 Feb 2019 07:33:43 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549899223; bh=psR7LOBJGBSE/Z8sSWIKuGT7DETq6nQHMOnCvx6C97w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LDE2DRRtV2c+Ju+V5ns315YXmr9MF1d8m0yVyCzVCEwxqk7Ky99CZWKfOn8O0chB9 b0syLdQnf69joV1zdCFiNPByFQkOFDRzgokNmPxAWutkdVG387/VkBhnIPuUpp/HEm k5tbZUojKKCaeKZmiwljaTTKhM5KxM0A9x8VwDOU=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab2c2ec019c493ac1c64a4fff277ce2f22e6c9e3b892cf00000001187957d792a169ce184a02c3@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2435/462371300@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2435@github.com>
References: <quicwg/base-drafts/issues/2435@github.com>
Subject: Re: [quicwg/base-drafts] loss recovery of crypto packets is less aggressive, not more aggressive (#2435)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c6195d72697c_ede3febf3ad45c03232a9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/NsMOU5yIFlUDZrkc14zx0A8beY8>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 15:33:46 -0000
I just tried to sketch the algorithm using a packet-number-space dependent `loss_time`, i.e. `loss_time[kPacketNumberSpace]`. In `SetLossDetectionTimer()`, you'd then use the smallest (non-zero) `loss_time` for your timer, and only arm the crypto retransmission timeout if all 3 `loss_time`s are 0. This seems to work fine, and is generally (a lot) more aggressive than what we currently have, however, there's one corner case where it's less aggressive. Consider the following sequence of packets being sent: ``` t=1: Initial 1 t=2: Initial 2 t=3: Handshake 1 ``` Now we receive an ACK for Initial 2, and arm the early retransmit timer at `t=1+1.125x`, where `x` is the RTT. When this timer fires, we retransmit Initial 1 as Initial 3. The crypto retransmission timeout will now be set this time plus 2 RTT, i.e. `t=1+3.125x`. This is then the first time we retransmit Handshake 1. Without the early retransmit timer, we would have retransmitted Handshake 1 2 RTTs after sending it, i.e. at `t=3+2x`, which for all realistic RTTs would be earlier. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/quicwg/base-drafts/issues/2435#issuecomment-462371300
- [quicwg/base-drafts] loss recovery of crypto pack… Marten Seemann
- Re: [quicwg/base-drafts] loss recovery of crypto … ianswett
- Re: [quicwg/base-drafts] loss recovery of crypto … Marten Seemann
- Re: [quicwg/base-drafts] loss recovery of crypto … ianswett
- Re: [quicwg/base-drafts] loss recovery of crypto … Marten Seemann
- Re: [quicwg/base-drafts] loss recovery of crypto … ianswett
- Re: [quicwg/base-drafts] loss recovery of crypto … Marten Seemann
- Re: [quicwg/base-drafts] loss recovery of crypto … Jana Iyengar
- Re: [quicwg/base-drafts] loss recovery of crypto … Marten Seemann
- Re: [quicwg/base-drafts] loss recovery of crypto … ianswett
- Re: [quicwg/base-drafts] loss recovery of crypto … ianswett
- Re: [quicwg/base-drafts] loss recovery of crypto … ianswett
- Re: [quicwg/base-drafts] loss recovery of crypto … ianswett