Re: [quicwg/base-drafts] PTO MUST send new data or retransmit data if possible (#3057)

ianswett <> Tue, 24 September 2019 02:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82ECE1200D8 for <>; Mon, 23 Sep 2019 19:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.898
X-Spam-Status: No, score=-7.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_32=0.001, 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 vomjWYZeBC_S for <>; Mon, 23 Sep 2019 19:14:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BBA3120086 for <>; Mon, 23 Sep 2019 19:14:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9D9889600B0 for <>; Mon, 23 Sep 2019 19:14:36 -0700 (PDT)
Date: Mon, 23 Sep 2019 19:14:36 -0700
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3057/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] PTO MUST send new data or retransmit data if possible (#3057)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d897c0c8cb9f_79233fe3b9ecd95c11527"; 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
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:14:40 -0000

ianswett commented on this pull request.

> @@ -526,15 +524,16 @@ as a probe, unless there is no data available to send.  An endpoint MAY send up
 to two full-sized datagrams containing ack-eliciting packets, to avoid an
 expensive consecutive PTO expiration due to a single lost datagram.
-It is possible that the sender has no new or previously-sent data to send.  As
-an example, consider the following sequence of events: new application data is
-sent in a STREAM frame, deemed lost, then retransmitted in a new packet, and
-then the original transmission is acknowledged.  In the absence of any new
-application data, a PTO timer expiration now would find the sender with no new
-or previously-sent data to send.
+When the PTO timer expires, and there is new or previously sent data, it MUST

I changed it to previously sent unacknowledged data, because that is the intent, though it's also a bit verbose.

Data is used fairly widely to mean ack-eliciting frames in this document.  I'm not sure if that is something we should codify in the definitions section?

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