On Tue, 27 May 2014, Dave Taht wrote:
On Tue, May 27, 2014 at 4:27 PM, David Lang <da...@lang.hm> wrote:
On Tue, 27 May 2014, Dave Taht wrote:
There is a phrase in this thread that is begging to bother me.
"Throughput". Everyone assumes that throughput is a big goal - and it
certainly is - and latency is also a big goal - and it certainly is -
but by specifying what you want from "throughput" as a compromise with
latency is not the right thing...
If what you want is actually "high speed in-order packet delivery" -
say, for example a movie,
or a video conference, youtube, or a video conference - excessive
latency with high throughput, really, really makes in-order packet
delivery at high speed tough.
the key word here is "excessive", that's why I said that for max throughput
you want to buffer as much as your latency budget will allow you to.
Again I'm trying to make a distinction between "throughput", and "packets
delivered-in-order-to-the-user." (for-which-we-need-a-new-word-I think)
The buffering should not be in-the-network, it can be in the application.
Take our hypothetical video stream for example. I am 20ms RTT from netflix.
If I artificially inflate that by adding 50ms of in-network buffering,
that means a loss can
take 120ms to recover from.
If instead, I keep a 3*RTT buffer in my application, and expect that I have 5ms
worth of network-buffering, instead, I recover from a loss in 40ms.
(please note, it's late, I might not have got the math entirely right)
but you aren't going to be tuning the retry wait time per connection. what is
the retry time that is set in your stack? It's something huge to survive
international connections with satellite paths (so several seconds worth). If
your server-to-eyeball buffering is shorter than this, you will get a window
where you aren't fully utilizing the connection.
so yes, I do think that if your purpose is to get the maximum possible in-order
packets delivered, you end up making different decisions than if you are just
trying to stream a HD video, or do other normal things.
The problem is thinking that this absolute throughput is representitive of
normal use.
As physical RTTs grow shorter, the advantages of smaller buffers grow larger.
You don't need 50ms queueing delay on a 100us path.
Many applications buffer for seconds due to needing to be at least
2*(actual buffering+RTT) on the path.
For something like streaming video, there's nothing wrong with the application
buffering aggressivly (assuming you have the space to do so on the client side),
the more you have gotten transmitted to the client, the longer it can survive a
disruption of it's network.
There's nothing wrong with having an hour of buffered data between the server
and the viewer's eyes.now, this buffering should not be in the network devices, it should be in the
client app, but this isn't because there's something wrong with bufferng, it's
just because the client device has so much more available space to hold stuff.
David Lang
You eventually lose a packet, and you have to wait a really long time
until a replacement arrives. Stuart and I showed that at last ietf.
And you get the classic "buffering" song playing....
Yep, and if you buffer too much, your "lost packet" is actually still in
flight and eating bandwidth.
David Lang
low latency makes recovery from a loss in an in-order stream much, much
faster.
Honestly, for most applications on the web, what you want is high
speed in-order packet delivery, not
"bulk throughput". There is a whole class of apps (bittorrent, file
transfer) that don't need that, and we
have protocols for those....
On Tue, May 27, 2014 at 2:19 PM, David Lang <da...@lang.hm> wrote:
the problem is that paths change, they mix traffic from streams, and in
other ways the utilization of the links can change radically in a short
amount of time.
If you try to limit things to exactly the ballistic throughput, you are
not
going to be able to exactly maintain this state, you are either going to
overshoot (too much traffic, requiring dropping packets to maintain your
minimal buffer), or you are going to undershoot (too little traffic and
your
connection is idle)
Since you can't predict all the competing traffic throughout the
Internet,
if you want to maximize throughput, you want to buffer as much as you can
tolerate for latency reasons. For most apps, this is more than enough to
cause problems for other connections.
David Lang
On Mon, 26 May 2014, David P. Reed wrote:
Codel and PIE are excellent first steps... but I don't think they are
the
best eventual approach. I want to see them deployed ASAP in CMTS' s and
server load balancing networks... it would be a disaster to not deploy
the
far better option we have today immediately at the point of most
leverage.
The best is the enemy of the good.
But, the community needs to learn once and for all that throughput and
latency do not trade off. We can in principle get far better latency
while
maintaining high throughput.... and we need to start thinking about
that.
That means that the framing of the issue as AQM is counterproductive.
On May 26, 2014, Mikael Abrahamsson <swm...@swm.pp.se> wrote:
On Mon, 26 May 2014, dpr...@reed.com wrote:
I would look to queue minimization rather than "queue management"
(which
implied queues are often long) as a goal, and think harder about the
end-to-end problem of minimizing total end-to-end queueing delay
while
maximizing throughput.
As far as I can tell, this is exactly what CODEL and PIE tries to do.
They
try to find a decent tradeoff between having queues to make sure the
pipe
is filled, and not making these queues big enough to seriously affect
interactive performance.
The latter part looks like what LEDBAT does?
<http://tools.ietf.org/html/rfc6817>
Or are you thinking about something else?
-- Sent from my Android device with K-@ Mail. Please excuse my brevity.
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
