said by LordFlux :

Could someone post up what behavior to look for specifically?

said by devnuller :

Karl updated the article with a reference, but not sure "still does" counts if the data is a year ago. Is there anything more recent?

said by joako :

You can use this tool to test for yourself: »broadband.mpi-sws.org/transparen···test.php

said by a333 :

bandwidth is bandwidth, either way you look at it.

said by a333 :

I've said over an over, the ideal solution is to gracefully scale back speed for ANY upload/download if the said user is using their full bandwidth for more than 20 minutes during peak hours. This actually solves the problem, unlike throttling schemes like bell's, which render many legitimate applications useless.

said by a333 :

To amigo_boy, ... What's your point?

said by a333 :

bandwidth is bandwidth, either way you look at it.

said by a333 :

It's not as if the user is using any more bandwidth than if they were conducting a regular http download.

said by a333 :

P2P actually is better for a network, as (given enough peers) it completes downloads significantly faster than normal centralized server methods, thus getting heavy users off the network noticeably faster

said by a333 :

The throttling of particular packets by itself violates the principles of TCP.

said by a333 :

The uploading you do during YOUR transfer in turn speeds up someone else's download of the SAME file, hence letting a lot of heavy users get their files faster, reducing strain on the network in general.

said by a333 :

To distribute Blizzard patches to several million users simultaneously using the regular HTTP/unicast methods would require a port into the 'net that's the size of a national backbone.

said by a333 :

And what is all this B.S. about upstream bandwidth? Unless you set your client to use 100% of your upstream bandwidth, and make it open up ~2000 ports, you are NOT causing any harm to the network, PERIOD. It's the same as if you had been uploading that 400 MB family reunion movie to Grandma Ginny.

said by espaeth :

Broadband bandwidth is oversubscribed. Your "idle" bits are intended to be someone else's "used" bits. The difference here is again finite vs infinite duration transfers. You start a standard upload of that 400MB video to Grandma Ginny, walk away, and once your transfer finishes there is no more traffic on the network. Using a P2P application, on the other hand, will keep putting bits on the network for as long as you let the application run. Little Timmy queues up some MP3s to download in the morning before he goes to school -- even though the transfer will probably finish in the first 30-45 minutes, the P2P app will keep uploading to other P2P clients the entire time he's away at school, or even longer if he leaves the client running after he gets home.

said by espaeth :

You start a standard upload of that 400MB video to Grandma Ginny, walk away, and once your transfer finishes there is no more traffic on the network. Using a P2P application, on the other hand, will keep putting bits on the network for as long as you let the application run. Little Timmy queues up some MP3s to download in the morning before he goes to school -- even though the transfer will probably finish in the first 30-45 minutes, the P2P app will keep uploading to other P2P clients the entire time he's away at school, or even longer if he leaves the client running after he gets home.

said by NetAdmin :

I would like to point out that more BT clients are now setting defaults that eliminate this issue. Most BT clients will shutdown the transfer once the user has reached an Upload to Download ratio of greater than or equal to 1. Users have to manually change that option to seed indefinitely.

said by espaeth :

Which is great if people actually update their software. Considering the number of SQL slammer packets I still see hitting my firewall to this day, forgive me if I remain skeptical that this will make a difference anytime soon.

said by a333 :

letting a lot of heavy users get their files faster, reducing strain on the network in general.

said by a333 :

P2P software REDUCES congestion, and avoids the situations most HTTP downloads would just keep trying to hammer their way through. To distribute Blizzard patches to several million users simultaneously using the regular HTTP/unicast methods would require a port into the 'net that's the size of a national backbone.

said by a333 :

P2P software REDUCES congestion, and avoids the situations most HTTP downloads would just keep trying to hammer their way through.

said by espaeth :

It is several orders of magnitude more expensive to deliver bandwidth to residential homes than it is to provide bandwidth for servers in data centers. That's why shifting the distribution burden from data center hosted servers to end-user links is such a poor idea. The P2P architecture is one that you arrive at when you develop an application with complete ignorance to the realities of the network infrastructure it will run on.

... Considering that technical hurdles make upstream capacity the most difficult to build out at the edge, an application designed to make constant use of upstream bandwidth is exceedingly bad.

said by SuperWISP :

Content providers should not be able to shift their bandwidth costs to ISPs, multiplying them in the process.

said by NetAdmin :

Nobody is magically shifting costs anywhere because all the costs are paid for by everyone connected to the network.

said by espaeth :

If your monthly subscription fee actually covered the cost of high bandwidth usage then there would be no reason for ISPs to waste time and money on network management.

said by SuperWISP :

It's necessarily much more expensive to deliver bandwidth to the end user via the last mile than it is to deliver it at a server farm. I know this because I'm out there every day -- on roofs, in users' homes, climbing radio towers -- to make that "last mile" link.

Content providers should not be able to shift their bandwidth costs to ISPs, multiplying them in the process. See my testimony before the FCC at »www.brettglass.com/FCC/remarks.html for a detailed explanation of why.

