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

ianswett <> Tue, 24 September 2019 01:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D279812009C for <>; Mon, 23 Sep 2019 18:18:03 -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 Iq6g5LuwRHJy for <>; Mon, 23 Sep 2019 18:18:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D414F120045 for <>; Mon, 23 Sep 2019 18:18:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F95C8C04D8 for <>; Mon, 23 Sep 2019 18:18:01 -0700 (PDT)
Date: Mon, 23 Sep 2019 18:18:00 -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_5d896ec8f393e_61a03fd9caecd96499010"; 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 01:18:04 -0000

ianswett 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 example, the point is that in order to remove the retransmission from byte in flight, you SHOULD send a PING and when it's acknowledged, you'll know whether the retransmission was lost or not.  Ideally it'll be ACKed on its own before the PTO fires.

The above text is about the server's amplification factor and not arming the alarm when "If no data can be sent"

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