IETF Logo Mail Archive

Re: [quicwg/base-drafts] Change PTO to be per packet number space (#3066)

Marten Seemann <notifications@github.com> Sun, 03 November 2019 06:07 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 4B4E41200BA for <quic-issues@ietfa.amsl.com>; Sat, 2 Nov 2019 23:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 StQKjppc9H3Y for <quic-issues@ietfa.amsl.com>; Sat, 2 Nov 2019 23:07:28 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9350612006D for <quic-issues@ietf.org>; Sat, 2 Nov 2019 23:07:28 -0700 (PDT)
Received: from github-lowworker-d31a065.va3-iad.github.net (github-lowworker-d31a065.va3-iad.github.net [10.48.17.70]) by smtp.github.com (Postfix) with ESMTP id D41D3C60647 for <quic-issues@ietf.org>; Sat, 2 Nov 2019 23:07:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572761247; bh=Hf6d7ANd34e9+NXHm9pTqNabZo3IBvwDbPnNPHW3sJ4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dqEL+0EbqvLXFDYuW7UvJY/34Sc7C5iVZIy6AxnYjS3bjZiCCwVCpanX3msY1LL1T 9cH16qrTCdLL/i0GwPX0LHY4IJOcnGFc3ydCPh2sYtJRwT8FK1RU492sRjIG+p85zp dKzwe+OTq4TL1rVcCAi1TiJMO0qgiLWko3jH6bDM=
Date: Sat, 02 Nov 2019 23:07:27 -0700
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5SL4N357AVODAUXH53ZOQR7EVBNHHB3LP3EA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3066/c549108352@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3066@github.com>
References: <quicwg/base-drafts/pull/3066@github.com>
Subject: Re: [quicwg/base-drafts] Change PTO to be per packet number space (#3066)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dbe6e9fc4615_277f3f970c0cd9641201347"; 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/ZqE_nU9DNju0NlMhaMoKDJvSLOU>
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: Sun, 03 Nov 2019 06:07:30 -0000

What is the motivation behind not sending a PTO for the application data packet number space until the handshake is completed? If I had to guess, we're trying to not put too much load onto the network (and thereby increase the chance that PTO packets containing Initial / Handshake data make it through) until we know that we're done with the handshake.
However, this only works for the server side. The client completes the handshake after sending its cert and the CFIN, but it doesn't know if those packets were actually received.

Maybe the signal we're actually looking for here is handshake confirmed, and not handshake completed?

-- 
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/pull/3066#issuecomment-549108352

v2.23.0 | Report a Bug | By Email