From: Jonathan Morton <chromatix99@gmail.com>
To: rick.jones2@hp.com
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps?
Date: Thu, 17 Mar 2011 23:50:02 +0200 [thread overview]
Message-ID: <44F5E713-4AB2-4D34-9DD5-97FBE92E401F@gmail.com> (raw)
In-Reply-To: <1300386132.2087.2345.camel@tardy>
On 17 Mar, 2011, at 8:22 pm, Rick Jones wrote:
>> For the benefit of the 3G folks, here are some helpful axioms to discuss:
>>
>> 1) Buffering more than a couple of seconds of data (without employing
>> AQM) is unhelpful, and will actually increase network load without
>> increasing goodput. Unless there is a compelling reason, you should
>> try to buffer less than a second.
>>
>> This is because congestion and packet-loss information takes longer to
>> influence existing flows, and new flows are more difficult to start.
>> After about 3 seconds of no information, most TCPs will start
>> retransmission - regardless of whether the packets were physically
>> lost, or are simply languishing in a multi-megabyte buffer somewhere.
>
> So initialRTO is specced currently to be 3 seconds, with a small but
> non-trivial effort under way to reduce that, but once established
> connections have a minimum RTO of less than or equal to a second don't
> they?
If the RTT they measure is low enough, then yes. If the queues lengthen, the measured RTT goes up and so does the RTO, once the connection is established.
But the *initial* RTO is the important one for unmanaged queue sizing, because that determines whether a new connection can be started without retransmissions, all else functioning correctly of course. There is no way to auto-tune that.
Note also that with AQM that can re-order packets, the length of the bulk queue starts to matter much less, because the SYN/ACK packets can bypass most of the traffic. In that case the RTT measured by the existing bulk flows will be higher than the latency seen by new and interactive flows.
- Jonathan
next prev parent reply other threads:[~2011-03-17 21:50 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-15 10:36 Jim Gettys
2011-03-15 14:40 ` Jim Gettys
2011-03-15 16:47 ` Jonathan Morton
2011-03-15 17:59 ` Don Marti
2011-03-15 18:14 ` Rick Jones
2011-03-15 18:31 ` John W. Linville
2011-03-15 19:40 ` Jonathan Morton
2011-03-15 19:59 ` Rick Jones
2011-03-15 20:51 ` John W. Linville
2011-03-15 21:31 ` Rick Jones
2011-03-16 0:32 ` John W. Linville
2011-03-16 1:02 ` Rick Jones
2011-03-15 22:01 ` Jonathan Morton
2011-03-15 22:19 ` Stephen Hemminger
2011-03-15 22:26 ` Jonathan Morton
2011-03-15 22:36 ` Rick Jones
2011-03-15 22:40 ` Jonathan Morton
2011-03-15 22:42 ` Stephen Hemminger
2011-03-15 22:52 ` Eric Dumazet
2011-03-15 23:02 ` Rick Jones
2011-03-15 23:12 ` Jonathan Morton
2011-03-15 23:25 ` Rick Jones
2011-03-15 23:33 ` Jonathan Morton
2011-03-15 23:46 ` Dave Täht
2011-03-16 0:49 ` Jonathan Morton
2011-03-16 1:02 ` Dave Täht
2011-03-16 1:28 ` Jonathan Morton
2011-03-16 1:59 ` Dave Täht
2011-03-16 2:23 ` Jonathan Morton
2011-03-16 22:22 ` [Bloat] Random idea in reaction to all the discussion of TCPflavours " Richard Scheffenegger
2011-03-16 23:38 ` richard
2011-03-16 23:50 ` Rick Jones
2011-03-17 12:05 ` Fred Baker
2011-03-17 12:18 ` Fred Baker
2011-03-17 17:27 ` Dave Täht
2011-03-18 18:30 ` Richard Scheffenegger
2011-03-18 18:49 ` Fred Baker
2011-03-20 11:40 ` Jonathan Morton
2011-03-20 22:18 ` david
2011-03-20 22:45 ` Jonathan Morton
2011-03-20 22:50 ` Dave Täht
2011-03-20 22:55 ` grenville armitage
2011-03-20 23:04 ` Dave Täht
2011-03-20 23:14 ` Jonathan Morton
2011-03-20 23:19 ` Dave Täht
2011-03-20 23:23 ` Dave Täht
2011-03-20 22:58 ` Jonathan Morton
2011-03-21 1:28 ` david
2011-03-21 1:56 ` Wesley Eddy
2011-03-18 18:27 ` [Bloat] Random idea in reaction to all the discussion ofTCPflavours " Richard Scheffenegger
2011-03-16 22:07 ` [Bloat] Random idea in reaction to all the discussion of TCPflavours " Richard Scheffenegger
2011-03-17 0:10 ` Jonathan Morton
2011-03-16 0:47 ` [Bloat] Random idea in reaction to all the discussion of TCP flavours " John W. Linville
2011-03-16 20:07 ` Jim Gettys
2011-03-17 2:26 ` Jonathan Morton
2011-03-17 18:22 ` Rick Jones
2011-03-17 21:50 ` Jonathan Morton [this message]
2011-03-17 22:20 ` Rick Jones
2011-03-17 22:56 ` Jonathan Morton
2011-03-18 1:36 ` Justin McCann
2011-03-18 5:51 ` Eric Dumazet
2011-03-15 16:34 ` Jonathan Morton
2011-03-15 18:13 ` Stephen Hemminger
2011-03-16 5:41 ` Fred Baker
2011-03-16 6:26 ` Jonathan Morton
2011-03-16 8:55 ` [Bloat] Random idea in reaction to all the discussion of TCPflavours " Richard Scheffenegger
2011-03-16 9:04 ` [Bloat] Random idea in reaction to all the discussion of TCP flavours " BeckW
2011-03-16 22:48 ` Fred Baker
2011-03-16 23:23 ` Jonathan Morton
2011-03-17 8:34 ` BeckW
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
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44F5E713-4AB2-4D34-9DD5-97FBE92E401F@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=rick.jones2@hp.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