[quicwg/base-drafts] QUIC timers would be simpler if the Handshake timer was unified with the PTO timer (#2650)

ianswett <notifications@github.com> Wed, 24 April 2019 13:51 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 23B161201A8 for <quic-issues@ietfa.amsl.com>; Wed, 24 Apr 2019 06:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tUIFhYbC4CqB for <quic-issues@ietfa.amsl.com>; Wed, 24 Apr 2019 06:51:42 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4125F120364 for <quic-issues@ietf.org>; Wed, 24 Apr 2019 06:51:42 -0700 (PDT)
Date: Wed, 24 Apr 2019 06:51:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1556113901; bh=s89Y7nwlO8k7YdQcOpVnYOllidaPX/go6dO3/k89gco=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Ep8JhK07YWHkymYOlpYiEIKg0VD9UlJLlGWoKPg9W6XgZg0V8GeNKN4mCEFRs/VzV 2CAZD49RZlEXPf55mGaYSymnXyq+ibqksygezR9J71vvDGVg3k8rd3h06Z3w3iBM4u 6NCkyEUyIuAJG8EAwc7riXAQVtoq8eMDlZy4AKGo=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2OOEJWQNBA4CHSBHV2ZWOG3EVBNHHBUB5KUE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2650@github.com>
Subject: [quicwg/base-drafts] QUIC timers would be simpler if the Handshake timer was unified with the PTO timer (#2650)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cc069ed28cac_368f3fa4a72cd9641649e1"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/SiIW4R2ifbBWitOZyMzzhcUyJsk>
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: Wed, 24 Apr 2019 13:51:50 -0000

The main optimization the handshake timer makes is the assumption that max_ack_delay does not need to be waited for before firing.  However, it also uses a completely different equation for a timeout (2 * SRTT vs SRTT + 4*RTTVar).  We could fix the max_ack_delay difference by defaulting max_ack_delay to 0(#2646), like almost all other transport parameters.

If there are no RTT measurements or estimates, we could use 1 second.  If there are no RTT measurements, but there is an estimate, we could either use the PTO formula and assume RTTVar is 1/2 RTT(=> 3*RTT), or we could recommend estimating RTTVar as well as RTT.  The first approach seems more practical.

Another notable difference is the advice to retransmit all the handshake packets instead of 1 or 2, but given the current 3x amplification limit, if a server sends 2 packets in response to a ClientHello, they can't even retransmit both packets, so advising that they retransmit all handshake packets is not indicative of real-world behavior.  If the server only has 1 handshake packet, then there's no change.  The client should always be able to fit its CRYPTO data into a single packet, unless there are large client certs.  If there are large client certs, one would expect time or packet threshold loss recovery to be faster and more effective than timer based retransmissions.  And at that point, the client should have at least one RTT sample.

The goal of this issue is to make the recovery mechanisms simpler, as well as including RTTVar in the handshake timer, as #2648 suggests.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: