IETF Logo Mail Archive

Re: [quicwg/base-drafts] loss recovery of crypto packets is less aggressive, not more aggressive (#2435)

Marten Seemann <notifications@github.com> Tue, 12 February 2019 02:04 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 4BE3E1277D2 for <quic-issues@ietfa.amsl.com>; Mon, 11 Feb 2019 18:04:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_IMAGE_ONLY_32=0.001, 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 5EVUnNLpmLsE for <quic-issues@ietfa.amsl.com>; Mon, 11 Feb 2019 18:04:09 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732DA1276D0 for <quic-issues@ietf.org>; Mon, 11 Feb 2019 18:04:09 -0800 (PST)
Date: Mon, 11 Feb 2019 18:04:08 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549937048; bh=Zy1cSibK6nbGxVkCmmEfn5UJrkluMcKEmFigPdPWVvA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XHRZYrLcT0U0fVRUO9tuG0pFx6u70nseScPZIya69rRfLMMX+2camd0hL2BSHvOir eQYoxMc/qyUWxQswHkcyT4ZBGkuKfP5+ZS+GeyWQ5h4pQmccrs63yA9xHMPyXXLWT6 yfn/Zw5olPCjL9Q5Bz76GJX/XKB8oOCy/Mh6glo4=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abe16a1bca6ceb09157a2c9d6ecea953c2d695a0e692cf000000011879eb9892a169ce184a02c3@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/462582507@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_5c62299885d95_4a5a3fde824d45b812934b"; 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/ev1ClOxoFyEFdlRuzDcNtah3fm0>
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: Tue, 12 Feb 2019 02:04:11 -0000

> If we wanted to favor aggressiveness during the handshake, we could arm the crypto timer based on the left edge(earliest unacked ack-eliciting packet) rather than the right(latest unacked). That's a larger change than I'd like to make in this CL/issue, though.

I'm not sure if it would work. The main reason is the 3x amplification limit, which can delay the sending of crypto packets on the server side. You could then run into the situation where the timer based on the oldest packet already expires, just after sending another crypto packet. It wouldn't make a lot of sense to immediately retransmit that packet.

-- 
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-462582507

v2.23.0 | Report a Bug | By Email