Date: Thu, 18 Apr 2019 14:37:44 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJK7TMIQ7KKTFB5JRSBV2YYQKREVBNHHBTVVJOU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2624/review/228518207@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2624@github.com>
References: <quicwg/base-drafts/pull/2624@github.com>
Subject: Re: [quicwg/base-drafts] Add details of marking packets lost on PTO
 (#2624)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5cb8ee2858a3_47543fae822cd95c2614e4";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/OWOwmICYx_hZ7V4_tjQaI0SvCq0>


----==_mimepart_5cb8ee2858a3_47543fae822cd95c2614e4
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

ianswett commented on this pull request.



> +When a PTO timer expires, a sender MUST send at least one ack-eliciting packet
+as a probe, unless there is no data available to send.  An endpoint MAY send up
+to two ack-eliciting packets, to avoid an expensive consecutive PTO expiration
+due to a single packet loss.
+
+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 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.
+
+Alternatively, instead of sending the ack-eliciting packet, the sender MAY mark

```suggestion
Alternatively, instead of sending an ack-eliciting packet, the sender MAY mark
```

-- 
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/2624#pullrequestreview-228518207
----==_mimepart_5cb8ee2858a3_47543fae822cd95c2614e4
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p><b>@ianswett</b> commented on this pull request.</p>=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2624#discussi=
on_r276843302">draft-ietf-quic-recovery.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; +When a PTO timer expires, a sender MUST s=
end at least one ack-eliciting packet=0D
+as a probe, unless there is no data available to send.  An endpoint MAY =
send up=0D
+to two ack-eliciting packets, to avoid an expensive consecutive PTO expi=
ration=0D
+due to a single packet loss.=0D
+=0D
+It is possible that the sender has no new or previously-sent data to sen=
d.  As=0D
+an example, consider the following sequence of events: new application d=
ata is=0D
+sent in a STREAM frame, deemed lost, then retransmitted in a new packet,=
 and=0D
+then the original transmission is acknowledged.  In the absence of any n=
ew=0D
+application data, a PTO timer expiration now would find the sender with =
no new=0D
+or previously-sent data to send.=0D
+=0D
+When there is no data to send, the sender SHOULD send a PING or other=0D=

+ack-eliciting frame in a single packet, re-arming the PTO timer.=0D
+=0D
+Alternatively, instead of sending the ack-eliciting packet, the sender M=
AY mark=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-Alternatively, instead of sending the ack-eli=
citing packet, the sender MAY mark=0D
+Alternatively, instead of sending an ack-eliciting packet, the sender MA=
Y mark=0D
</pre>=0D
=0D
=0D
<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/pull/2624#pullrequestreview-228518207">view it on GitHub</=
a>, or <a href=3D"https://github.com/notifications/unsubscribe-auth/AFTOJ=
K35OUM6BN5SVYVS4D3PRDS2RANCNFSM4HGD4GCA">mute the thread</a>.<img src=3D"=
https://github.com/notifications/beacon/AFTOJK5AMO4GTUZIOLSIRX3PRDS2RANCN=
FSM4HGD4GCA.gif" height=3D"1" width=3D"1" alt=3D"" /></p>=0D
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name"=
:"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"=
quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"http=
s://github.githubassets.com/images/email/message_cards/header.png","avata=
r_image_url":"https://github.githubassets.com/images/email/message_cards/=
avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/q=
uicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@=
ianswett commented on #2624"}],"action":{"name":"View Pull Request","url"=
:"https://github.com/quicwg/base-drafts/pull/2624#pullrequestreview-22851=
8207"}}}</script>=0D
<script type=3D"application/ld+json">[=0D
{=0D
"@context": "http://schema.org",=0D
"@type": "EmailMessage",=0D
"potentialAction": {=0D
"@type": "ViewAction",=0D
"target": "https://github.com/quicwg/base-drafts/pull/2624#pullrequestrev=
iew-228518207",=0D
"url": "https://github.com/quicwg/base-drafts/pull/2624#pullrequestreview=
-228518207",=0D
"name": "View Pull Request"=0D
},=0D
"description": "View this Pull Request on GitHub",=0D
"publisher": {=0D
"@type": "Organization",=0D
"name": "GitHub",=0D
"url": "https://github.com"=0D
}=0D
}=0D
]</script>=

----==_mimepart_5cb8ee2858a3_47543fae822cd95c2614e4--