Date: Wed, 10 Apr 2019 12:23:08 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abd8e69d7df659c4ee0a367d746b308a2acc17d8f092cebabb751c92a169ce19a97bc9@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2593/481827995@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2593@github.com>
References: <quicwg/base-drafts/issues/2593@github.com>
Subject: Re: [quicwg/base-drafts] Persistent congestion interaction with app
 limited state (#2593)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5cae429c555fc_76083f91d06d45c41478fc";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/OgUWlU3EXDr1uE5p04EqXTcLTBc>


----==_mimepart_5cae429c555fc_76083f91d06d45c41478fc
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

There's text on this edge case, but not the interaction with persistent congestion.
https://tools.ietf.org/html/draft-ietf-quic-recovery-19#section-6.3.2
"When a PTO timer expires, new or previously-sent data may not be
   available to send and packets may still be in flight.  A sender can
   be blocked from sending new data in the future if packets are left in
   flight.  Under these conditions, a sender SHOULD mark any packets
   still in flight as lost.  If a sender wishes to establish delivery of
   packets still in flight, it MAY send an ack-eliciting packet and re-
   arm the PTO timer instead."

I think if you follow either suggestion listed, you shouldn't inadvertently declare persistent congestion from being idle, since in one case you immediately declare packets lost and in the other, you'd only declare persistent congestion if the subsequent PTOs established it?

-- 
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/issues/2593#issuecomment-481827995
----==_mimepart_5cae429c555fc_76083f91d06d45c41478fc
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>There's text on this edge case, but not the interaction with persisten=
t congestion.<br>
<a href=3D"https://tools.ietf.org/html/draft-ietf-quic-recovery-19#sectio=
n-6.3.2" rel=3D"nofollow">https://tools.ietf.org/html/draft-ietf-quic-rec=
overy-19#section-6.3.2</a><br>
"When a PTO timer expires, new or previously-sent data may not be<br>
available to send and packets may still be in flight.  A sender can<br>
be blocked from sending new data in the future if packets are left in<br>=

flight.  Under these conditions, a sender SHOULD mark any packets<br>
still in flight as lost.  If a sender wishes to establish delivery of<br>=

packets still in flight, it MAY send an ack-eliciting packet and re-<br>
arm the PTO timer instead."</p>
<p>I think if you follow either suggestion listed, you shouldn't inadvert=
ently declare persistent congestion from being idle, since in one case yo=
u immediately declare packets lost and in the other, you'd only declare p=
ersistent congestion if the subsequent PTOs established it?</p>

<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/issues/2593#issuecomment-481827995">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkqxdn=
1gX5-GL6qOcr4HH8oJ0d_RQaks5vfjocgaJpZM4cikee">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkq-R4R2GnLwqWaB_0Ib_A46QZ=
2_iQks5vfjocgaJpZM4cikee.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<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 in #2593: There's text on this edge case, but not the interactio=
n with persistent congestion.\r\nhttps://tools.ietf.org/html/draft-ietf-q=
uic-recovery-19#section-6.3.2\r\n\"When a PTO timer expires, new or previ=
ously-sent data may not be\r\n   available to send and packets may still =
be in flight.  A sender can\r\n   be blocked from sending new data in the=
 future if packets are left in\r\n   flight.  Under these conditions, a s=
ender SHOULD mark any packets\r\n   still in flight as lost.  If a sender=
 wishes to establish delivery of\r\n   packets still in flight, it MAY se=
nd an ack-eliciting packet and re-\r\n   arm the PTO timer instead.\"\r\n=
\r\nI think if you follow either suggestion listed, you shouldn't inadver=
tently declare persistent congestion from being idle, since in one case y=
ou immediately declare packets lost and in the other, you'd only declare =
persistent congestion if the subsequent PTOs established it?"}],"action":=
{"name":"View Issue","url":"https://github.com/quicwg/base-drafts/issues/=
2593#issuecomment-481827995"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2593#issuecomment=
-481827995",
"url": "https://github.com/quicwg/base-drafts/issues/2593#issuecomment-48=
1827995",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5cae429c555fc_76083f91d06d45c41478fc--