[Bloat] CS244's work on netflix streaming

[Bloat] CS244's work on netflix streaming

[Dave Taht]

I really love the work that stanford's CS244 does.

I was reading this paper about netflix's "downward spiral" problem...

http://www.stanford.edu/~huangty/imc012-huang.pdf

When greg white pointed me at this wonderful followup:

http://reproducingnetworkresearch.wordpress.com/2013/03/13/cs244-13-rising-
from-the-depths-observing-and-implementing-improvements-in-online-video-bit
rate-selection/

"The students' goal was to reproduce the research done in the Huang paper.
What they found was that in the interim Netflix had fixed the problems
outlined by Huang, so they reverse engineered the original Netflix rate
adaptation algorithm, and then evaluated several new rate adaptation
approaches.

Cool stuff."

Also the discussion of "remy" going on is pretty nifty.

https://plus.google.com/u/0/103530621949492999968/posts/2L9e4kxo9y3

[Bloat] The Remy paper (was: Re: CS244's work on netflix streaming)

[Eric S. Raymond]

Dave Taht <dave.taht@gmail.com>:
> Also the discussion of "remy" going on is pretty nifty.
> 
> https://plus.google.com/u/0/103530621949492999968/posts/2L9e4kxo9y3

Thanks for that link.  I've been mad curious what your tak on the Remy 
paper was ever since I read it myself. Because while I didn't spot any
obvious bogons, you know the domain far better than I do.

The only thing about their methods that troubles me is a suspicion that the
generated algorithms might be overspecialized - that is, very vulnerable 
to small changes in traffic statistics.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Bloat] The Remy paper (was: Re: CS244's work on netflix streaming)

[Dave Taht]

On Mon, Jul 22, 2013 at 2:21 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Dave Taht <dave.taht@gmail.com>:
>> Also the discussion of "remy" going on is pretty nifty.
>>
>> https://plus.google.com/u/0/103530621949492999968/posts/2L9e4kxo9y3
>
> Thanks for that link.  I've been mad curious what your tak on the Remy
> paper was ever since I read it myself. Because while I didn't spot any
> obvious bogons, you know the domain far better than I do.

Well, it's a little presently computationally intensive for this decade...


> The only thing about their methods that troubles me is a suspicion that the
> generated algorithms might be overspecialized - that is, very vulnerable
> to small changes in traffic statistics.

They point that out too, in (for example) in fig 11. I LIKE fig 11, I
keep thinking about it - although codel is designed to run against
varying link rates, it makes sense to optimize for the most observed
actual bandwidth, if possible, and this result shows that is possible.
(if not understandable). So, what if you could generate a model
showing your bandwidth range at location Z is X, optimize for that,
download it and run it?

I also like their presentation plot mechanism inverting the queue
delay against throughput to make a "best" result up and to the right
(see fig 4 and 5). I'll use this in future versions of rrul in
particular.

The thing is, we are exploring a very difficult subject (congestion
control) with the equivalent of stone knives and bearskins. We have
all this computing power lying around, serving ads! Why not use that
in useful fashions? Take for comparison, the kind of work and compute
resources that have been poured into physics and sigh.

While they restrict their argument to e2e computation, the same
techniques could apply to optimizing edge networks and interprovider
interconnects, the core, calcuating better multi-path routing, and so
on... for which running a model of existing traffic then implementing
it and iterating fairly rapidly could be automated...

I don't mind being obsoleted...

"How should we design network protocols that free subnetworks and
links to evolve freely, ensuring that the endpoints will adapt prop-
erly no matter what the lower layers do? We believe that the best
way to approach this question is to take the design of specific algo-
rithmic mechanisms out of the hands of human designers (no matter
how sophisticated!), and make the end-to-end algorithm be a func-
tion of the desired overall behavior. "

...

I'm unfond of how g+ (and now email) splits up a conversation, here's
what I said on another thread of discussion:
https://plus.google.com/u/0/107942175615993706558/posts/8MRTLpRyAju

"My happiness at the paper is keyed on three factors: 1) identifying
what a perfect algorithm could be like and the boundaries for it is
inspiring as a goal,

2) and being able to study those results in search of inspiration... and

3) (if you didn't notice), just how well sfqcodel did across a wide
range of benchmarks. No, it wasn't as good as specialized algos that
took weeks of compute time, but it hit a sweet spot in most cases, and
it ain't my fault cubic is so aggressive. I thought of the result as
"kasperov vs deep blue", with clear win on the chess clock, to
kasperov." (kasperov being kathie, van and eric)

Now, I've been looking at bittorrent traffic of late - principal
preliminary result is that traffic in slow start competes well with
it, long duration traffic less so but still gets about double it's
"fair share" (still don't understand the result) and under fq_codel to
compete like that it drops a LOT of packets.

> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [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@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [