Re: [quicwg/base-drafts] Allow PING in Initial/Handshake? (#3034)

Kazuho Oku <> Tue, 24 September 2019 02:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03AC2120086 for <>; Mon, 23 Sep 2019 19:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.495
X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ac5jzsk0qzN1 for <>; Mon, 23 Sep 2019 19:35:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EE291200E9 for <>; Mon, 23 Sep 2019 19:35:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D6683520167 for <>; Mon, 23 Sep 2019 19:35:23 -0700 (PDT)
Date: Mon, 23 Sep 2019 19:35:23 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3034/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Allow PING in Initial/Handshake? (#3034)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d8980ebc06d6_69c03ff7354cd968117969"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2019 02:35:26 -0000

While I am fine with allowing PING frames in Initial and Handshake, I wonder what the benefit is.

IIUC, the reason of sending PINGs in case of PTO is to determine if a previously sent ack-eliciting packet has reached the peer. That is determined by the peer sending an ACK.

However, in case of Initial and Handshake packets, the only case when PTO fires and you do not have any data to send is when the endpoints are ready to switch to the next epoch. To rephrase, I think there might be a high chance of the endpoint not receiving an ACK due to the peer dropping the Initial keys (or the Handshake keys).

Considering that, I am not sure if it is a good advice to suggest endpoints send PINGs on PTO. Rather, I think it might be worthwhile to suggest that when discarding a packet number space, unconfirmed loss does not affect the CWND.

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