said by SuperWISP :

It's necessarily much more expensive to deliver bandwidth to the end user via the last mile than it is to deliver it at a server farm. I know this because I'm out there every day -- on roofs, in users' homes, climbing radio towers -- to make that "last mile" link. Content providers should not be able to shift their bandwidth costs to ISPs, multiplying them in the process. See my testimony before the FCC at »www.brettglass.com/FCC/remarks.html for a detailed explanation of why.

said by a333 :

Yawn, here comes the typical argument... bandwidth is bandwidth, either way you look at it. All p2p does is open several simultaneous connections, splitting the user's bandwidth. Unless you horribly misconfigured your client to open up, say, 1000 ports. It's not as if the user is using any more bandwidth than if they were conducting a regular http download.

P2P actually is better for a network, as (given enough peers) it completes downloads significantly faster than normal centralized server methods, thus getting heavy users off the network noticeably faster (obviously, unless the user is dumb enough to allocate their entire upstream bandwidth to seeding).

Do I even support the above solution? By itself, absolutely NOT!! IMHO, the ideal solution is to upgrade the core and its routers. However, that takes time and capital

said by patcat88 :

Yes it is. Lets make an example. TCP equalizes the bandwidth equally for all TCP connections on the link at a single roadblock. User A and User B have 2 mbit connections to the DSLAM. The DSLAM has no one other than User A and User B. The DSLAM has a 3 mbit connection to the core router. User A is running P2P with 100 connections, User B is running an HTTP download with 10 connections. User A's speed will be 2 mbit (limited only by his DSL modem's 2 mbit speed), User B will be 1 mbit. Shouldn't it be 1.5 mbit for User A and 1.5 mbit for User B? Its not. If User A has a 3mbit connection to the DSLAM (DSLAM to internet is still 3 mbit), his speed would be 2.72 mbit ((3/110)*100), and User B will be left with .27 mbit ((3/110)*10).

Its the same reason download accelerators who make multiple connections to download an HTTP file work.

said by funchords :

Nope, because as long as the 1 Mbps connection has upward headroom, it's going to take a creep at it and some of the resulting dropped packets at the 3 Mbps choke point will belong to the other user. This means that the equilibrium will continue to creep up until some balance was made. (This thought experiment is easier if you think in terms of 1 and 10 connections instead of 10 and 100, but the outcome is the same).

There is possibly a temporary unfairness, and that's because the 100-connection link will experience a less deep cut on a dropped packet than the 10-connection link will. But ulitimately routers are stateless, they only know data packets and balance will eventually be achieved such that A and B packets get dropped at about the same rate.

Besides, none of us have a 3 Mbps choke point. You need to apply that as well.

Nope. Download accelerators work because you're taking a larger share of the distant server's ports, each of which is allocated a share of the total bandwidth.

They would work the way you envision if we had 100 Mbps connections fighting for a smaller upstream pipe. But as it is we all have a small pipe competing in a larger one -- so it doesn't.

said by funchords :

There is possibly a temporary unfairness, and that's because the 100-connection link will experience a less deep cut on a dropped packet than the 10-connection link will. But ulitimately routers are stateless, they only know data packets and balance will eventually be achieved such that A and B packets get dropped at about the same rate.

said by a333 :

The throttling of particular packets by itself violates the principles of TCP.

said by Sean :

All bandwidth should be equally distributed.

said by Sean :

All bandwidth should be equally distributed. If you are experiencing a slow down, then so should I, and vice versa.

Let me ask you, why should your data go faster then mine...?

said by devnuller :

Is bypassing TCP congestion control a good thing for the users of the network?

said by devnuller :

Is bypassing TCP congestion control a good thing for the users of the network?

said by devnuller :

Is bypassing TCP congestion control a good thing for the users of the network? Why should one persons non-interactive file sharing generating a dozen to a hundred streams be more important than my interactive VoIP call or gaming experience?

said by atom_galaxy :

Wouldn't this be a prime candidate to fix by properly using the TOS and priority packet fields? p2p apps should set priority to minimum and games and VoIP should set it at max and there we are, low-latency for apps that need it, in a protocol-defined well-mannered way.

said by FelixMc :

I think this will be a shotgun blast to the foot. Mainstream support will turn and restrictive laws will be created to fight P2P.

»www.theregister.co.uk/2008/12/01···ent_udp/

said by NOCMan :

You have to be kidding right? Fiber and even Coax freshly delivered today is vastly more expensive compared to pots DSL and existing cable plant.

said by a333 :

Problem is, in many cases, ISP's like Bell Canada block ANY secure/encrypted connections. There was, in fact, a whole lot of noise created about that a few months back, when Bell was throttling wholesale CLEC's. Many people got a rude digital slap in the face when they attempted to use encrypted VPN's. Further encryption would only add fuel to the fire in this crazy cat-and-mouse game we've been seeing for the last few years.

