Live data from Hacker News

Netflix takes up 9.5% of upstream traffic on the North American Internet

arstechnica.com

41–50 of 58 posts

Re: Netflix takes up 9.5% of upstream traffic on the North American Internet

#41
post #26
post #6

From the article: the newest report has Netflix at 9.48 percent of upstream and 34.89 percent of downstream [...] The average Internet subscribing household in North America uploaded 7.6GB of data per month in Sandvine's report in the first half of this year, increasing to 8.5GB in the latest report, a boost of 11.8 percent. The average household's monthly downloads increased from 43.8GB to 48.9GB, a boost of 11.6 pe…

I'm sure you are aware of this, but the average here seems missleading. The median household has never Torrented anything, therefore I think that the median would be more representative of the average user's habits.

Maybe people should listen to statistician's main lament about number in the press :

Will you please start including the standard deviation ?

Would contain a lot more information than just having mean and median.

Re: Netflix takes up 9.5% of upstream traffic on the North American Internet

#42
post #9

Why does Netflix use TCP for streaming instead of UDP? A few missing packets isn't going to meaningfully impact a video stream.

UDP does not give any significant benefits to TCP when latency is not as important (e.g. playing previously recorded movies as opposed live streaming).

In fact UDP makes things much harder, for example unlike TCP with UDP you need to worry about the rate at which you're sending the data. Too slow and you're not utilizing the full bandwidth, too fast and packets are getting dropped because the client can't receive it fast enough.

If you don't have a real good reason for UDP you should stick with TCP otherwise be prepared to re-implement your own congestion/rate control, and unless you're familiar with the subject it might be a challenge.

IMO an good example of unnecessarily using UDP is Etsy's statsd. Their argument is that it's ok when data is lost so no need for TCP. Unfortunately with their approach when there's enough of traffic on the LAN to cause router to drop packets, there's not much traffic left for other data as well. If they instead would use TCP with (optionally) low send/receive buffer and use O_NONBLOCK socket. When sending data if send() returns EAGAIN, simply ignore it. This approach still causes data being dropped when there's too much of it, but at the same time it minimizes amount of data in the network and plays nice with other services sharing the same routers.

Re: Netflix takes up 9.5% of upstream traffic on the North American Internet

#44
post #22
post #5

Earlier quoted context omitted.

It just seems weird that YouTube is further down that list, yet YouTube is a video hosting service.

Youtube has far shorter videos (5-15 minutes on average), defaults to 480p or less most of the time and the visitor session length is much less than the average Netflix stream. Netflix is doing 720p / 1080p defaults on most players, 1 hour to who-knows-how-long non-stop sessions (I personally have binge-watched like half a season of TV shows in one sitting occasionally) and gets daily recurring traffic from multiple…

Right, what I meant though was YouTube let's anyone upload videos. That ingestion must account for a lot more than Netflix's TCP ACKs considering 100 hours of video are uploaded every minute to YouTube [1].

[1] https://www.youtube.com/yt/press/statistics.html

Re: Netflix takes up 9.5% of upstream traffic on the North American Internet

#45

Can't Netflix acquire Level 3 and solve their issues with ISPs?

LOL Level 3 is not the problem here. In fact they are on the side of Netflix.

The regional ISPs are making big fuss, because until now they were sending about the same amount of traffic to Level3 as they were receiving, which allowed them to not charge each other for the traffic. As now there's more traffic coming from Level3 than goes the other way. As per their agreements would make them pay to Level 3 for the difference.

Because of that they prefer to simply throttle incoming traffic from L3, despite the fact that it is the traffic requested by their own users, they also refuse to peer directly with Netflix because Netflix also competes with their services as a cable companies.

Re: Netflix takes up 9.5% of upstream traffic on the North American Internet

#47

Netflix doesn't take it up, paying broadband customers are all requesting individual content that happens to be at Netflix due to the customer benefits. Netflix just has some files on a server and streams content. Netflix isn't broadcasting but customers are pulling that content. The consumers/customers of Netflix take up 9.5% upstream, granted improvements can probably be made in their software. There is a disparity…

> Netflix doesn't take it up, paying broadband customers are all requesting individual content that happens to be at Netflix due to the customer benefits.

Consider that "Netflix" can refer not only to the company (the interpretation you're using), but also to the service itself.

Re: Netflix takes up 9.5% of upstream traffic on the North American Internet

#48

Earlier quoted context omitted.

TCP is more efficient than UDP if you don't need low-latency delivery, because you can compress more data at once and waiting for retransmitted packets isn't a problem. This also ensures you get a high quality stream through the viewing experience unless there are major congestion problems. A video chat will always prefer UDP transmission for the lowest latency possible, but quality may vary and bandwidth usage can t…

"TCP is more efficient than UDP if you don't need low-latency delivery, because you can compress more data at once and waiting for retransmitted packets isn't a problem." Would you care to elaborate what you mean by any of those things? I happen to have some background in protocols but I honestly can't make sense of any part of that sentence.

If you know that the receiver is going to receive all of the data that you send (or at least a lot of it at once, for example if you have a 5-second buffer), then you can more efficiently compress all of the media being sent.

Typically, a UDP-based video stream will have less dependency among the packets, so that even if a packet is dropped, the next packet is still decodable. This means that there is more redundant information per-packet as a durability measure.

UDP-based streams also often have something called forward error correction (FEC). This is where you encode lower quality versions of media samples in subsequent packets. Again this is trading more bandwidth for realtime durability. If you miss a packet, then the next packet probably has the same media sample in a lower quality, and your 100ms jitter buffer gives you just enough time to make use of it. This is far more time-efficient than requiring the receiver to ask the sender to retransmit a missed packet.

To the point about retransmission: in UDP cases, it's often not worth bothering about. By the time you round-trip the request, you've probably already received more recent media.

I should say that this isn't about TCP vs UDP so much as it is about buffered vs realtime streaming.

Re: Netflix takes up 9.5% of upstream traffic on the North American Internet

#49
post #6

From the article: the newest report has Netflix at 9.48 percent of upstream and 34.89 percent of downstream [...] The average Internet subscribing household in North America uploaded 7.6GB of data per month in Sandvine's report in the first half of this year, increasing to 8.5GB in the latest report, a boost of 11.8 percent. The average household's monthly downloads increased from 43.8GB to 48.9GB, a boost of 11.6 pe…

This seems high and would seem to amount to an ACK for almost every second downstream packet. Since I pcap ALL THE THINGS, I looked at some Netflix streaming sessions from a 3 different clients over a week.

Stream 1: 43MB down, 21KB up

Stream 2: 56MB down, 28KB up

Stream 3: 126MB down, 62KB up

That's using Wireshark to count the bytes in the TCP conversation.

Re: Netflix takes up 9.5% of upstream traffic on the North American Internet

#50
post #3
post #2

So if Netflix makes up 9.48% of upstream and 32.39% of downstream, that means for each 10 packets sent, 3 ACK packets are sent back (I know those figures don't represent raw traffic). Does that seem a little odd? I'm not asking as a basis for some conspiracy, I'm more so wondering what that implies for data services I'm working on.

no, it just means that you don't have to upload a whole lot of stuff to become 10% of upstream traffic.

That doesn't make sense; There isn't one pool of "upload" data and another of "download" data. Rather, there is one pool of data streaming from edges into the core (upload) and back out again (download). You can either attribute each chunk of data to its uploader or to its downloader, but in either case, the pool is the same size.

Edit: or these metrics don't mean what I think they mean, in which case, please tell me!

Post reply on HN