Hacker News new | ask | show | jobs
by wmf 4420 days ago
QoS mostly decides which packets get dropped, but ISPs shouldn't be dropping any significant fraction of packets.

(I was tempted to downvote you for your persecution complex, but that would only validate it so I'm torn.)

1 comments

Packets get dropped when links are saturated as they often are during peak hours. I know a network admin would think "well the links should never be saturated" but the economics of that just don't work in the consumer ISP space. You aim for a target level of service that means certain portions of the network will be saturated, and use QoS to ensure things like DNS and HTTP remain responsive.

Regardless, the point is that QoS exists to keep non-video traffic from getting trampled out by video traffic. Video traffic is such a disproportionately large amount of total Internet traffic that virtually the only services that would be significantly impacted by being in the "slow lane" are video services. The links wouldn't even be saturated in the first place without video traffic.

EDIT: Also wanted to add that congestion is almost guaranteed with adaptive bit rate streaming. Netflix will use as much bandwidth as is available up to like 9 mbit/s.

the economics of that just don't work in the consumer ISP space

A citation is needed here. Somehow consumer ISPs got along for 15 years without "permanent congestion".

Because they didn't have 50% of their users trying to view 6 mbit/s video streams.

EDIT: Just wanted to clarify that 50% is a number I pulled out of my ass. The general point is that the percentage of users who stream video online on a regular basis is increasing more quickly than the economics/logistics allow the ISPs to perform network upgrades.

> The general point is that the percentage of users who stream video online on a regular basis is increasing more quickly than the economics/logistics allow the ISPs to perform network upgrades.

This is another citation needed point. Bandwidth consumption has always increased over time, as has the performance per dollar of routing equipment.

Well, the goal of a properly designed transport protocol is to transfer X bytes in 0 seconds. TCP doesn't quite achieve that, but that is its goal. This pretty much dictates †hat for any reasonable sized download, somewhere on the path is congested. If that congestion isn't at the server (it usually isn't), and isn't in the backbone (it usually isn't), then it's either your consumer ISP or your computer (it usually isn't). ISP's tend to oversubscribe backhaul to make the economics work, so if you're not getting your full linkspeed, then it's likely the backhaul that's congested, and everyone else is seeing congestion too.

There are exceptions of course. Older OSes have ridiculously small TCP receive windows, and older TCP congestion control algorithms have trouble filling the pipe. But these shouldn't really be the main problem these days. It doesn't apply so much for streaming either, because modern streaming protocols such as MPEG-DASH will select a lower bitrate stream if they sense congestion.