A third option: Standard net, but everything end-to-end encrypted including what protocol is being used. If this information can't be discerned (easily), then priority cannot be given or taken away for any given data, only for certain data sources/destinations. If two computers (could be mobile devices, PC, server, doesn't matter) have an encrypted channel connecting them then anything could be transmitted across that channel without anyone but the endpoints knowing what it is.
Now, all this traffic could be slowed. But if it becomes near ubiquitous, then only source/destination would be useful for determining throttling/accelerating data.
Net neutrality advocates are worried precisely about isps being able to discriminate by source or destination. Additionally, most traffic is already e2e encrypted. You just used the system you were proposing to post that comment.
I agree. But source/destination isn't the only way that ISPs discriminate. They can also discriminate based on the type/protocol of content (when revealed). See the way they used traffic shaping with bittorrent, what was that 8 years ago now? That was communication between peers, potentially within the same ISP.
e2e encryption mitigates the impact ISPs can have when looking at the protocol/contents. But there is still work to be done to prevent them (without regulation) from having an impact based on source/destination without going the TOR (or similar) route.
Begging your pardon, but net neutrality isn't and has never been about traffic discrimination by type. That kind of traffic shaping is not only acceptable, it's desirable. Services with real-time requirements (VOIP, streaming, etc) can and should have priority over non-real-time services. I'm sick of people polluting the net neutrality debate with this misunderstanding and discussion on a site as knowledgeable as HN should be better. Net neutrality only covers discrimination based on source/destination and we need to push back against upset torrenters muddying the waters.
If the destination is encrypted, how does the ISP know where to send the packets? You could use some form of garlic/onion routing (Tor/i2p/etc) but that's really slow generally, and there's a decent chance the ISP at the end of the chain will be in the US anyway (and can still throttle).
Now, all this traffic could be slowed. But if it becomes near ubiquitous, then only source/destination would be useful for determining throttling/accelerating data.