[quicwg/base-drafts] TLP and RTO arbitrariness (#2166)

janaiyengar <notifications@github.com> Thu, 13 December 2018 22:30 UTC

Date: Thu, 13 Dec 2018 22:30:31 +0000
From: janaiyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab01fe96969c3f7d945a2f17ad638e9e6e0781672b92cf00000001182a9f8792a169ce174c7df5@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2166@github.com>
Subject: [quicwg/base-drafts] TLP and RTO arbitrariness (#2166)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c12dd87b335f_4eaf3fae87cd45b82084a8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/h_Jmmq7jCaHm2jQf__Nl5_6I6AE>

There is some arbitrariness around TLP, RTO, and crypto timeouts  as they are described in the draft. 

- TLP computation includes smoothed_rtt but not rttvar, where RTO includes both. There's no clear rationale for not using rttvar in TLP.  This is what the TLP draft (individual, expired) says and what Linux TCP implements, but there's little justification beyond that. rttvar should be included here.
- minTLP is 10ms and minRTO is 200ms. This choice of 10ms is a bit arbitrary, but is based on what Linux TCP implements.
- The crypto timeout uses minTLP, which does not seem intuitive.

We should include rttvar in TLP, and we should either justify the 10ms min timeout or use the same 200ms timeout for TLP.  We should also use a different min for the crypto timeout than min TLP.

-- 
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/2166

[quicwg/base-drafts] TLP and RTO arbitrariness (#… janaiyengar
Re: [quicwg/base-drafts] TLP and RTO arbitrarines… janaiyengar