devnuller
join:2006-06-10
Hollis, NH
1 edit | Is this a good thing for the net?
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?
Using it as a feature, maybe, but enabling this behavior by default is just wrong and will lead to continuing counter, counter measures and more justification for caps. |
|
a333
A hot cup of integrals please
join:2007-06-12
Rego Park, NY
 ·Cingular Wireless
 ·Verizon Online DSL
| 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).
As to bypassing the "TCP congestion control" you speak of, do you think Bell's solution is ANY better? The throttling of particular packets by itself violates the principles of TCP. Not only that, it also throttles/cripples MANY legitimate applications, such as secure VPN's or other encrypted connections. Do you REALLY want that as an alternative to this so-called "problem" of p2p? 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. Let's face it, even Comcast here in the states has been forced to take a long hard look at their policy on Sandvine. Soon enough, we can only hope Bell will as well...
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 that companies like Bell are rather unwilling to spend; they'd rather (ab)use their position in the limited Canadian ISP market to deploy band-aid solutions like throttling p2p. |
|
amigo_boy
join:2005-07-22
Tempe, AZ
 ·Cox HSI
 ·magicjack.com
| said by a333  :bandwidth is bandwidth, either way you look at it. That's not true. Even p2p users employ QoS to give their interactive activity higher priority (slowing down their bit torrent, etc.).
I don't see anything wrong with the same principle applying at a higher (wider) level.
Mark |
|
devnuller
join:2006-06-10
Hollis, NH
| reply to a333
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. Like this? »www.bloomberg.com/apps/news?pid=···NA18k1dY |
|
a333
A hot cup of integrals please
join:2007-06-12
Rego Park, NY
·Cingular Wireless
·Verizon Online DSL
| Yep, Comcast's "protocol agnostic" approach is EXACTLY what I was talking about, hence the reason I mentioned them in my original post..
To amigo_boy, QoS can be enabled on many different levels. Per se, many Vonage routers let you slow down ALL your internet traffic in general, to make sure your VoIP is clear/reliable. Many download managers let you put a cap on download speeds/time that stuff is downloaded. I don't see anything special about BitTorrent/P2P. What's your point? |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| reply to a333
said by a333 :bandwidth is bandwidth, either way you look at it. That's not entirely true. 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.
said by a333 :It's not as if the user is using any more bandwidth than if they were conducting a regular http download. False. A HTTP transfer would be a straight download, with the only upstream packets being TCP ACKs. In a P2P environment you upload content to other members while you download -- you will use significantly more overall bandwidth grabbing your content even if you shut down your P2P client immediately after you have completed the 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 Again, false. Your P2P client will continue uploading to other members even after you have completed the download of your file. This seeding process will keep using upstream data capacity for as long as the client is running on your machine. 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 a333 :The throttling of particular packets by itself violates the principles of TCP. Throttling flows is not a technical violation. This is how QoS systems work; if you are giving priority to some packets then by definition you are also reducing the priority and delaying the delivery of other packets. |
|
a333
A hot cup of integrals please
join:2007-06-12
Rego Park, NY
·Cingular Wireless
·Verizon Online DSL
| First of all, you took my statement "bandwidth is bandwidth" COMPLETELY out of context. Nice try, though...
Next, exactly how do you think seeding works? 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. How hard is it to get this? 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.
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. As I said, bandwidth is bandwidth. P2P doesn't magically make my available bandwidth a multiple of 10.
Overall, none of you network engineers/"experts" have given me a VALID reason to throttle P2P in PARTICULAR. |
|
amigo_boy
join:2005-07-22
Tempe, AZ
·Cox HSI
·magicjack.com
| reply to a333
said by a333 :To amigo_boy, ... What's your point? I was just responding to the assertion that all bandwidth is equal. That's not true. Even torrent users apply traffic shaping via QoS because they don't want their torrents disrupting their own interactive applications.
I see nothing wrong with applying the same common sense further upstream. Maybe ISPs aren't doing that in the best way. I don't know what they do, or what the alternatives are. But, just claiming that all bandwidth is equal is incorrect.
Mark |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| reply to a333
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. The payoff on P2P only works if many people leave their connection seeding after their transfer completes. The fast downloads of a few require extra upstream capacity from many others to be used.
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. It would require an intelligent method of distribution like using content delivery networks. Microsoft has more customers than Blizzard, and they have no problems deploying massive service packs and regular patches via HTTP transfers. Linux package managers like apt, yast, yum, or up2date also grab package updates via HTTP for the tens of millions of Linux boxes out there. Same deal with antivirus updates, or really the overwhelming majority of software updates.
Blizzard uses P2P for one key reason: cost. It moves the distribution burden and expense from them to you. In reality the WoW patches would deploy significantly faster if Blizzard were to "man up" and pay for CDN delivery.
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. 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.
The other issue is concurrence. With standard transfers you have normal human triggers that cause the load to be randomly distributed. (ie, the chances of you and your neighbor clicking a website button to trigger a large download at the same time a relatively small) Since the distribution from P2P is constant and automated, the chances of transfers of multiple P2P users all hitting the network at the same time are significantly greater. |
|
amigo_boy
join:2005-07-22
Tempe, AZ
·Cox HSI
·magicjack.com
4 edits | reply to a333
said by a333 :letting a lot of heavy users get their files faster, reducing strain on the network in general. That's illogical. If it were true that letting torrents run faster so they finish sooner (and consume bandwith for less time), torrent users wouldn't use QoS to slow down their torrents for the benefit of their web browsing, DNS lookups and VOIP.
I agree that distributed serving reduces network load compared to the load of multiple people downloading from one server. But, if distributed loads facilitate data transfer that wouldn't have been feasible from one server (because the provider wouldn't pay for enough bandwidth to meet the demand), then it has the effect of creating "virtual" servers which are unfunded on networks that didn't bargain for providing that kind of bandwidth.
It's an interesting challenge. But, let's not be coy about what's happening.
Mark |
|
rawgerz
In Debt we trust
Premium
join:2004-10-03
Grove City, PA
·Verizon Online DSL
·Sprint Mobile Broa..
| reply to espaeth
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. That's what QOS is for. Prioritize http and keep P2P at the bottom. Everyone wins. Now, if everyone using P2P was using a high encrypted VPN, then it would be a problem. Or "unlimited" high speed tiers that don't have the bandwidth to support all the clients. But that's not exactly the end user's fault.
--
You can't make all the people happy all of the time. But it should be common sense to shoot for the majority. |
|
Sean
join:2004-01-23
Ottawa
·Bell Sympatico
1 edit | reply to devnuller
I see you've been brainwashed by the anti-neutrality crowd. It's not even ABOUT which data is more important. It's about treating it all fairly.
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...? It shouldn't.
Perhaps the ISPs should give up some of their profits in order to maintain their business. Revenue is supposed to be re-invested. |
|
amigo_boy
join:2005-07-22
Tempe, AZ
·Cox HSI
·magicjack.com
| said by Sean :All bandwidth should be equally distributed. I'll believe that when torrent users stop using QoS to make their other, more interactive services usable.
Mark |
|
dvd536
as Mr. Pink as they come
Premium
join:2001-04-27
Phoenix, AZ
| reply to devnuller
YES!
because if users can bypass the crap isps are doing that its subs are PAYING FOR, they might just have to throw some of those profits at their NETWORKS!
--
When I gez aju zavateh na nalechoo more new yonooz tonigh molinigh - Ken Lee |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| reply to Sean
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...? Quite simply: because not all applications are affected by latency in the same way. Latency due to congestion makes real-time applications like RDP, VoIP, or online gaming completely unusable. Injecting latency into a file transfer simply slows it down -- it doesn't break anything, it just takes longer to get your data.
Broken apps are a bigger deal than slow apps. |
|
Combat Chuck
Too Many Cannibals
Premium
join:2001-11-29
Erie, PA
2 edits | reply to devnuller
I think you're misunderstanding just what TCP congestion control's purpose is; that being primarily to keep TCP's reaction to unacknowledged packets from doubling the amount of bandwidth a particular stream is consuming when a router along the way starts dropping packets, thus making the situation worse. UDP doesn't care if a packet is actually received or not so it won't retransmit a packet.
TCP congestion control has little to nothing to do with bandwidth management. It's about making sure that a temporary reduction in actual bandwidth doesn't result in a permanent reduction of effective bandwidth because every TCP stream over the affected link keeps sending duplicate data.
--
The world’s elusive, remember
where love's the leaf
faith, the river
what's born as flame dies in ember
see for yourself! |
|
Skippy25
join:2000-09-13
Hazelwood, MO | reply to amigo_boy
To the ISP, yes it should be as they should be nothing but the dumbpipes they are passing packets along the network.
The rest will work itself out with the law of physics, congestion, and consumers willingness to deal with it. |
|
Kearnstd
Elf Wizard
Premium
join:2002-01-22
Mullica Hill, NJ
| reply to devnuller
the problem is ISPs saw the money portals where making and comitted themselves to being portals as well. now customers expect that portal so there is no backing out to just a simple webmail page.
--
[65 Arcanist]Filan(High Elf) Zone: Broadband Reports |
|
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
1 edit | reply to devnuller
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? It's a very good thing for the network. This new protocol YIELDS to other streams. In other words, it's less agressive. The idea, eventually, is that background file transfers are handled like -- well -- background transfers -- similar to the way that background processes take a lighter toll on the CPU while you're actively using the computer. P2P users have the same concerns -- this change keeps their interactive uses snappy, and during crunch time it ought to help others as well.
TCP's congestion control (actually, there are several styles, but let's pretend there's just one) is just a choice. There's nothing wrong with reproducing the same behavior in UDP -- or any other IP-based protocol.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
|
|
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
| reply to espaeth
Espaeth, FWIW, there's a reason that dedicated file-sharers flee to "private" (they're not really) "trackers" (they're mostly websites-tracker hybrids), and it's because most people don't share all that constantly. So they sign up for these private sites (like sports leagues) to set and enforce some community rules about uploading at least as much as people download. That users do this and that it's the sharing imbalance motive is very clear.
If we lived in the world you're describing, the average up/down "ratio" would be 5:1 and private sites wouldn't exist. My guess is the average up/down ratio is 1/5. Yes, users upload longer than they download, but they also have asymmetric pipes. It takes 5-15x longer to upload the same amount as they download.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
|
|