said by emoci :

The issue up here at least is a bit different.

All wholesalers have their own servers and their own separate agreements with PEER1, Cogent etc.. None of them had any trouble with the price of bandwith or any shortage in those terms.

However since the single monopoly on telephone lines is held by Bell they have to turn around and buy these from Bell in order to allow their customers to connect to their servers.

They pay $20/month/connection so the customer can use Bell's copper all the way to the BAS. From there they separately buy what are supposed to be dedicated 1 GBps pipes from Bell that send their customers traffic to their servers. Eg. Teksavvy has 5 and has been waiting for 2 others to come alive for about a year now.

Once in the ISP servers that traffic is no longer in Bell's network.

Now Bell throttles either just before, or just after the BAS. So in fact they are throttling the data that go over those 1GBps pipes that the ISPs buy one by one depending on how their customer base is growing ensuring that at any time their users are not using more than 50-60% of the pipelines (from what I've heard each pipe costs 8000-10000/month).

The problem here is that Bell is taking money for each pipeline but they are selling more of these pipelines that they have built (although they are significantly cheap to put up, and should be easily paid up by what the third party ISPs are paying leaving over profit)...

So I can understand Bell throttling its own retail customers because they are buying "best effort service" and as noted above if you think you have a 5/800 dedicated connection for $30 you are mistaken.

The third party ISPs on the other hand are clearly buying dedicated pipes...so why throttle these guys? How they deal with their own end-customers (to throttle or not to throttle is up to them), they were doing just fine before Bell imposed the throttling...

For anyone asking: Why not choose someone elses delivery network?

Bell has single handed control of copper in Ontario/Quebec while Telus has the same in AB/BC. The good news is that these guys are regulated to share under CRTC legistlation to promote competition. Also Bell started selling access to its copper to third paties before Bell Sympatico even existed, so the original team at Bell was quite adamant about "working with the third parties" to improve the network which seemed promising. Unfortunately the original people involved have been slowly dissappearing from Bell ranks since March-April 2008.

said by patcat88 :

Teksavvy does not buy dedicated pipes from BC. AFAIK no CLECs in Canada do. In the USA CLEC DSL is different, the CLEC must install their own DSLAM at the CO, and then the CLEC must get the traffic from their own DSLAM to the internet and out of the CO building.

In Canada, CLECs buy a packet switched (idle bandwidth uses no room) ethernet link from BC, and the ethernet link is filled with incoming VPNs. Each VPN is the traffic of that CLEC's customer's modem. The bandwidth each VPN uses can expand or decreased based on how much bandwidth the CLEC customer is using. Its not an SONET/ATM/T1/T3/ISDN link where if you have 10 customers each with a 3 mbit DSL link, you will get a 30mbit T3 from BC, and idle frames take as much room as a full frame. BC suffers the effects of contention on this business model. CLEC DSL in Canada is not circuit switched, its packet switch. Teksavvy will NEVER buy a "[# of customer]*[their DSL plan's speed]" ethernet link to BC. Also because of having to deliver all the CLEC DSL customer's traffic to a single point, over inter-CO links, BC suffers congestion.

In the united states, this case would be much different, and laughable. Teksavvy puts a DSLAM in the CO, and place connection order to ILEC. ILEC installs a DSL modem in the CO, and connects Teksavvy's customer's pair to the ILEC's DSLAM, then connects an ethernet port from the ILEC's DSLAM to the ILEC's DSL modem, then take the POTS pair from the ILEC's DSL modem and gives it to Teksavvy to plug into their DSLAM, and throttles between the ILEC DSL modem in the CO, and the ILEC DSLAM in the CO. For a final mess, look at the below.

[Teksavvy DSLAM in CO]--POTS--[ILEC DSL modem in same CO]--eth--[throttling server in same CO]--eth--[ILEC DSLAM in same CO]--POTS--[Teksavvy's customer's DSL modem at house]

lol

If it really was 3rd party DSL, you could get VDSL2, IDSL, ADSL2+, RADSL, UDSL, SDSL and SHDSL from Teksavvy for relatively the same price.

said by AstroBoy :

I am downloading 1 file with a torrent. I still get about 50 RST packets every 10 minutes.

I have Comcast. I think they still forge RST packets!

said by AstroBoy :

I have Comcast. I think they still forge RST packets!

said by cornelius785 :

i just think that any major changes to the BT protocol should be done by some 'ruling body' that everyone listens too. my concerns may also be moot.

said by NetAdmin :

Multicast won't improve the situation that P2P presents one bit. Multicast only works well in a one-to-many broadcast situation, such as a video stream or streaming radio station.

said by Bar Humbug2U :

with respect NetAdmin ,NO IT DOESNT, if you read that paper i linked to above »www.cl.cam.ac.uk/research/srg/ne···port.pdf

it make it perfactly clear your View is the antiquated old school way of thinking, and is just an excuse NOT to provide it to the end users.