Date: Fri, 15 Dec 2017 20:27:07 +0000 (UTC)
From: Subodh Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abf0496788c20f2348546d57dd16d94ad95277200d92cf00000001164bf21b92a169ce10d715c1@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1017/352103712@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1017@github.com>
References: <quicwg/base-drafts/issues/1017@github.com>
Subject: Re: [quicwg/base-drafts] Eliminating the fixed minimum RTO (#1017)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5a34301ba3a22_7593f9e72de2f3814626";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/_9WupOKx0I0VcD0zs64gnYIPoig>

----==_mimepart_5a34301ba3a22_7593f9e72de2f3814626
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

Strongly agree with this proposal. 

I think communicating MAD is very important to replace this. There could be a case that a sender decided to set their RTO too low due to a receiver delaying ACKs. I anticipate that this might happen right after the handshake because handshake packets would be acked usually immediately thus setting RTO close to the RTT, however after handshake the receiver might start delaying acks for regular data. 

Another case is if a spurious RTO triggers an ACK from the receiver QUIC would only get an RTT sample from the ack of the RTO instead of getting the sample from the original packet. So it seems important to include ack delay into the RTO computations.

-- 
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/1017#issuecomment-352103712
----==_mimepart_5a34301ba3a22_7593f9e72de2f3814626
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>Strongly agree with this proposal.</p>
<p>I think communicating MAD is very important to replace this. There could=
 be a case that a sender decided to set their RTO too low due to a receiver=
 delaying ACKs. I anticipate that this might happen right after the handsha=
ke because handshake packets would be acked usually immediately thus settin=
g RTO close to the RTT, however after handshake the receiver might start de=
laying acks for regular data.</p>
<p>Another case is if a spurious RTO triggers an ACK from the receiver QUIC=
 would only get an RTT sample from the ack of the RTO instead of getting th=
e sample from the original packet. So it seems important to include ack del=
ay into the RTO computations.</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/1017#issuecomment-352103712">view it on GitHub</a>, or <a h=
ref=3D"https://github.com/notifications/unsubscribe-auth/AWbkqydefFHBB5Hmd9=
i4p4gv1mT5ifqTks5tAtYbgaJpZM4RD7go">mute the thread</a>.<img alt=3D"" heigh=
t=3D"1" src=3D"https://github.com/notifications/beacon/AWbkqzVZKQUCm5kDu6xg=
eZRFJhZbqKbfks5tAtYbgaJpZM4RD7go.gif" width=3D"1" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewAction=
">
  <link itemprop=3D"url" href=3D"https://github.com/quicwg/base-drafts/issu=
es/1017#issuecomment-352103712"></link>
  <meta itemprop=3D"name" content=3D"View Issue"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Issue on GitHub"></meta>
</div>

<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://clou=
d.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290=
892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/asset=
s/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name=
":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates=
":{"snippets":[{"icon":"PERSON","message":"@siyengar in #1017: Strongly agr=
ee with this proposal. \r\n\r\nI think communicating MAD is very important =
to replace this. There could be a case that a sender decided to set their R=
TO too low due to a receiver delaying ACKs. I anticipate that this might ha=
ppen right after the handshake because handshake packets would be acked usu=
ally immediately thus setting RTO close to the RTT, however after handshake=
 the receiver might start delaying acks for regular data. \r\n\r\nAnother c=
ase is if a spurious RTO triggers an ACK from the receiver QUIC would only =
get an RTT sample from the ack of the RTO instead of getting the sample fro=
m the original packet. So it seems important to include ack delay into the =
RTO computations."}],"action":{"name":"View Issue","url":"https://github.co=
m/quicwg/base-drafts/issues/1017#issuecomment-352103712"}}}</script>=

----==_mimepart_5a34301ba3a22_7593f9e72de2f3814626--