IETF Logo Mail Archive

Re: [quicwg/base-drafts] Review conditions for PTO arming around end of handshake (#3613)

martinduke <notifications@github.com> Thu, 30 April 2020 01: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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39B23A0CB9 for <quic-issues@ietfa.amsl.com>; Wed, 29 Apr 2020 18:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Level:
X-Spam-Status: No, score=-1.482 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, 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 64dirVBeRjAZ for <quic-issues@ietfa.amsl.com>; Wed, 29 Apr 2020 18:51:42 -0700 (PDT)
Received: from out-16.smtp.github.com (out-16.smtp.github.com [192.30.254.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E8D3A0CB4 for <quic-issues@ietf.org>; Wed, 29 Apr 2020 18:51:42 -0700 (PDT)
Received: from github-lowworker-56fcc46.va3-iad.github.net (github-lowworker-56fcc46.va3-iad.github.net [10.48.102.32]) by smtp.github.com (Postfix) with ESMTP id 9A0881212F5 for <quic-issues@ietf.org>; Wed, 29 Apr 2020 18:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1588211501; bh=2WjcPdCPeiX3doamhi0BRitH+0n2MfJKen/hD1cKlt4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dg/a2feEYLhBOyLzZWRA1I5X9hfMp2Nl0CQKMp1MhC2xQYIs2puNnTNHpY7SYCgYE TYOKfco//kH55B7pSY85vKg82HLcQ395Z6tk864AKk7eHbQadZ4/1arJFW8EslIGXT 1Sq1zInZNOwaAg+eeeMg/A/fLBhU8f8LqHCpqsT0=
Date: Wed, 29 Apr 2020 18:51:41 -0700
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7DCIWDQN5D2UZYKC54WYIC3EVBNHHCIVAFGY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3613/621564549@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3613@github.com>
References: <quicwg/base-drafts/issues/3613@github.com>
Subject: Re: [quicwg/base-drafts] Review conditions for PTO arming around end of handshake (#3613)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eaa2f2d74637_8d03f9c346cd9681034f6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/YeAw-lAWe4Fef5vD7EuHLw6eUAo>
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: Thu, 30 Apr 2020 01:51:44 -0000

There's some architectural inconsistency around the treatment of 1RTT PTOs at the end of the handshake.

On the one hand, we are not supposed to set the PTO timer for 1RTT before the handshake is **complete**. This is to prevent us from retransmitting stuff the peer may not be able to process.

On the other hand, we are supposed to arm the PTO timer when the handshake is **confirmed**. This is the point where we're guaranteed that the peer has receive keys.

So there is a weird gap between handshake complete and handshake confirmed where new 1RTT packets will arm the PTO, but outstanding 0RTT or 1RTT packets from before handshake complete will not have an active PTO timer.

This isn't the end of the world -- the connection will recover -- but it doesn't make any sense, and could result in either excessive PTO delays, or 1RTT probes that the peer can't decode.

-- 
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/3613#issuecomment-621564549

v2.23.0 | Report a Bug | By Email