From: "David P. Reed" <dpreed@deepplum.com>
To: "Jonathan Morton" <chromatix99@gmail.com>
Cc: "Jonathan Foulkes" <jf@jonathanfoulkes.com>,
"Rich Brown" <richb.hanover@gmail.com>,
"cerowrt-devel" <cerowrt-devel@lists.bufferbloat.net>,
"bloat" <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] (no subject)
Date: Sat, 18 May 2019 22:06:04 -0400 (EDT) [thread overview]
Message-ID: <1558231564.2493747@apps.rackspace.com> (raw)
In-Reply-To: <DDAB928C-31F7-4A4A-9463-BDB182E8E160@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]
Correction accepted. Between the US east and west coasts, the time of flight of packets on fiber or cable is about 23 msec. (Boston-LA, driving route, over fiber, at 207 Mm/sec).
So, if all intermediate links are equal in rate, at say, 10 Gb/sec, that means that there should be no more than 10,000,000,000 * 0.023 bits actually in transit on the actual fiber, plus a packet in each router between's outbound queue. Let's say a packet is around 1500 bytes, or 12,000 bits, since that is the MTU we stupidly enforce even today, and there are 10 hops (typical today between Boston and LA.)
So we would expect the optimal window size sum, for all flows on any hop of that path to be 10 * 12000 bits + 230,000,000 bits:
230,120,000 bits in flight between BOS and LAX. Divide that by 12,000 bits/packet, and you get about 19,177 packets along that path. At most points along the path, you would expect about 10 different flows or more to be in flight, so there would be, optimally, about 1,918 1500 byte packets. Each flow would get 1 Gb/sec as its share.
If the connection is limited to < 1 Gb/sec at either endpoint, then there's no reason for any intermediate node to buffer that much of the flow.
This gives a reasonable understanding of where AQM should be ending up in terms of the cwnd needed to sustain max throughput and optimum end-to-end latency (which would be about 23 msec + 10 hops * 12000 / 1 Gb/sec. = 23.012 msec. for a packet to get from one end to the other).
On Saturday, May 18, 2019 6:57pm, "Jonathan Morton" <chromatix99@gmail.com> said:
> > On 19 May, 2019, at 1:36 am, David P. Reed <dpreed@deepplum.com>
> wrote:
> >
> > Pardon, but cwnd should NEVER be larger than the number of forwarding hops
> between source and destination.
> > Kleinrock and students recently proved that the optimum cwnd for both
> throughput and minimized latency is achieved when there is one packet or less in
> each outbound queue from source to destination (including cross traffic - meaning
> other flows sharing the same outbound queue.
>
> This argument holds only if time-of-flight *between* nodes is negligible.
> Trivially, a geosynchronous satellite hop adds only two nodes but approximately
> half a second to the one-way path delay, with potentially thousands of packets
> existing only as radio waves in the distance between, not in a queue.
>
> - Jonathan Morton
>
>
[-- Attachment #2: Type: text/html, Size: 4282 bytes --]
next prev parent reply other threads:[~2019-05-19 2:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 12:16 [Cerowrt-devel] fq_codel is SEVEN years old today Rich Brown
2019-05-14 17:57 ` Valdis Klētnieks
2019-05-14 18:38 ` David P. Reed
2019-05-14 22:05 ` David P. Reed
2019-05-14 22:35 ` [Cerowrt-devel] [Bloat] " Toke Høiland-Jørgensen
2019-05-14 23:34 ` David P. Reed
2019-05-15 7:31 ` [Cerowrt-devel] (no subject) Sebastian Moeller
2019-05-15 7:58 ` [Cerowrt-devel] [Bloat] " Dave Taht
2019-05-15 8:30 ` Sebastian Moeller
2019-05-16 22:01 ` Jonathan Foulkes
2019-05-18 22:36 ` David P. Reed
2019-05-18 22:57 ` Jonathan Morton
2019-05-18 23:06 ` Jonathan Morton
2019-05-19 2:06 ` David P. Reed [this message]
2019-05-16 16:40 ` Jonathan Foulkes
2019-05-16 22:12 ` Sebastian Moeller
2019-05-18 11:36 ` [Cerowrt-devel] [Bloat] fq_codel is SEVEN years old today Dave Taht
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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1558231564.2493747@apps.rackspace.com \
--to=dpreed@deepplum.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=jf@jonathanfoulkes.com \
--cc=richb.hanover@gmail.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