Hacker News Reader

Net neutrality and QoS are different things. I have never understand why they are both mashed together.

Neutrality means non discrimination on who sends the packet and who receives is.

QoS means that the provider have obligation to deliver a packet with strict timing.

So you buy 100-mbit slow lane and 1Mbit fast. They can even give you 2 IPs for that. If you are a call center you buy 100 of the fast lane and so on.

I think this is a great solution to this discussion. Customers should be charged transparently for a given QoS, and not secretly manipulated for a good average QoS for the network.

The only problem is complexity for both users and applications. Ideally you would have a set of pipes with different parameters and assign each application the right to use some pipes -- e.g. voip gets a slow and stable while torrent gets a fast but unstable one (but the assignment is your choice). Of course, those should be regionally consistent so that companies can't extort money from users of known traffic types (e.g. I know a priori Joe uses voip a lot so I'll raise his voip-optimal cost).

Consumers may also not be very happy with an inconsistent pricing, though. Some misconfigured app could use ton of expensive bandwidth. But this has to be worked out, it's essential for the future of the net; we can't be completely at the mercy of ISPs as the gatekeepers of content.

It seems many people think any kind of QoS means we no longer have a completely dumb pipe and ergo we have now lost network neutrality.

I agree with you that the ISP should not care about who is on the other end of my connection. VoIP packets for Skype or for Vonage or for my ISP's phone service should all get the VoIP bit set and all be treated the same.

These are more complicated rules than the water company has, but the Internet is more complicated that the water company. Water usage in a household doesn't double every N years.

IMO the word "discrimination" is useful here, because certain kinds are justified while other kinds are not.

I'd draw the line as "semantic" discrimination. (This includes if ISPs are using other things, like DNS names, as heuristics.)

So while VoIP should be given priority over the text of a blog post, two blog-posts should be coequal regardless of the opinions inside them.

I think you're missing a useful distinction: It's important which criteria someone is using when they discriminate between packets.

The real problem is when companies discriminate based on the semantic substance of the data.

All "blog post" data should be co-equal, regardless of the political views in it. Similarly, all VoIP data should be equal, regardless of whether it's a religious sermon or a phone-sex line.

But prioritizing VoIP over blog-posts? That's a much different (much more acceptable) situation.

No, you pay for X speed you should get X speed. And screw everything else. If you are using it for work/play/illegal activities, let the pertinent authorities do what is legal - but do not throttle traffic based on intended use.

Nothing else really works this way. The 2.2 GHz CPU in my Nexus 5 will throttle to 1.x GHz after a couple of minutes. Linux will happily hand out way more memory than there is actually in the system. Airlines will overbook, etc. Oversubscription/overcommit is just how engineers design systems. It's unnecessarily expensive to over-design systems to accommodate theoretical maximum capacity.

Also, how much are you willing to pay for such a system? Comcast/TWC's margins are like 10%. The margins on their cable businesses alone is probably a lot narrower than that. They couldn't profitably design a network that overbuilt--nobody could.

But is is a disservice to under-design systems to not accomodate real usage capacity.

You should always have 10% more hardware available than what your peak usage is, so when that goes up you have wiggle room to move your boundaries up more.

That, or you advertise your service as 10 - 20MB/s during non-peak hours, and throttled rates from 6 - 12. Which would naturally drive consumers who want the bandwidth to distribute the load throughout the day.

Are the services under designed for real usage capacity?

"Comcast/TWC's margins are like 10%. The margins on their cable businesses alone is probably a lot narrower than that."

How is this calculated? Do they get to factor in losses from other parts of their conglomerate?

Oh, right, and what about their captive market?

>Linux will happily hand out way more memory than there is actually in the system.

You can disable this behavior:

   echo 2 > /proc/sys/vm/overcommit_memory

If my neighbor is bit-torrenting ... I still want to be able to have my VoIP call work.

This can be mostly solved in a neutral way using fair queuing and AQM.

Companies with more money will always be able to buy better access.

Sure, but let's let those companies choose rather than being extorted by ISPs.

Sure, but let's let those companies choose rather than being extorted by ISPs.

If you are saying that a Netflix should never need to negotiate faster speeds with a customer's ISP, I agree.

That.

The the necessary complement that, if it's not economical for the ISP to serve movies to the clients, it's the ISP job to cap bandwidth or increase prices for customers. Not Netflix.

Traffic priority is very game-able and subjective, though. You can easily argue VoIP versus bulk transfer, but where's the application boundary between "necessary" and "not necessary" - music streaming? SSH? Online games? Who decides this?

It might be workable if it came with a guarantee that rates below (max bandwidth/contention ratio) would always be delivered from each customer, and traffic above that would be at risk from contention.

It is extremely easy test. Are you costrained by latency or bandwidth.

If it is latency - to have VOIP you need 200ms round trip top. That is the first lecture in Communication Technology 101.

Video streaming is latency tolerant but bandwidth sensitive. You moderately don't care if a packet gets lost or spikes as long as you have long enough buffer.

