Netflix takes up 9.5% of upstream traffic on the North American Internet
arstechnica.com
arstechnica.com
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 how online entities are seen as bad due to taking too much interest from customers where TV numbers don't include bandwidth usage over broadband or spectrum usage and having x number of viewers is seen as good.
This just means Netflix is a popular and big channel or land of content that people spend lots of time in as paying broadband customers using their bandwidth and content customers paying Netflix for access to content. So this can't really be used to justify broadband companies lobbying.
There does need to be improvements to broadcasting on the web which was explored with multicast and maybe SCTP will be more interesting soon as that could help with the TCP problems.
Consider that "Netflix" can refer not only to the company (the interpretation you're using), but also to the service itself.
I dread the time when they become cable-ified and start adding different tiers (but it would make good economic sense).
I've been told Cable TV didn't have ads at the beginning.
Netflix themselves have said many times that this is antithetical to their business model - they want to have a single price for streaming.
They may end up being forced to do this by the cable companies, but this is certainly not their goal if they have their way.
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 percent.
So the average "Internet subscribing household in North America" downloads 48.9GB * 34.89% = 17.1 GB from Netflix, and uploads 8.5GB * 9.48% = 0.8 GB. If the upstream is all 40 byte ACKs, that's one ACK per 850 bytes downloaded, which is a bit more ACKing than I expected, but not completely unreasonable.
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.
Will you please start including the standard deviation ?
Would contain a lot more information than just having mean and median.
The #1 source of upstream traffic - Bittorrent - has significantly decreased their peak-hour upstream (shifting it to other hours) as described in the article. This rather obviously means that you can go from 7.7% to 9.5% share without any significant changes to Netflix as such, simply because the total peak-hour upstream rate is now slightly lower.
Asymmetric bandwidth isn't particularly high on the list of priorities when it comes to the terrible state of the ISP industry in America. It's just "one more thing".
A single missing packet will seriously mess up your video stream. Remember that long sequences of movie pictures are sent as a single whole image plus delta instructions to generate the rest of the images. A single bad packet can screw up a second of video.
But I think the bigger reason Netflix uses TCP is because TCP has a much easier time with NAT traversal and not needing port forwarding. By looking and acting like normal web traffic it makes it easier to guarantee that things will just work rather than need any special accommodation.
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.
A video chat will always prefer UDP transmission for the lowest latency possible, but quality may vary and bandwidth usage can technically be higher.
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.
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.
That has nothing to do with the underlying transport.
"Typically, a UDP-based video stream will have..." "UDP-based streams also often have something..." "in UDP cases, it's often not worth bothering about... "
Here you're describing a bunch of possible properties a hypothetical protocol written on top of unreliable datagrams would/should have.
"I should say that this isn't about TCP vs UDP so much as..."
This part is correct. You should keep this part.
"..it is about buffered vs realtime streaming."
Right. Let's not conflate transport protocols with media streaming methodologies please.
You could devise a format that tolerates loss better, but the quality and/or compression ratio wouldn't be as good.
From the article: "But for some reason, its share of uploads went up substantially in the latest measurement while downloads remained level."
[1] - http://arstechnica.com/information-technology/2014/07/how-co... Tier 1 networks have generally exchanged traffic with each other without payment if they send and receive roughly equal amounts of data. Schaeffer has claimed it's impossible for Comcast to be "in balance" with any other network because its own Internet service is designed for consumers to download far more than they upload
No, because that would not help them.
A lot of ISPs are demanding payment because they claim they're absorbing more traffic than they're sending back.
This is just a misdirection tactic from ISPs who have no intention of offering free peering to Netflix under any circumstances. Backbone peering agreements are irrelevant since neither Netflix nor broadband ISPs are backbones.
Edit: or these metrics don't mean what I think they mean, in which case, please tell me!
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 members per household.
There are no acks to be sent, a consumer endpoint just tunes to a channel and reads transport stream [1] video off the wire.
http://www1.icsi.berkeley.edu/~nweaver/papers/2009-tprc-cach...
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.
On top of that there are peering agreements which might also mention against that.
What's happening here is that ISPs such as Comcast already purposefully hurt their own consumers by providing sub-par service. No one else would normally care about it but to Netflix that's large number of their own customers and they're willing to bend backwards to be able to stream to them.
The problem is that there's really no competition so either we should remove laws and allow once again for competition, provide competition for example by letting cities provide Internet as well or heavy regulation (starting with title 2/common carrier) of existing monopolies, similarly how we do this to other utilities such as electricity/water/gas etc.