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

Benjamin Saunders <> Mon, 23 September 2019 23:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E20F9120090 for <>; Mon, 23 Sep 2019 16:34:22 -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 ezcP17PF1Y5I for <>; Mon, 23 Sep 2019 16:34:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78A60120045 for <>; Mon, 23 Sep 2019 16:34:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AE8EB8C06B6 for <>; Mon, 23 Sep 2019 16:34:20 -0700 (PDT)
Date: Mon, 23 Sep 2019 16:34:20 -0700
From: Benjamin Saunders <>
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_5d89567c9fb72_7fe93ff0792cd964283d3"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: Ralith
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: Mon, 23 Sep 2019 23:34:23 -0000

Ralith commented on this pull request.

-When there is no data to send, the sender SHOULD send a PING or other
-ack-eliciting frame in a single packet, re-arming the PTO timer.
+It is possible 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.  When there is no data to
+send, the sender SHOULD send a PING or other ack-eliciting frame in a single
+packet, re-arming the PTO timer.

In this case, the second packet is ack-eliciting and has not been acknowledged, eventually leading to a probe timeout. However, there is no unsent or sent-but-unacknowledged ack-eliciting data available to send, so a `PING` is fabricated instead.

Perhaps "there is new or previously sent data" should be more specific?

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