Europe's 'Net Neutrality' Could Allow Throttling of Torrents and VPNs (torrentfreak.com) 161
An anonymous reader writes: TorrentFreak reports that the European Parliament is approaching a vote on new telecom regulations that aim to implement net neutrality throughout EU member states. Unfortunately, the legislation hinges on a few key amendments, and experts are warning about the consequences should those amendments fail to pass. "These amendments will ensure that specific types of traffic aren't throttled around the clock, for example. The current language would allow ISPs to throttle BitTorrent traffic permanently if that would optimize overall 'transmission quality.' This is not a far-fetched argument, since torrent traffic can be quite demanding on a network." That's not the only concern: "Besides file-sharing traffic the proposed legislation also allows Internet providers to interfere with encrypted traffic, including VPN connections. Since encrypted traffic can't be classified though deep packet inspection, ISPs may choose to de-prioritize it altogether."
de-prioritize everthing? (Score:5, Insightful)
The use of VPN and Encryption by businesses (Score:2)
Whether the governments like it or not, the use of VPN and encryption is on the rise by businesses around the world
My companies, for example, rely on VPN and encryption for all inter-office data traffic, and if EU starts to de-prioritize VPN and/or encrypted traffic many business communication will be hit
Re:The use of VPN and Encryption by businesses (Score:4, Insightful)
Whether the governments like it or not, the use of VPN and encryption is on the rise by businesses around the world
. . . it's not just businesses . . . but governments, as well, who use VPNs.
So when those Eurocrats in Belgium realize that their VPN is being throttled, they will suddenly change their minds.
Re: (Score:2)
Governments are businesses.
Re: (Score:2)
That's okay. You simply make "unthrottled encrypted traffick" a feature offered for business-class connections. Private persons don't have secrets unless they're terrorists.
100% - 95% = 5% (Score:3)
Apply priority to 95% of clients and priority doesn't mean anything anymore
Actually it does, but probably not in a good way: it means the other 5% of clients are losing out, perhaps heavily.
Avoiding this scenario -- keeping in mind that a huge proportion of all Internet traffic is generated by a relatively small number of businesses today, and all the little guys between them might only make up 5% of total traffic -- is a large part of why Net Neutrality matters.
Re:100% - 95% = 5% (Score:4, Interesting)
I get where your confusion is coming from. Your parent was talking about applying prioritizing 95% of the traffic in response to an AC that was questioning the logic of de-prioritizing encrypted traffic. Let me change the logic to something that will make a bit more sense by using the same argument from the OP of the thread to provide a bit more consistency.
If 95% of clients are getting de-prioritized based on the traffic being encrypted, that means that 5% of clients are being prioritized to allow the maximum bandwidth allotted to them and giving them full benefit of their link. The other 95% are truly neutral on the link now, because the ISP can't use Deep Packet Inspection to identify the type of traffic to prioritize. So when the majority of users are using encryption for everything it becomes a matter of hide your usage and have an experience much like most of the rest of the people on that network, or bare your ass to the world about what you're doing and experience the fast lane while doing it.
Personally, as someone who grew up in the days of dialup... I wouldn't care if images take 3 minutes to load like they used to, I'm not decrypting my traffic for anything. If there are more people that feel as I do than are there are who are willing to sacrifice their information to the world for some faster downloads, then my speed won't suffer all that much.
Re: (Score:2)
Ah, sorry, apparently I'd jumped context and missed the unusual use of "prioritised" to mean "deprioritised" in this particular subthread. Scratch my previous comment, then.
Re: (Score:2)
I grew up with dialup, at 300 bauds !!
but I wouldn't like to lose my gigabit fiber I have right now.
Not a problem (Score:3)
Re:Not a problem (Score:4, Insightful)
Not sure how thats not a problem. Its always how this starts. grab a part of it. then fuck up everything over time.
You will not know if torrent, your game, your mail, or http traffic needs to be throttled. They will decide on that and make the numbers say anything they want to get a financial advantage. That's what they do.
Re:Not a problem (Score:5, Interesting)
It depends on your definition of 'net neutrality'.
1 - Every packet is of equal weight and value, irrespective of content
2 - Every packet is of equal weight and value, irrespective of source or destination
3 - both of the above
Where bandwidth demand is greater than availability - i.e. 6pm on a Sunday on residential networks - something has to give.
I'm very comfortable with my ISP choosing not to take option 1 if it means that packets for online gamers get low latency, video streams don't buffer and web browsing remains interactive. If that means someone's Linux distribution takes another two minutes to download, then that's a reasonable use of the available resources.
Where I dig my heels in on net neutrality is option 2. If the ISP prioritises its own video streaming service ahead of others, its own gaming service ahead of others, its favourite partners' websites ahead of others, then it's prejudicing the market and acting in bad faith.
So no, do traffic shaping by all means. It's a reasonable and proportionate approach to assuring quality of service. Just do it for all packets of that type.
Re: (Score:2)
The difference between (1) and (2) is largely meaningless for net neutrality. If your ISP wants to extort money out of Netflix, say, they can just de-prioritize the type of streaming video packets that they use. They will find a way to affect just Netflix and maybe a few collateral minor services based on packet content.
The only solution that won't be open to abuse is to treat all packets equally. The only solution to bandwidth being exceeded by demand is to add more bandwidth, or to work with content provi
Re: (Score:2)
I'm tempted to say this isn't a particularly big deal in Europe - if an ISP trys to pull this kind of stunt then the content provider will announce what's happening and folks will just switch ISP. Compare to the US where this *is* a problem because the end users generally don't have a choice of ISP - if the ISP decides to hold Netflix to ransom then Netflix can't just tell their customers to switch ISP.
Re: (Score:2)
I'm very comfortable with my ISP choosing not to take option 1 if it means that packets for my Linux distribution download get low latency, my porn movies don't buffer and whatever the h
Re: (Score:2)
Sounds fair to me, but not that I'm not requiring that my traffic takes priority over your traffic.
I'm asking that quality of service is a core part of the offering, and acknowledging that not all traffic has the same needs.
If my youtube uploads make your porn movies buffer then that's a bad thing. If your linux download makes my gaming suck then that's a bad thing.
Ideally we both flood our upstream and downstreams with no impact on each other. Where the ISP identifies that they can't make that possible, ra
Re: (Score:2)
I'm not. Who am I, you, some network engineer, or some pencil pusher at determining the importance of one packet over another?
No. I was being facetious with my comment. I want my packets to be treated exactly the same as every other packet. No more. No less. If my traffic caus
Re: (Score:2)
You don't even benefit from low latency on a Linux distro download as long as the total incoming bandwidth is the same.
Re: (Score:2)
So no, do traffic shaping by all means. It's a reasonable and proportionate approach to assuring quality of service. Just do it for all packets of that type.
No. For god's sake, no, don't do traffic shaping, a small handful of important and ultra-well-known protocols (e.g. SIP) aside. Just deliver my goddamned packets, use as much of the link as you can, and serve customers round-robin. Nothing else. ISPs trying to get smart about traffic shaping actually just ruins everything. Any new kind of traffic gets shaped incorrectly.
Re: (Score:2)
So don't traffic shaping, except do?
We seem to be agreeing.
Re: (Score:3)
I say Don't do traffic shaping. Why should SIP and RSTP get special treatment. Is my skype call less important? If you allow shaping of even the 'ultra well known protocols' than you effectively choke off innovation.
So nobody can ever get a better voip protocol out the door because the network treats it like shit so for practical use it ends up being inferior. We have enough issues like proxies and NATs that can't deal with non http protocols in the case of proxies, and NATs that don't handle anything t
Re: (Score:2)
So don't traffic shaping, except do?
No. Don't shape streaming traffic. Just throw it into the bulk bin. And don't shape most of the traffic that you claim needs shaping, because it makes the problem worse and not better. Your logical fallacy is moving the goalposts.
Re: (Score:3)
My logical fallacy is arguing with idiots.
Re: (Score:2)
I'm pretty sure QoS of this kind has been around since the days of dial-up. Your approach only works when equal requirements are placed on packets by all services. This is not the case. Some services work fine when a packet doesn't make it to the destination at all. Others shit themselves when a packet arrives a little too late or in the wrong order.
Think of it the same as not having your passport sent via regular mail, but rather with tracking and a signature to receive.
Re: (Score:2)
Re: (Score:2)
So no, do traffic shaping by all means. It's a reasonable and proportionate approach to assuring quality of service. Just do it for all packets of that type.
Or they could always do something novel like not oversubscribe their service or build out their infrastructure to actually support what they are selling.
Traffic shaping at the local network level where the administrators actually know what type of traffic is important to them is fine. Shaping at the provider level is ridiculous as it will always unfairly hinder someone (why should your gaming/streaming/backups/pr0n/etc... be more important than whatever I am doing? Why should whatever I'm doing be more impo
Re: (Score:2)
I don't care how beautifully elegant, lean and efficient my voice communications protocol is, if there's a three second pause between words because some cunt's hogging the bandwidth watching cat videos then we're not talking.
Investing in infrastructure is sensible, but don't pretend you can design latency requirements out of everything. You can't.
Re: (Score:2)
If they're doing all that packet inspection anyway, they can do proper fair queueing. Each customer is assigned their fair share of the total uplink for their area and each queue is allowed to borrow as much as is available from under-used queues.
Suddenly everyone gets their fair share without regard to what they're communicating with, where it is, or over what protocol. Further, they can keep their fingers out of the payload and just look at the src and dst fields of the header.
Re: (Score:2)
Why does something have to give rather than everything having to give.
Because some applications are more sensitive to latency than others. Something happening in real time, such as gaming, a VOIP call, or streaming a video, will be more disrupted by frequent minor delays than a bulk data transfer like backing up 100G of data from office servers to an off-site location overnight.
When the roads become congested, the authorities do not restrict the number of vehicles allowed onto the road or only allow cars and prohibit trucks.
Maybe your roads work differently, but over here in the UK, we do this all the time.
Many popular areas have dedicated lanes to prioritise various forms of transport considered a high priority in conges
Re: (Score:2)
That depends entirely on the network. In some places I've lived/worked, on-line gaming was a heavy contributor to overall data volumes. In some places, video calls have become so (and obviously aren't amenable to the kind of caching you mentioned). I don't think that any particular examples are really the point anyway, though.
Re: (Score:2)
I've also seen reports that at certain times NetFlix represents a high proportion of overall Internet traffic, though I don't recall any with a figure nearly as high as the 80% you mentioned. Maybe that's been true somewhere at some time. But with the rise of things like cloud services, the volume of data flying around during the business day is surely increasing as well. Also, I suspect you underestimate the bandwidth requirements of, say, a RTS game with half a dozen players, each with hundreds or thousan
worse performance for all, ssh voip ueeles. 3 meas (Score:5, Interesting)
Routing packets in the order the arrive makes it worse for EVERBODY, and makes very low bandwidth uses like ssh and voip more or less useless.
Streaming video (Netflix) requires a certain (high) BANDWIDTH to avoid repeated buffering. Any more than what it requires does little good, but it needs to transfer X MBs per minute in order to keep up. Latency and jitter do no matter at all for Netflix. It's purely MB per minute- packets can be delayed 200ms and it doesn't matter as long as they arrive before the buffer runs out.
Voip needs very, very little bandwidth- 64Kbps is enough. That's 1% of what video uses. But voip can't have high jitter (variation in latency). It also requires reasonable latency, but jitter is the main issue.
If you have Netflix and voip traffic going through the same router, it doesn't affect the video viewer AT ALL to have a 64 byte voip packet occasionally jump to the front of the queue if it's been waiting too long. Having the voip wait for three seconds of video -would- mean the call goes silent for three seconds. That would be stupid. Really stupid.
Ssh needs virtually zero bandwidth- bytes per second, 1/1,000th as much as video needs. Ssh doesn't care about jitter. But it DOES care very much about latency. When you try type "cat /etc/resolv.conf" it's really annoying to have delays between each character. But the ssh packets are tiny - just a few bytes, so they don't effect anyone else on the network. Again, leaving them waiting in line hurts the ssh user with absolutely no benefit to anyone - it's only damaging. Doing that would again be really dumb.
Suppose a provider has incompetent admins and does ruin ssh, voip, and other low-bandwidth highly interactive traffic by making those packets wait for high-bandwidth non-interactive traffic. People who care about interactive traffic will find that provider's service more or less unusable and switch. So here's a guy (like me) who was using less than 1kbps for ssh while paying the same $45 you pay while you use Netflix. The ISPs cost to service both of us is $70 ($10 for me and $60 for you). Guess what happens when the voip and ssh users leave for a different ISP? We're not there to subsidize your cost anymore, so your bill goes from $45 to $70.
To turn back to your road analogy, you may have noticed that in many places trucks aren't allowed in the left (fast) lane and in most places the left lane is for faster traffic only. If on one tollway all the cars had to line up behind the semis, while another road allowed them to go faster, which road do you think the cars would use? Once the trucks had to pay the full cost of the road by themselves, do you think their toll rates would go down or up? Would the trucks somehow benefit from making it illegal for a car to pass a truck?
Re: (Score:2)
Your analysis has one key flaw. It is based on the assumption that there isn't enough bandwidth to keep latency low for everyone. There are natural bottlenecks in an ISP network. A subscriber's ADSL might only be capable of 10Mbps, so as long as the upstream pipe is big enough to handle their constant 10Mbps of streaming video without packet queue depths getting long enough to add more than a few milliseconds to an arriving SSH packet everything is fine.
So while there is an argument for some limited priorit
Re: (Score:2)
Your analysis has one key flaw. It is based on the assumption that there isn't enough bandwidth to keep latency low for everyone.
That's not an assumption, that's a very real fact.
ISPs design their infrastructure to keep it that way too, and for frankly very sensible reasons.
Re: (Score:2)
My max
Re: (Score:3)
Congratulations, you found a good ISP.
If you can prove to me that all ISPs are like yours, I'll concede the point. Until then we both know that my factual statement remains accurate.
Re: (Score:2)
Re: (Score:2)
Reading comprehension challenge there then. I stated that ISPs do X. As long as more than one ISP does X, you haven't refuted my statement.
Just because 1 doesn't do X is totally fucking irrelevant.
Have a great weekend.
Re: (Score:2)
Now what were you saying about a "fact"?
You didn't post any facts. Unsupported statistics aren't facts. Why didn't you name your ISP, if they are so great? Are you one of the 1/100th of 1% that can get Google fiber, or something like that?
Re: (Score:2)
How is that even relevant?
Because the cryptic nature of the claims, from an undisclosed location in the Midwest, for all we know, the ISP doesn't exist, and he's lying to prove a point. If he gives the ISP, we can look at other 3rd party evaluations for verification.
Yes, I know there are places with good ISPs. The US isn't one of them. And an ISP like Google isn't a reasonable answer, as the last numbers I saw, about 1/100,000 people had access to it, and that was an exaggeration. They need to grow by about 2 orders of magnitud
Re: (Score:2)
Again, how is that relevant? There only needs to exist one example of a real world ISP to prove that it is possible to run a network congestion free.
The claim that because someone somewhere in the world does it that it's practical in the US regulatory environment is a silly claim. If it were as easy as you claim, why can nobody name any in the US that act in that manner?
Taking the money and intentionally not delivering the advertised service is fraud!
Your Term of Service clearly lay out a "best effort" service, and that's what they deliver. That you disagree with them on the definition of Best Effort indicate you need to sue them (and lose) in court for clarification. Your poor English skills don't trump the law.
Re: (Score:2)
Re: (Score:2)
There's a large market and a lot of societal benefit to providing crap internet access at an affordable price.
People who want high quality low latency bandwidth can get it, just not cheaply.
Re: (Score:2)
Your analysis has one key flaw. It is based on the assumption that there isn't enough bandwidth to keep latency low for everyone.
So his analysis is flawed because it's based in reality? That's quite a condemning indictment. You are wrong because, um, you are right, but that's not the way I'd like to see it.
If that's the case. No ISP runs a network like you'd like. The obvious solution is for you to build or buy an ISP and run it the way you'd like. The flood of new customers to you would make you a billionaire. Unless you are wrong, and that's why nobdody does it. The 1/10 of 1% that would care don't make enough people to justi
Re: (Score:2)
Re: (Score:2)
And they aren't "trying to screw with customers" they are trying to make the service the best possible for the most number of people. And one of the easy ways to do that is to put in a DPI and set it to put bittorrent as the lowest priority. The people downloading all day long never complain. 99% of the time, they are doing somethi
Re: (Score:2)
I've read article after article over the years where they said incumbent ISPs are incredibly wasteful and bandwidth and infrastructure is relatively
Re: (Score:2)
When talking to an ISP network admin, he told me they tried doing QoS and traffic shaping, but issues always cropped up and customer would complain because of poor performance.
Ah, so you heard from a guy that it's this way. What do you *know*? I've worked on the QoS for about 10 ISPs of various sizes (some as a network engineer, some as the network manager, some as the equimpent manufacturer's support), and you'd have to
Re: (Score:2)
Re: (Score:2)
It is also wide open to abuse, because SSH is used for SFTP and a variety of other bandwidth-hogging protocols, and because it is difficult to tell one type of encrypted packet from another.
Which is why the higher priority should only be given to the first x KB of packets each second. Same would benefit VoIP. But yes, it's nearly impossible to distinguish from even HTTPS traffic, since it's encrypted.
Re: (Score:2)
I buy quality bandwidth, it's $20/Mbps, plus deliv (Score:2)
I buy dedicated, guaranteed bandwidth from more than one provider. The cost is around $20/Mbps, at the provider's POP. A line from my office to the POP is quite a bit more expensive.
Since at home I'm only using bandwidth 5% of the time, it would be silly to pay for it 100% of the time. It makes much more sense to share the cost with my neighbors , who also need it only occasionally. Remember on the web you're only using bandwidth while the page is loading, so if my neighbor spends an hour a day surfing
Re: (Score:2)
I would say that ISP's should allocate enough bandwidth for the service they provide. But, of course, if they can avoid doing this (and many times, thanks to monopolies, they can) and save money, they will.
It's rather like medical insurance: companies have no more incentive to provide better service than to save money through simply risk selection by cutting out customers more likely to get sick.
Hence the need for legislation.
Re: (Score:3)
Routing packets in the order the arrive makes it worse for EVERBODY, and makes very low bandwidth uses like ssh and voip more or less useless.
You shouldn't prioritize SSH traffic up, because if you do that, then people's SSH tunnels get prioritized up. You should just have a network without shit latency, which is not massively oversubscribed. You can always prioritize down the stuff you know is streaming. The stuff that goes up is DNS, SIP, and maybe NTP would be nice and the traffic is minimal. And the beginnings of HTTP connections, but only the first however-many-kBs-make-sense.
To turn back to your road analogy, you may have noticed that in many places trucks aren't allowed in the left (fast) lane and in most places the left lane is for faster traffic only. If on one tollway all the cars had to line up behind the semis, while another road allowed them to go faster, which road do you think the cars would use?
No, you cannot use a road analogy like that, because networking do
Re: (Score:2)
If you prioritize the first X KB / sec. worth of packets, you can give a de facto priority to low-bandwidth uses, without giving extra favor to things like tunnels. I don't know if that's being done by anyone. Each additional packet in a given time frame would get a lower and lower weighted priority based on how long it's been since the previous X packets. Might be too CPU intensive for a huge amount of traffic, but probably not worse than deep packet inspection.
Re: (Score:2)
Right on! Road traffic neutrality! Fuck ambulances and fire engines! They can wait in the gridlock like everyone else!
Yeah because if that game lags out someone is going to die!
Re: (Score:2)
The problem with the language they used is that any protocol they can't explicitly classify can be assumed to be encrypted. You run the risk of an unencrypted Youtube video getting prioritized over games, or whatever else is using custom protocols.
They should not be the ones to hold these reins. And I think that's the whole hold-up -- their focus is obviously that they want control, not so much that they want to limit bandwidth. Really, pretty much everyone involved who they consider a bandwidth hog would b
Re: (Score:3)
That's fine. The competition between ISPs is enough to have some cater to the edge cases.
Not where I live. We have a choice between 2 ISPs, and I'm pretty damn sure they make illegal price fixing arrangements. Both offer the same packages, pester you with advertisement calls for mobile services and streaming TV bullshit, and have the same incompetent and impotent tech service with a 1/2 to 1 hour call queue.
Re: (Score:2)
It's a huge problem because many people don't have a choice of ISP. I can only get Virgin, for example, because my BT line doesn't support ADSL.
Re: (Score:2)
I'm 2.2km from the exchange. I tried ADSL2 and got about 5Mbps intermittently. They couldn't fix it and BT were not interested because voice works on the line. I could try FTTC I guess but I'm only willing to do it if I can cancel the contract and installation fee when it fails to work. The Infinity web site says I will only get about 15Mbps anyway, which is probably optimistic.
Re: (Score:2)
Hows is this a net neutrality bill? (Score:4, Insightful)
If they are allowed to set priorities for different traffic, how is this a net neutrality bill?
Re: (Score:2)
Re:Hows is this a net neutrality bill? (Score:5, Informative)
I though net neutrality is frequently confused with QoS.
Throttling all VPNs is net neutrality. Throttling all VPNs except those provided by the ISP isn't. Net neutrality is about being neutral as to the source/destination/provider, not the protocol. It's to stop the ISPs abusing their service provider positions to make their versions of services better than everyone else's by artificially damaging other people's.
Don't get me wrong, it's still crappy, but I always thought the point of network neutrality was to level the playing field for service providers, not protocols.
Re: (Score:3)
While you have a sane view of network neutrality, not everyone subscribes to it. The reality is that different protocols have different foot prints and are not all equal. It makes little sense to pretend that they are -- and when you do handle traffic as if each and every packet was equal and equivalent then you get problems.
One example is bit torrent. It is one of the most abusive network protocols in use. It is resource intensive (e.g., routing overhead for 1:1 connections like http are far less than that
Re: (Score:2)
Like I said on another post, the problem is that if an ISP wants to prioritize their own service over others, there's nothing stopping them from trivially modifying an existing protocol, calling it a new protocol, and prioritizing that over other protocols of the same nature.
The solution to bandwidth hogs like p2p is per-user bandwidth control. If user A is using tiny amounts of bandwidth but user B is using a ton, then you prioritize user A's packets. If someone wants to suck down tons of bandwidth, then
Re: (Score:2)
Re: (Score:2)
While I am a strong proponent of network neutrality as you describe it, there is a case to be made for handling packets different based on who is involved (even if the technical details are tricky).
No, handling packets differently based on who is involved is pretty much the opposite of neutrality.
Neutrality should mean that the specific source, destination, and content of a packet (including things like the "protocol" and "port" fields) have no effect on prioritization. Data which can influence prioritization includes the level of service the customer purchased, whether or not the packet must be routed outside the ISP's own network, general statistics about the customer's network traffic like historic
Re: (Score:2)
Re: (Score:2)
Throttling all VPNs is net neutrality. Throttling all VPNs except those provided by the ISP isn't. Net neutrality is about being neutral as to the source/destination/provider, not the protocol. It's to stop the ISPs abusing their service provider positions to make their versions of services better than everyone else's by artificially damaging other people's.
OK, picture this. The ISP comes out with their own proprietary protocol to stream their video service, maybe just a special data format within HTTP packets - after all, a different protocol could technically be at any level of the protocol stack. Their protocol gets prioritized, while the competitors' protocol gets de-prioritized. The ISP is technically only throttling based on protocol, not source/destination.
The ISP version of Murphy's Law: If it can be abused, they will find a way.
Because it is not content or person based (Score:4, Interesting)
Re: (Score:2)
Okay, so if I run an ISP, and we offer our own video service, I'll just barely modify an existing protocol and use that for our video service. Then I'll prioritize it over all other video protocols.
See why that doesn't work?
You what? (Score:2)
How exactly is torrent traffic impactful on an ISP network? they're just routing packets around (okay, maybe you need a larger routing table?), it's the nodes that have to do most of the work. Unless they're using carrier-grade NAT, in which case get IPv6 working you lazy b*s.
Also, looking forward to seeing http encapsulated VPNs!
Re: (Score:3)
1/6 of the downstream traffic and 1/3 of the upstream traffic is impactful on an ISP network because it consumes resources that would otherwise be available for other uses, and/or requires the ISP to invest in additional infrastructure to prevent that traffic impacting other uses.
it's the nodes that have to do most of the work
You appear to come from a world that has infinite speed zero latency networks. Welcome to Earth, where we have an internet that requires switches, routers, fibre optics and complex networking.
Re: (Score:2)
1/6 of the downstream traffic and 1/3 of the upstream traffic is impactful on an ISP network
Maybe I missed it, where are those numbers coming from?
Also, let's say it is 1/6th or even 1/3rd of the traffic, that doesn't say anything about the capacity.
because it consumes resources that would otherwise be available for other uses
Ignoring the distinction between traffic and capacity, your argument is "if the traffic wasn't being used for what the subscribers wanted to use it for, it could be used for..." what exactly?
and/or requires the ISP to invest in additional infrastructure to prevent that traffic impacting other uses.
Yes, ISPs need to invest in infrastructure to ensure the service level they sell meets the real world wants and needs of the customers they sell it to. And the pro
Re: (Score:2)
Maybe I missed it, where are those numbers coming from?
Online references located via Google search results. Those were 2013 numbers, more recent statistics may vary.
The precise numbers don't matter, and actual capacity also doesn't matter. Your question was "How exactly is torrent traffic impactful on an ISP network?" and my response is that torrent traffic is a meaningful percentage of the network use for an ISP.
Since the ISP invests resources in providing a network, it's pretty obvious that the ISP is investing resources in meeting the demands of torrent user
Re: (Score:2)
Re: (Score:2)
Curious. Where did you read that I claim we're getting a good deal?
I mean, I'm getting 160Mbps down and 12Mbps up, and within those bounds network performance and availability is excellent. I still pay too much and the upload is too low. It's not a bad deal, but I don't think I've claimed it's a good deal.
A lot of people don't even have it that good. I acknowledge this. I also acknowledge that if provision of gig links up and down were trivial and cheap, we'd have them.
Re: (Score:2)
Re: (Score:2)
Slow networks are expensive because they go out of their way to do things inefficiently. Fast networks are cheap
What the holy fuck. It's cheaper to have a fast network? Shit, all these ISPs, they've been doing it wrong all this time.
You must be a billionaire, meeting public demand for ever increasing speeds by continually reducing your costs through enhancing your network to make it faster.
Really?
Re: (Score:2)
I didn't say there was an issue. I merely answered the question of how torrent traffic is impactful on an ISP.
Re: (Score:2)
you acknowledge, then dismiss, the most glaringly obvious problem with bit torrent (from a network provider point of view).
Congratulations, but dismissing it doesn't make the problem go away. It does make it look like you have no understanding of the issues involved. Try working at an ISP sometime (or otherwise gain working, practical knowledge).
Err... (Score:4, Insightful)
Re: Err... (Score:3)
Because the ISP can't tell what is being encrypted. Naturally, if torrents are throttled and encrypted streams aren't, then all P2P data sharing will move to encrypted.
Re: (Score:2)
Torrents are used for real-time streaming video, e.g. Popcorn Time.
It's not just that torrent transfers will take a bit longer. ISPs will severely limit them, so that services that use Bittorrent will grind to a near complete halt at times when people want to use them. Lots of services, such as Amazon S3, Vodo, NRK, Blizzard's game distribution system, Wargaming's distribution system, the UK government, research data distribution and the Internet Archive will be affected.
We have seen it before, it's not jus
Re: (Score:2)
The torrent part I agree with: torrenting can be very demanding on the networks, and torrents are not used in applications that require real time.
Depends on HOW they implement this. It's a busy day let's blanket slow all P2P is a dumb way to do it when international lines are clogged but local peers are underutilised. Setting it to a fixed speed is also dumb compared to dynamically adjusting as a percentage of pipe capability. Likewise torrents should be treated equally the same as any larger download, why should my 20MB torrent be slowed but someone downloading a 40MB TIFF file not be?
This isn't as simple as many people make out. QoS is still requir
Re: (Score:2)
Does Europe need regulation? (Score:2)
Many European countries have competition in the telecoms sector. Any action perceived as unfair throttling will see their customers go elsewhere.
The problem is, regulation is a blunt instrument. If I want decent broadband speed for Netflix, I don't care if everything else is slower. However, it might be in Netflix's interests to offer ISPs a cut to allow higher broadband speeds for it
Time to encrypt ALL traffic then (Score:2)
and start deprecating ALL unencrypted protocols.
Establish a new connection dispatch service that all all other services would use. All interconnections would first establish a connection to the dispatch, which would establish a TLS or PGP type of encrypted session, and THEN transit information about which service to connect to.
Re: Time to encrypt ALL traffic then (Score:2)
Why would anyone switch to encrypted if unencrypted packets get higher priority?
Re: (Score:2)
Excellent news (Score:2)
It's about time we update bittorrent with better security/encryption and something less easily detectable.
We will all make our own net neutrality when everything is encrypted and nothing can be prioritised. Pros and cos but it's better than "net neutrality" IMO.
Encryption (Score:2)
The trend is for everything to become encrypted, anyway - so the whole thing will be moot.
Even our company's website defaults to https and we're not even a tech company. YouTube defaults to https. Google. Farcebook, Reddit. (Slashdot seems to be one of the few that don't).
If they start throttling a protocol, people will start making it look like https to work around the throttling - use port 443 and TLS 1.2.
Bunch of whiners (Score:2)
Really, a bunch of torrenting whiners whine because the proposed regulation acknowledges that ISPs have a legitimate interest in QoS, and that this might impact their download speeds.
Get in your thick heads: Net Neutrality is not about freedom to download, it is about forbidding discriminating traffic based on the endpoints.
It sucks (Score:2)
It sucks, but is still better than the present non regulation.
no good reasons (Score:2)
The unintended consequences (Score:2)
This smells of another government attack on encryption, ALL encryption. It seems governments all over are so intent on surveillance that they will break anything to get it.
And so, what could possibly go wrong with this deprioritization of encrypted traffic?
- No chance of your banking app sensing problems with traffic and either terminating or restarting sessions? I know, there are few reasons to do that, and none technically sound. Assume, for the moment, that your bank has control over how their app wor
Re: (Score:2)
God damn fucking piece of shit posted as HTML formatted. Fuck off.
Re: (Score:2)
If it actually would work, it would be relatively easy to implement on IPv6. Customer gets two IPv6 address ranges. No need for two physical lines as traffic can be QoSed such that the latency sensitive traffic gets 100% priority. And the ISP can respect that all the way up the chain.
What they can't do is handle that at the backbone level, just last mile and maybe the next hop after that.
Re: (Score:2)
2. For the TCP side, TCP ACK packets are prioritized. This keeps heavy traffic going one way from impeding traffic going the other way. You could also set a 50/50 split here with borrowing so DDoS style abuses of this policy are curbed until the DDoS can be stopped.
Delaying ACK packets is how inbound QoS is achieved.