From: Hagen Paul Pfeifer <hagen@jauu.net>
To: Yuchung Cheng <ycheng@google.com>
Cc: Daniel Metz <dmetz@mytum.de>, netdev <netdev@vger.kernel.org>,
Daniel Metz <daniel.metz@rohde-schwarz.com>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH net-next v2] tcp: use RFC6298 compliant TCP RTO calculation
Date: Wed, 15 Jun 2016 19:41:14 +0200 [thread overview]
Message-ID: <20160615174114.GA16217@virgo.localdomain> (raw)
In-Reply-To: <CAK6E8=eeso8OEN_0-znqkuEyVTqzP1mTvwktk4QOsrLJXmuj9Q@mail.gmail.com>
* Yuchung Cheng | 2016-06-14 14:33:18 [-0700]:
>> + tp->rttvar_us = tp->mdev_us;
>AFAICT we can update rttvar_us directly and don't need mdev_us anymore?
Yes, v3 will remove mdev_us.
>This is more aggressive than RFC6298 that RTO <- SRTT + max (G,
>K*RTTVAR) where G = MIN_RTO = 200ms
>
>based on our discussion, in the spirit of keeping RTO more
>conservative, I recommend we implement RFC formula. Acks being delayed
>over 200ms is not uncommon (unfortunately due to bloat or other
>issues).
>
>Also I think we should change __tcp_set_rto so that the formula
>applies to backoffs or ICMP timeouts calculations too.
We are a unsure what you mean Yuchung. We believe this patch not to be more
aggressive than RFC 6298. In fact, we believe it to be RFC 6298 compliant, as
in RFC 6298, G is the clock granularity and we don’t see where it deviates
from the RFC. However, it is more aggressive than “RTO <- SRTT + max (G,
K*RTTVAR) where G = MIN_RTO = 200ms”. Which formula do you want to implement?
Hagen
next prev parent reply other threads:[~2016-06-15 17:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-13 20:45 [PATCH net-next] tcp: use RFC6298 compliant TCP RTO calculation Daniel Metz
2016-06-13 21:19 ` Eric Dumazet
2016-06-13 22:38 ` Yuchung Cheng
2016-06-14 6:17 ` Hagen Paul Pfeifer
2016-06-14 17:58 ` Yuchung Cheng
2016-06-14 19:18 ` [PATCH net-next v2] " Daniel Metz
2016-06-14 21:33 ` Yuchung Cheng
2016-06-15 17:41 ` Hagen Paul Pfeifer [this message]
2016-06-15 18:02 ` Yuchung Cheng
2016-06-15 20:34 ` Daniel Metz
2016-06-15 20:38 ` Eric Dumazet
2016-06-15 21:07 ` Yuchung Cheng
2016-06-16 9:07 ` Hagen Paul Pfeifer
2016-06-16 9:03 ` Hagen Paul Pfeifer
2016-06-15 18:00 ` [PATCH net-next v3] " Daniel Metz
2016-06-17 18:32 ` David Miller
2016-06-17 18:56 ` Yuchung Cheng
2016-06-22 5:53 ` Yuchung Cheng
2016-06-22 11:21 ` Hagen Paul Pfeifer
2016-06-22 20:50 ` Yuchung Cheng
2016-06-29 7:06 ` Yuchung Cheng
2016-06-29 20:18 ` Daniel Metz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160615174114.GA16217@virgo.localdomain \
--to=hagen@jauu.net \
--cc=daniel.metz@rohde-schwarz.com \
--cc=dmetz@mytum.de \
--cc=edumazet@google.com \
--cc=netdev@vger.kernel.org \
--cc=ycheng@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox