No, it does not mean that. I explained why here: https://news.ycombinator.com/item?id=15910389
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.
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.
I'm not sure what you're trying to say here. Are you suggesting it is incorrect that many ISPs block port 25?
> 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.)
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.
> 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?!
...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.
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.
Yes, you can make a case that it is.
But the OP was accurate: NN is mostly about pay-to-play prioritization of content.
The definition above was far stronger than this assertion, hence my comment.
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"?
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.
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.
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" 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.
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.
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.
But yeah, I agree that this is not what we want.