For a basic explanation the electricity analogy posted above is fair and accurate. I don't think consumer ISPs blocking port 25 is related to the discussion on net neutrality. It's blocked because spam/viruses would be much worse if it wasn't.

> I don't think consumer ISPs blocking port 25 really weakens the analogy.

I think it does? Port 25 is only blocked if you don't pay for the premium service of having it opened. It's very much similar a case of the ISP deciding that it would rather you have a client (toaster) than a mail server (refrigerator) and charging you accordingly.

It's an analogy. It gets the point across. Yes, as you've pointed out, there are exceptions, but then you'll be ignoring the spirit of the argument. The point is that it shouldn't matter what services are used, everything should be priced the same, companies should not be able to bribe an ISP to prioritize their traffic instead of their competitors.

My ISP (sonic.net) doesn't block anything, specifically including port 25, and I'm not paying them a premium to do so.

I am paying the (very high per-mbit) premium of using them instead of, e.g., Comcast, but that's, at best, tangential to port 25.

EDIT: phrasing.

> My ISP (sonic.net) doesn't block anything, specifically including port 25

I'm not sure what you're trying to say here. Are you suggesting it is incorrect that many ISPs block port 25?

I think he/she was just making the point that not all consumer ISPs block port 25.

Yes. My comment was an existence proof against 'dataflow's assertion that "Port 25 is only blocked if you don't pay for the premium service of having it opened."

>>> My ISP (sonic.net) doesn't block anything, specifically including port 25, and I'm not paying them a premium to do so.

> My comment was an existence proof against 'dataflow's assertion that "Port 25 is only blocked if you don't pay for the premium service of having it opened."

You got my statement entirely backwards. I said port 25 is blocked only if you don't pay for it to be opened. This is logically equivalent to "if port 25 is blocked, then you can pay for it to be opened". In other words, your payment is a sufficient condition for it to be opened, but it's not necessary because not every ISP will have blocked it in the first place. (You missed the word "only" in my sentence.)

It's been many years since I studied logic (but, as a philosophy undergrad, it was required), so I may be wrong here, but ISTM that your construction is an "iff" — "if and only if". But whatever. If I mistook your meaning, my apologies.

Regardless, I think port blocking is orthogonal to Net Neutrality, and that it's disingenuous to suggest otherwise. That is, specifically: it's about prioritization not blocking.

Yeah, no, I didn't mean an "iff" when I wrote "if". As a general rule of thumb, it's safe to assume everybody understands that there are exceptions to every rule (yes, including the very rule that there are exceptions to every rule). Furthermore, it's unhelpful to contest minor points like this when they're not germane to the argument being presented. Nothing in the point I was trying to get across would have changed even if I had neglected the exceptions out there.

> Regardless, I think port blocking is orthogonal to Net Neutrality, and that it's disingenuous to suggest otherwise. That is, specifically: it's about prioritization not blocking.

I'm sorry, so are you saying that as a consumer you would consider it net-neutral if they blocked everything except Facebook unless you paid an additional fee, as opposed to merely de-prioritizing that traffic? You're fine with blocking but not with prioritization?!

> You're fine with blocking but not with prioritization?!

...and you think I was mischaracterizing your comment?

No-one I've ever seen on the Anti-NN side is talking about blocking either content or traffic. That would be antithetical to the narrative that doing away with it is a "freedom" issue, and which has somehow been spun into the crazy notion that NN entails censorship. They're talking about prioritizing — or, rather, de-prioritizing — content whose provider doesn't pay for a fast-lane.

Bringing blocking into the discussion distracts from the actual issue. To then double down on that and make the utterly unsubstantiated leap to inferring that I might somehow be okay with blocking content but not prioritizing it — when I specifically said "I think port blocking is orthogonal to Net Neutrality", never mind that this entire sub-thread was about blocking ports, not content — is fatuously specious.

If that's the kind of discourse you have to offer, I'm done here.

EDIT: phrasing.

...you entirely missed my point about port blocking (perhaps my fault).

