On Fri, 27 Mar 2015, Bill Ver Steeg (versteb) wrote:
Dave Lang-
Yup, you got the intent.
The ABR video delivery stack is actually one level more complex. The
application uses plain old HTTP to receive N==2 second chunks of video, which
in turn uses TCP to get the data, which in turn interacts with the various
queuing mechanisms, yada, yada, yada. So, the application rate adaptation
logic is using the HTTP transfer rate to decide whether to upshift to a higher
video rate, downshift to a lower video rate, or stay at the current video rate
at each chunk boundary.
There are several application layer algorithms in use (Netflix, MPEG DASH,
Apple, Microsoft, etc), and many of them use more than one TCP/HTTP session to
get chunks. Lots of moving parts, and IMHO most of these developers are more
concerned with getting the best possible throughput than being bloat-friendly.
Driving the network at the perceived available line rate for hours at a time
is simply not network friendly.....
although if the user is only using the line for this purpose, it may be exactly
the right thing to do :-/
Clearly, the newer AQM algorithms will handle these types of aggressive ABR
algorithms better. There also may be a way to tweak the ABR algorithm to "do
the right thing" and make the system work better - both from a "make my video
better" standpoint and a "don't impact cross traffic" standpoint. As a start,
I am thinking of ways to keep the sending rate between the max video rate and
the (perceived) network rate. This does impact how such a flow competes with
other flows, and
You aren't really going to be able to measure your impact on other traffic
(unless you can have the client do something else at the same time that would
show the latency)
We've been working for a long time to directly measure bufferbloat and it's been
quite a struggle. The best that we've been able to do is to compare the ping
response time while under load and watch for it to climb (it tends to go up
_very_ quickly when bufferbloat starts kicking in)
Regarding peeking into the kernel ----- The overall design of the existing
systems assumes that they need to run on several OSes/platforms, and therefore
they (generally) do not peak into the kernel. I have done some work that does
look into the kernel to examine TCP receive queue sizes ---
https://smartech.gatech.edu/bitstream/handle/1853/45059/GT-CS-12-07.pdf -- and
it worked pretty well. That scheme would be difficult to productize, and I am
thinking about server-based methods in addition to client based methods to
keep out congestion jail. Perhaps using HTTP pragmas to have the client signal
the desired send rate to the HTTP server.
I was thinking in terms of the sender peeking into the kernel, you normally have
a much more limited set of OSs on your server. But if you are transferring
things via a standard HTTP server, you can't do this.
do you really have any better option than saying "I expected it to take X ms to
send 2 sec worth of data, but it took X + Y ms to finish the HTTP transfer" and
then take action based on the value of Y (which could be negative if the
connection improved)?
If you have the ability to do something else (something very lightweight,
ideally UDP based so you don't have TCP retries to deal with) in a separate
connection while you are downloading the 2s of video and can detect the delays
of that.
David Lang
Bill Ver Steeg
-----Original Message-----
From: David Lang [mailto:[email protected]]
re-reading your post for the umpteenth time, here's what I think I may be
seeing.
you are working on developing video streaming software that can adapt the bit
rate of the streaming video to have it fit within the available bandwidth. You
are trying to see how this interacts with the different queuing options.
Is this a good summary?
If so, then you are basically wanting to do the same thing that the TCP stack
is doing and when you see a dropped packet or ECN tagged packet, slow down the
bit rate of the media that you are streaming so that it will use less
bandwidth.
This sounds like an extremely interesting thing to do, it will be interesting
to see the response from folks who know the deeper levels of the OS as to what
options you have to learn that such events have taken place.
David Lang
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
