Date: Wed, 10 Apr 2019 19:21:25 +0000 (UTC)
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abef0cc690ec858207954676ef3453e758856921d292cebabb74b592a169ce19a97bc9@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/481827438@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_5cae423598ce3_7e2e3fce2f0d45c0162774";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/ne_3BiXjGpSL8M7Gz8nmmxtgmu0>

----==_mimepart_5cae423598ce3_7e2e3fce2f0d45c0162774
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 packet loss 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-481827438
----==_mimepart_5cae423598ce3_7e2e3fce2f0d45c0162774
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 persistent =
congestion.<br>
<a href=3D"https://tools.ietf.org/html/draft-ietf-quic-recovery-19#section-=
6.3.2" rel=3D"nofollow">https://tools.ietf.org/html/draft-ietf-quic-recover=
y-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 inadverten=
tly declare persistent congestion from being idle, since in one case you im=
mediately declare packet loss and in the other, you'd only declare persiste=
nt congestion if the subsequent PTOs established it?</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&mda=
sh;<br />You are receiving this because you are subscribed to this thread.<=
br />Reply to this email directly, <a href=3D"https://github.com/quicwg/bas=
e-drafts/issues/2593#issuecomment-481827438">view it on GitHub</a>, or <a h=
ref=3D"https://github.com/notifications/unsubscribe-auth/AWbkq-Fz4dkiQZReKk=
WiXxJvIPU2uf8Pks5vfjm1gaJpZM4cikee">mute the thread</a>.<img src=3D"https:/=
/github.com/notifications/beacon/AWbkqwrvlEWqaUyQuxlInb8ffpi9Wb7sks5vfjm1ga=
JpZM4cikee.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_version"=
:"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"Gi=
tHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg=
/base-drafts","subtitle":"GitHub repository","main_image_url":"https://gith=
ub.githubassets.com/images/email/message_cards/header.png","avatar_image_ur=
l":"https://github.githubassets.com/images/email/message_cards/avatar.png",=
"action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-dra=
fts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@ianswett in #259=
3: There's text on this edge case, but not the interaction with persistent =
congestion.\r\nhttps://tools.ietf.org/html/draft-ietf-quic-recovery-19#sect=
ion-6.3.2\r\n\"When a PTO timer expires, new or previously-sent data may no=
t 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 lef=
t in\r\n   flight.  Under these conditions, a sender SHOULD mark any packet=
s\r\n   still in flight as lost.  If a sender wishes to establish delivery =
of\r\n   packets still in flight, it MAY send an ack-eliciting packet and r=
e-\r\n   arm the PTO timer instead.\"\r\n\r\nI think if you follow either s=
uggestion listed, you shouldn't inadvertently declare persistent congestion=
 from being idle, since in one case you immediately declare packet loss and=
 in the other, you'd only declare persistent congestion if the subsequent P=
TOs established it?"}],"action":{"name":"View Issue","url":"https://github.=
com/quicwg/base-drafts/issues/2593#issuecomment-481827438"}}}</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-4=
81827438",
"url": "https://github.com/quicwg/base-drafts/issues/2593#issuecomment-4818=
27438",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5cae423598ce3_7e2e3fce2f0d45c0162774--