The point I've been trying (and apparently failing) to make is that this is an email port that is being blocked and sold as a premium feature. In other words, ISPs are deciding that it is OK for you to use your internet service for browsing, but not for hosting email, unless you pay extra. Just like your power company deciding it's OK to let you have a toaster, but not a fridge (even if the fridge draws less power than the toaster [yes, I realize in reality it's probably the other way around, but a fridge is more like a server...]), unless you pay extra. And this is something people are okay with, and which they vehemently deny to be a net-neutrality concern.

Okay, fine. So far, I'll swallow this.

But at the same time, people are freaking out about a whole variety of scenarios, a pretty significant and frequently-repeated one of which is the idea that their ISP might decide "you should pay $X for social networking, $Y for videos, $Z for VPN", etc. when net neutrality is repealed. They very clearly see those as net neutrality issues and are vehemently against them.

So, to recap: blocking email and making it a "premium" feature is perfectly OK and not a net-neutrality issue, but doing the exact same thing with VPNs or pretty much anything else is a net-neutrality issue.

To me, these two positions are blatantly contradictory. It means people are either overreacting about the whole thing and the fears are baseless, or otherwise have incoherent & inconsistent positions on what the entire concept of net neutrality they're advocating for even is. Which would not be surprising, considering that the question of "what is net neutrality?" was one of the top questions here, which, in light of all this, I was very glad to see.

If people object to idea of their ISP choosing what kind of traffic they can transmit, then the ship sailed away from beneath their noses long before anyone noticed it, and it's clear that the subsequent "net neutrality" rules didn't bring it back. If, on the other hand, they're okay with the idea, then they need to examine and correct the inconsistencies in their positions (perhaps through the addition of more nuance rather than emotion in their discussions) and stop spreading all the "If this rule is repealed then your ISP will charge $5 for social media, $15 for email, and $999999 for VPN!!" FUD.

Port blocking isn't something that is generally considered part of the net neutrality discussion.

Yes, you can make a case that it is.

But the OP was accurate: NN is mostly about pay-to-play prioritization of content.

if they throttle all videos equally, I think that it could be considered somewhat neutral... but if they prioritize some videos, it is a different story

What right do they have to look into my traffic and decide that it's video?

Their jobs is to pass me the bits I asked for, no more, no less.

How would you feel if Fedex opened your packages and looked inside? If Safeway added sugar to some of your purchases to "make them taste better"?

I'm pretty sure that they can look into your packages, at least if you ship/receive something that crosses the border.

But yeah, I agree that this is not what we want.

For international shipments the government can, but Fedex is not supposed to. (Of course for international shipments fedex do have access to what you say is in the package)

There some answer is because different applications require different latencies. VoIP and video conferencing, for example, have hard latency requirements that even other high bandwidth activities like viewing YouTube or Netflix do not.

As a user, I would prefer if my video calls are the highest priority, whereas I wouldn't care if my YouTube videos downloaded in batches in the background, as long as I didn't encounter buffering.

But wouldn't that use case be best solved by your router, giving priority to some kind of traffic instead of other? (most routers come with QoS, which is exactly that)

Why is it better to give all the power to the ISP? You're losing your ability to choose if what you need isn't included in a pack.

QoS needs to be configured on the ISP's network to really work. Your home router can only impact your outbound traffic, not the bottleneck on your inbound traffic 4 routers up.

As another user said, QoS on my router won't much matter when I have only one computer connected to it. Content-aware load balancing/QoS at higher stages, if done correctly/morally, leads to better service for everyone.

There's a counterargument to this that you should just be able to purchase a dedicated/guaranteed 1 gb/s, and I can buy that idea, but currently, that kind of thing is really expensive (and I expect that there's a dirty little secret that the service provider will still use "your" bandwidth if you aren't).

> Content-aware load balancing/QoS at higher stages, if done correctly/morally, leads to better service for everyone.

"Content-aware" isn't really what's required. You can get decent QoS by just putting CoDel on every buffer, so that congestion doesn't lead to unreasonable latency. Your latency-sensitive traffic will still get its share of packet drops in proportion to how much bandwidth it's using, but the end result will be that your latency-sensitive traffic won't be affected by congestion as much as the high bandwidth bulk file transfers that are causing most of the congestion.

If you want to go further to protect the latency-sensitive traffic from packet drops in the event of congestion, you can upgrade from codel to fq_codel. Then the traffic flows that are using most of the bandwidth will get the packet drops first, and your low-rate latency sensitive traffic will be unaffected until it's taking up your fair share of bandwidth.

None of that requires being explicitly content-aware. Traffic flows on port 80 get treated with the same rules as traffic flows on port 500. UDP flows get the same rules as TCP flows (except that your UDP traffic almost certainly doesn't support ECN). Flows originating from Netflix get the same treatment as flows originating from Windows Update. And it all works well for the users, while being content-blind in every way except for deciding which packets are related to each other.

Not only does it work well, but it almost always works better than any manually-crafted QoS ruleset that singles out certain ports and protocols and endpoints and applications. Those rulesets are inherently fragile and riddled with corner cases, and require expert maintenance to keep up with changing usage patterns.

Does such a scheme continue to work well for high bandwidth, low latency traffic (videoconferencing, potentially livestreaming)?

Essentially, I believe such a scheme would break down if you had, for example, 4N bandwith, 3 users using an average of N, with the ability to buffer, and one user using an average of N but fluctuating by +- .5N, and without the ability to buffer. I don't think the scheme you described would work in such a case, but an "intelligent" provider could give everyone in this situation a "perfect" experience.

Granted, I'm not sure how realistic what I just described is, but still.

> if you had, for example, 4N bandwith, 3 users using an average of N, with the ability to buffer, and one user using an average of N but fluctuating by +- .5N, and without the ability to buffer.

Are you referring to buffering in the endpoint, as for video streaming? The buffers I was referring to are the queues in the network itself. Properly managed queues can absorb bursts of traffic but will otherwise maintain a steady state of minimal buffer occupancy, so packets spend minimal time waiting in the buffer even when the line is running at full capacity. Even when a user is experiencing packet drops as a congestion signal, the packets that make it through the bottleneck will do so without undue delay.

If I understand your hypothetical correctly, user number 4 has higher latency sensitivity than users 1-3, but they're all trying to use at least their full fair share of the bandwidth. Furthermore, users 1-3 are transferring at a fairly steady rate, indicating that their traffic is being managed by a relatively intelligent endpoint that is using something like TCP BBR.

Depending on the timescale of user 4's traffic volume fluctuations, his experience may differ. Short bursts of traffic will get buffered, and so the tail end of the burst may experience a few milliseconds of delay (and also induce a few milliseconds of delay on the neighbors' traffic), but if the burst is large enough that it would monopolize the line for tens of milliseconds, packets will start getting dropped as a congestion signal, and user 4 will experience most of those drops. On a long time scale of seconds, if user 4 is still trying to use more than his fair share of bandwidth in spite of having had enough time for congestion signals to make a round trip, then user 4's packets are going to get dropped as much as necessary to keep them under control, because user 4's traffic is behaving badly.

In the real world, Netflix-style video streaming tends to be fairly well-behaved, dropping to lower resolutions in response to congestion. It is also fairly latency-tolerant because of client-side buffering. Interactive videoconferencing is more latency sensitive but has similar congestion response and is almost as loss-tolerant. Video games, DNS lookups, and early-stage connection handshakes are all relatively unresponsive to congestion signals and very latency-sensitive. But because those are almost never the traffic flows that are using the most bandwidth, they're never first in line to be dropped in the event of congestion and they usually are the first packets to be forwarded by a fq_codel style traffic manager.

Your ISP prioritizing your video call over your youtube videos on your link according to your wishes is not a violation of NN. The problem is when they prioritize your video call over your neighbour's youtube videos.

> if they throttle all videos equally, I think that it could be considered somewhat neutral... but if they prioritize some videos, it is a different story

The definition above was far stronger than this assertion, hence my comment.