[MUSIC] The last application layer technique we will discuss is rate adaptation in video streaming. The goal here is to provide the best video streaming experience in the face of variable network bandwidth. Obviously we'd like the highest possible video resolution. So we'd prefer the picture on the right to the picture on the left. But at the same time we'd like to avoid waiting for buffering. Buffering does help a lot. It can mask variations in the network's performance. In fact even interactive applications like Skype use buffering on the order of 100 milliseconds or so. For streaming with the applications, several seconds of buffering is seen as acceptable, because these aren't interactive. You can fill up the buffer in the beginning, start playing smoothly. And then the buffer covers up variations in the networks bandwidth. So as the available bandwidth reduces. The buffer drains a little bit, and as the bandwidth increases, the buffer fills up again. And hopefully you don't see the buffer empty. And the stream plays smoothly. But if the buffer does empty out, you have a pause in the playback, and that hampers the video experience. The common approach to solving this problem is as follows. Video is encoded in multiple bit-rates. For example, from lower resolution standard definition, or SD, through various rates up to 102 for HD, or higher. The video player at the client estimates the network connection's available bandwidth. It then picks a video rate that's slightly less than the available bandwidth. So, the rate of incoming data over the network exceeds the rate of the data playing out from the buffer onto the client's screen. That's simple enough. Right? Let's look closer at how this is supposed to play out. You're looking at the video buffer at the client device here. We'll see how the video bit rate is supposed to vary with the network's capacity. One can think of buffer as a set of one second chunks. The one second chucks at high bit rates, like HD. Are obviously a larger number of bytes and use more room in the buffer and are just shown as taller here. The chunk at the head of the buffer is playing out to the screen and a new chunk is downloading into the buffer. The plot above the buffer is shown as a trap of the network's bandwidth. Bandwidth is measured over a download of chunks. If a chunk is two megabits and it took one second to download. The bandwidth is measured as two megabits per second. This measured bandwidth may be used as an estimate of the future network capacity. If the estimated capacity is less than the video bit rate. We need to request the next chunk at lower quality, our bit rate. An easy way to think about this is if you're taking more than one second to download the chunk that plays for one second. Then you need to view the video at lower quality if you want to prevent rebuffering. And of course, if the capacity is higher than the video rate. You may be able to jump to a higher quality video junk. This technique is called adaptive betrayed streaming. One cool thing to is that all the logic for the bit reader adaptation resides on the client side. So the CD and server side can actually be quite simple. This works reasonably well and at least until recently some variant of this was Netflix's default approach. But there is room for improvement. The problem is that capacity estimation is hard to get right. If your estimate is too conservative, you're unnecessarily viewing the stream at lower quality, which is undesirable. If your estimate is too aggressive, you request higher quality chunks. And the buffer drains out because of the time it takes to get those chunks and this causes the video to pause. This pause is called a rebuffer. We refer to this term rebuffer, or rebuffering often in the following discussion. The difficulty of estimating network capacity is reflected in this plot. It shows for one Netflix video player's trace, the average throughput over chunk downloads, that's on the y-axis, over time on the x-axis. Notice how the average throughput varies in a wide range. 10% of sessions in a random sample of 300,000 Netflix sessions Show high variability in network capacity. This variability means that the capacity estimation is often off the mark. 20 to 30% of all rebuffers seen in this data set were found to be avoidable. That is, switching to a lower quality video stream would have avoided the need to pause. Of course, if the network's capacity is lower than the lowest video bitrate. Then there's no avoiding rebuffering. You will see frequent rebuffering in that case. This paper from Stanford and Netflix researchers also proposes a method of improving upon the capacity estimation-based approach. The key idea of this work is this. It's the buffer's occupancy that we care most about. Can we make decisions based on the buffer occupancy alone? The answer is, for the most part. If the buffer is nearly full, we can use a larger bit rate, that is, a higher video quality. If the buffer is nearly empty. We need to be using a lower bit rate. That is, lower video quality, if you want to avoid rebuffering. This intuition can be captured formally as a function that map buffer occupancy to the next video chunk's bit rate. If the buffer occupancy is high, we can use the highest video quality. If it's low, we must request lowest video quality for the next chunk. This ensures that as long as the network's capacity exceeds the lowest video bit rate. The video stream will not suffer from a rebuffer. Between these extremes, the junk rate is a non decreasing function of buffer occupancy. It's not necessarily linear, though. That's just the example here. We will omit details of the function explored in this paper. But nevertheless, one problem remains. What about the startup phase? When the stream has just started, the buffer occupancy gives us very little information. How do we make decisions then? A simple form of capacity estimation is indeed useful in this startup phase. Note that reality is a bit more complex than what we discussed here. For example, video encoding rates Aren't continuous but rather discreet. So you might have just a few options between the lowest bit rate and the highest HD bit rate. So you need to figure out how discretize the rate function. The paper does address these issues in case you're interested. How well does this approach work? The paper includes real world results from a massive experiment. The data was gathered over 500,000 users of Netflix browser based player, over a weekend in September 2013. Each group in their ab tests played roughly 120,000 hours of video. Let's look at the two primary quantities of interest, the number of free buffers and the video quality. The x-axis of this plot is time in GMT. The yellow bands represent peak Netflix hours in the US. The y-axis is the number of free buffers normalized to the number of free buffers in the control algorithm. So the control algorithm is what this work is comparing against. And that's Netflix capacity estimation based approach, in deployment at the time of these experiments. The lower bound curve shows the best possible result for rebuffers. That is if the video were played at the lowest quality throughout. What would the number of rebuffers be? From the lower bound result we can gather that there's roughly 20 to 30% room for improvement in the best case. The buffer adaptation algorithm marked BBA achieves performance quite similar to the lower bound, especially in the peak hours. It achieves 10 to 20% fewer rebuffers than the control algorithm. Further, the buffer-based algorithm, unlike the lower bound in this scenario, does not compromise on video quality. This is what the other result we'll discuss shows. Here the y axis is the video rate difference between the default control algorithm and BBA. BBA achieves higher video rate throughout. Lastly, it's useful to remind ourselves that this algorithm is deployed in the browser-based layer on top of standard protocols. In such applications where there is enough value. There's a strong argument for the application to take on some of the tasks that the general purpose network isn't necessarily adept at. [MUSIC]
