From: Jonathan Morton <chromatix99@gmail.com>
To: Fred Baker <fred@cisco.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCPflavours - timestamps?
Date: Sun, 20 Mar 2011 13:40:52 +0200 [thread overview]
Message-ID: <BB411AFB-1FF7-428A-BE42-6029B7E61D8C@gmail.com> (raw)
In-Reply-To: <7480559F-1F3B-4CE5-939F-FD9FD3E68E52@cisco.com>
On 18 Mar, 2011, at 8:49 pm, Fred Baker wrote:
>> How about trying to push for a default, that the logical egress buffers are limited to say 90% of the physical capacity, and only ECN-enabled flows may use the remaining 10% when they get marked...
>
> Lots of questions in that; 90% of the buffers in what? In a host, in a router, on a card in a router, in a queue's configured maximum depth, what? One would need some pedagogic support in the form of simulations - why 90% vs 91% vs 10% vs whatever?
>
>> Someone has to set an incentive for using ECN, unfortunately...
>
> Yes. From my perspective, the right approach is probably more like introducing a mark/drop threshold and a drop threshold. Taking the model that every M time units we "do something" like
>
> if queue depth exceeds <toobig>
> reduce M
> drop something
> else if queue depth exceeds <big>
> reduce M
> select something
> if it is ECN-capable,
> mark it congestion-experienced
> else
> drop it
> else is below <hysteresis limit>
> increase M
>
> the advantage of ECN traffic is that it is less likely to be dropped. That might be a reasonable approach.
That does actually seem reasonable. What's the betting that HW vendors still say it's too complicated? :-D
I think we can come up with some simple empirical rules for choosing queue sizes. I may be half-remembering something VJ wrote, but here's a starting point:
0) Buffering more than 1 second of data is always unacceptable.
1) Measure (or estimate) the RTT of a full-sized packet over the exit link and back, then add 100ms for typical Internet latency, calling this total T1. If T1 is more than 500ms, clamp it to 500ms. Calculate T2 to be twice T1; this will be at most 1000ms.
2) Measure (or estimate) the throughput BW of the exit link, in bytes per second.
3) Calculate ideal queue length (in bytes) Q1 as T1 * BW, and the maximal queue length Q2 as T2 * BW. These may optionally be rounded to the nearest multiple of a whole packet size, if that is convenient for the hardware.
4) If the link quality is strongly time-varying, eg. mobile wireless, recalculate Q1 and Q2 as above regularly.
5) If the link speed depends on the type of equipment at the other end, the quality of cabling, or other similar factors, use the actual negotiated link speed when calculating BW. When these factors change, recalculate as above.
I would take the "hysteresis limit" to be an empty queue for the above algorithm.
- Jonathan
next prev parent reply other threads:[~2011-03-20 11:41 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-15 10:36 [Bloat] Random idea in reaction to all the discussion of TCP flavours " 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 [this message]
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
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=BB411AFB-1FF7-428A-BE42-6029B7E61D8C@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=fred@cisco.com \
--cc=shemminger@vyatta.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