[Bloat] CS244's work on netflix streaming

[Michael Richardson]

After reading both papers, I think that the take home that I got is:

      As we show in this paper, the problem arises because
      it is hard to estimate bandwidth above TCP

it seems that this is a service that TCP ought to be providing, and the
conclusion says so.  I think that it is an API issue, not a protocol issue.
If TCP knows how big the window was, it knows how much data can reasonably
have been sent, and since it also knows when it grew the window, it has some
notion of how long the new data took to arrive.

I think that the radical solution of not trying to estimate at all, but
rather, to increase the rate when the buffer is full, is rather analogous to
the bufferbloat problem:  vendors increased the size of buffers, and allowed
them to stay full, rather than decreased them until they they were
underrunning.

I'm curious to know what happens if the downlink to the client is
bufferbloated.  It seems that the long running flow ought to accumulate
significant amount of traffic with the result that the video client will see
a slow cwnd growth for each chunk that it requests.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [