Date: Tue, 26 Mar 2019 17:09:52 +0000 (UTC)
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab627cf063bcc02f5eafc8d3fd28b8bdfee012ea8392cf0000000118b21ee092a169ce195b9436@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2556/476751807@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2556@github.com>
References: <quicwg/base-drafts/issues/2556@github.com>
Subject: Re: [quicwg/base-drafts] Should kPersistentCongestionThreshold be 1
 or 2? (#2556)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c9a5ce056bef_24573f8b4b2d45b811030";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/UYdaMpOmJUw_2aP4BMV-tZk6hhA>

----==_mimepart_5c9a5ce056bef_24573f8b4b2d45b811030
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

*facepalm* @ianswett, of course. (Also, FWIW, PR #2557 makes this a simple multiplier, so let's just use that language.)

So I think I may have the opposite concern to @pravb. The mechanisms we are talking about are subtly different, so let's just talk about behavior instead of the mechanisms.

TCP RTO uses a minRTO while PTO does not. As a result, in the common case, persistent congestion for TCP will be declared at minRTO (or later). We risk declaring persistent congestion too soon with QUIC, even with 3 PTOs, since minRTO is at least 200ms for TCP, AFAIK. QUIC might be too aggressive in declaring persistent congestion.

This might be actually bad for performance. Anecdotally, I remember that Yuchung had tried turning on [RTO Restart](https://datatracker.ietf.org/meeting/85/materials/slides-85-tcpm-2) and found that it increased spurious RTOs.  While spurious PTOs are not bad in QUIC, we don't yet have a way to detect spuriously declared persistent congestion.

This makes me wonder if we should use a min value for declaring persistent congestion. I think this is justifiable as based on best current practice that we know in TCP and that declaring congestion too soon might hurt throughput. (Note that a min is still unnecessary for QUIC PTO because spurious PTOs have only minor bandwidth cost.)

As a strawman, I'll propose that we set the persistent congestion time period to max(PTO, 200ms).

Why PTO and not 3 * PTO? Because I believe (and someone can prove me wrong) that TCP actually does use a single RTO period for declaring an RTO, despite potentially sending TLPs in that time period.
>From the RACK draft, my understanding is that sending TLPs in TCP does not actually change the RTO timer, which runs for the same amount of time (from the last ack received in practice or the earliest outstanding data).

-- 
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/2556#issuecomment-476751807
----==_mimepart_5c9a5ce056bef_24573f8b4b2d45b811030
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p><em>facepalm</em> <a class=3D"user-mention" data-hovercard-type=3D"user"=
 data-hovercard-url=3D"/hovercards?user_id=3D20072817" data-octo-click=3D"h=
overcard-link-click" data-octo-dimensions=3D"link_type:self" href=3D"https:=
//github.com/ianswett">@ianswett</a>, of course. (Also, FWIW, PR <a class=
=3D"issue-link js-issue-link" data-error-text=3D"Failed to load issue title=
" data-id=3D"425506121" data-permission-text=3D"Issue title is private" dat=
a-url=3D"https://github.com/quicwg/base-drafts/issues/2557" data-hovercard-=
type=3D"pull_request" data-hovercard-url=3D"/quicwg/base-drafts/pull/2557/h=
overcard" href=3D"https://github.com/quicwg/base-drafts/pull/2557">#2557</a=
> makes this a simple multiplier, so let's just use that language.)</p>
<p>So I think I may have the opposite concern to <a class=3D"user-mention" =
data-hovercard-type=3D"user" data-hovercard-url=3D"/hovercards?user_id=3D12=
821832" data-octo-click=3D"hovercard-link-click" data-octo-dimensions=3D"li=
nk_type:self" href=3D"https://github.com/pravb">@pravb</a>. The mechanisms =
we are talking about are subtly different, so let's just talk about behavio=
r instead of the mechanisms.</p>
<p>TCP RTO uses a minRTO while PTO does not. As a result, in the common cas=
e, persistent congestion for TCP will be declared at minRTO (or later). We =
risk declaring persistent congestion too soon with QUIC, even with 3 PTOs, =
since minRTO is at least 200ms for TCP, AFAIK. QUIC might be too aggressive=
 in declaring persistent congestion.</p>
<p>This might be actually bad for performance. Anecdotally, I remember that=
 Yuchung had tried turning on <a href=3D"https://datatracker.ietf.org/meeti=
ng/85/materials/slides-85-tcpm-2" rel=3D"nofollow">RTO Restart</a> and foun=
d that it increased spurious RTOs.  While spurious PTOs are not bad in QUIC=
, we don't yet have a way to detect spuriously declared persistent congesti=
on.</p>
<p>This makes me wonder if we should use a min value for declaring persiste=
nt congestion. I think this is justifiable as based on best current practic=
e that we know in TCP and that declaring congestion too soon might hurt thr=
oughput. (Note that a min is still unnecessary for QUIC PTO because spuriou=
s PTOs have only minor bandwidth cost.)</p>
<p>As a strawman, I'll propose that we set the persistent congestion time p=
eriod to max(PTO, 200ms).</p>
<p>Why PTO and not 3 * PTO? Because I believe (and someone can prove me wro=
ng) that TCP actually does use a single RTO period for declaring an RTO, de=
spite potentially sending TLPs in that time period.<br>
>From the RACK draft, my understanding is that sending TLPs in TCP does not =
actually change the RTO timer, which runs for the same amount of time (from=
 the last ack received in practice or the earliest outstanding data).</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/2556#issuecomment-476751807">view it on GitHub</a>, or <a h=
ref=3D"https://github.com/notifications/unsubscribe-auth/AWbkq9oC9D-WCr1h9S=
QxQD6evvCx-PiTks5valRggaJpZM4cLgN2">mute the thread</a>.<img src=3D"https:/=
/github.com/notifications/beacon/AWbkq2gZF5OGZ1JvLXUgAvZTMtHRuLlgks5valRgga=
JpZM4cLgN2.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":"@janaiyengar in #=
2556: *facepalm* @ianswett, of course. (Also, FWIW, PR #2557 makes this a s=
imple multiplier, so let's just use that language.)\r\n\r\nSo I think I may=
 have the opposite concern to @pravb. The mechanisms we are talking about a=
re subtly different, so let's just talk about behavior instead of the mecha=
nisms.\r\n\r\nTCP RTO uses a minRTO while PTO does not. As a result, in the=
 common case, persistent congestion for TCP will be declared at minRTO (or =
later). We risk declaring persistent congestion too soon with QUIC, even wi=
th 3 PTOs, since minRTO is at least 200ms for TCP, AFAIK. QUIC might be too=
 aggressive in declaring persistent congestion.\r\n\r\nThis might be actual=
ly bad for performance. Anecdotally, I remember that Yuchung had tried turn=
ing on [RTO Restart](https://datatracker.ietf.org/meeting/85/materials/slid=
es-85-tcpm-2) and found that it increased spurious RTOs.  While spurious PT=
Os are not bad in QUIC, we don't yet have a way to detect spuriously declar=
ed persistent congestion.\r\n\r\nThis makes me wonder if we should use a mi=
n value for declaring persistent congestion. I think this is justifiable as=
 based on best current practice that we know in TCP and that declaring cong=
estion too soon might hurt throughput. (Note that a min is still unnecessar=
y for QUIC PTO because spurious PTOs have only minor bandwidth cost.)\r\n\r=
\nAs a strawman, I'll propose that we set the persistent congestion time pe=
riod to max(PTO, 200ms).\r\n\r\nWhy PTO and not 3 * PTO? Because I believe =
(and someone can prove me wrong) that TCP actually does use a single RTO pe=
riod for declaring an RTO, despite potentially sending TLPs in that time pe=
riod.\r\nFrom the RACK draft, my understanding is that sending TLPs in TCP =
does not actually change the RTO timer, which runs for the same amount of t=
ime (from the last ack received in practice or the earliest outstanding dat=
a)."}],"action":{"name":"View Issue","url":"https://github.com/quicwg/base-=
drafts/issues/2556#issuecomment-476751807"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2556#issuecomment-4=
76751807",
"url": "https://github.com/quicwg/base-drafts/issues/2556#issuecomment-4767=
51807",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c9a5ce056bef_24573f8b4b2d45b811030--