So any kind of conversation needs a fast lane. Downloading and streaming don't. But they need bulk.

The problem is the only time you actually have latency issues is when there is not enough bandwidth. Almost nothing is so sensitive that it can't stand for packets to be buffered for 25ms. The problematic latency is when you're sufficiently bandwidth constrained that packets are dropped and have to be retransmitted, in which case you can't drop streaming packets either or else over a matter of seconds the client's buffer will shrink into nothing and the video will start stuttering.

My PC has 32 gigabytes of RAM. That is a lot of buffer. Make the buffer minutes or half and hour. Right now it is more convenient for me to torrent at 100Mbit 1080p and just watch than stream.

That doesn't do any good for streaming when there isn't enough bandwidth. If the video bitrate is twice as much as the available bandwidth then it would take 30 minutes to fill the buffer in order to watch an hour of uninterrupted video. I want to turn on my TV and watch Netflix, not turn on my TV, come back in 30 minutes, watch one episode of House of Cards, come back in 30 minutes, etc.

It's not an easy test when looking at the packet. If you're relying on people to label their packets appropriately, they will lie if doing so gets them what they want.

The test is that I'll pay more for my VoIP packets to get through right now than I will for my Netflix packets.

My 2am download of Windows Update goes into the bargain basement slow lane. Let anyone else go first, I don't care.

There isn't anyone to go first at 2AM. Nobody's packets are dropped at that time of day.

The problem with QoS is that the window where it's actually useful is miniscule. If, on the one hand, it's 2AM and nobody is using the network, QoS does nothing because all the packets are delivered and none are dropped. On the other hand, if everybody is trying to watch the Superbowl at the same time and $STREAM_BPS * $NUM_USERS > $TOTAL_BANDWIDTH, QoS can't save you. You have more time-sensitive traffic than you have pipe to put it in, so at least some of your customers are going to see choppy video (or no video).

In the middle of that you have this tiny slice where the network is saturated "just right" for QoS to actually do something. You have only just enough bandwidth to handle all of the active streams, so that when some bursty thing (like loading a large web page) comes along, you can drop some packets from a stream and have just enough bandwidth available two seconds later to let the stream catch up before the client's buffer is exhausted.

To skip to the punch line, that never happens. Networks that hit 100% utilization on a regular basis are under-provisioned. If you're at the point where QoS helps you do something, your network is broken, because tomorrow's peak usage could be higher than today's which means you needed to start upgrading yesterday. QoS on the Internet is useless.

And that's before you get to the whole trouble with what to do about ssh tunnels and TLS connections and otherwise unclassifiable traffic.

I've helped plenty of clients where QoS changed their VoIP phones from "not working" to "working."

You can push my Windows Update example to 6pm -- I still don't care at all how it runs. I'd tell my router to mark it as the least time-sensitive of any of my network connections.

> I've helped plenty of clients where QoS changed their VoIP phones from "not working" to "working."

Because QoS on a LAN is a different animal. A LAN will have multiple machines that each have a 100Mbps or faster connection to a shared router with a 100Mbps or slower link to the rest of the Internet. That means one person downloading anything will saturate the entire Internet connection. ISPs have the opposite topology: A bunch of users with e.g. 50Mbps connections that come together to share a multi-Gbps uplink. Regularly saturating the uplink in that context is Bad. It means customers aren't getting the speeds you sold them.

There is also a difference between QoS and fairness. If you're using VOIP and I'm downloading something, the ISP should be dropping my packets before yours when we're on the same plan, but because of the quantity of traffic rather than the type. That pretty much exempts VoIP from being dropped, without doing any kind of DPI or traffic classification, based simply on how relatively little bandwidth it requires.

Yeah! Why should I have to deal with slower internet because you are using Netflix! You should have to pay more to your ISP if you want to use some bandwidth hogging service like that.

Weakness in your argument 1:

"bit-torrenting The Avengers" is a Strawman - illegal things are illegal and should dealt with regardless of net neutrality. Everyone does a load of stuff on the Internet, who's to decide what should have priority? Games? Email? Business? Youtube?

Weakness in your argument 2:

Slippery Slope. Let's see if "not making it easier to buy better access" is a good thing, regardless if it affects Netflix and their hypothetical attempt of "using a private network parallel to the Internet".

ISPs should not care where the packets are coming from, end of story. Agree?

You're missing the point of his argument 1. It isn't that pirating is illegal, it's that torrenting by nature has less strict bandwidth and latency requirements than VoIP calling.

Good point.

Then make it "downloads and seeds the entire open source catalog out there" - it's still that the friendly neighbor won't care about a few kbps less while those can make or break a VoIP line.

The bittorrent vs voip argument has nothing to do with legality- it applies equally well if the torrent is of a Linux install iso. On purely technical grounds, some data is simply higher priority than others.

What this means is that good net neutrality rules are more nuanced than you "ISPs should not care where the packets are coming from, end of story." QoS needs to be factored in.