Slashdot Mirror
Fixing the Unfairness of TCP Congestion Control
duncan99 writes "George Ou, Technical Director of ZDNet, has an analysis today of an engineering proposal to address congestion issues on the internet. It's an interesting read, with sections such as "The politicization of an engineering problem" and "Dismantling the dogma of flow rate fairness". Short and long term answers are suggested, along with some examples of what incentives it might take to get this to work. Whichever side of the neutrality debate you're on, this is worth consideration."
The author of this analysis seems to have missed the fact that each TCP session in a P2P application is communicating with a different network user and may not be experiencing the same congestion as other sessions. In most cases (those where the congestion is not on the first hop) It doesn't make sense to throttle all connections when one is effected by congestion.
The point isn't to kill p2p. It's simply to make sure that everyone plays by the same rules... no more exploitive cheating and bandwidth hogging by the few. When there really is leftover bandwidth, p2p filesharers can use as much as they like. But it's ridiculous that when I'm spending 30 seconds downloading CNN.com during a high-demand period, some asshat is using twenty times my bandwidth downloading some file that could just as easily be sent at any time of day.
It's like taking a sofa on to the subway... if you're going to do it, pick a time when everyone else isn't trying to get to work.
Absolute power corrupts absolutely. indymedia
A New Way to Look at Networking is a Google Tech Talk. It's about an hour long, but there's a lot of very good and fascinating historical information, which sets the groundwork for this guy's proposal. Van Jacobson was around at the early days when TCP/IP were being invented. He's proposing a new protocol layered on top of TCP/IP that can turn the Internet into a true broadcast medium -- one which is even more proof against censorship than the current one!
There is a debate? I thought it was more like a few monied interests decided "there is a recognized correct way to handle this issue; I just make more profit and have more control if I ignore that." That's not the same thing as a debate.
For what it's worth, Net Neutrality IS a political fight, p2p is not the cause, but just the straw that broke the camels back. Fixing the fairness problem of tcp flow control will not make Net Neutrality go away. Nice fix though, too bad getting people to adopt it would be a nightmare. Where was this suggestion 15 years ago?
Weighted TCP is a great idea. That doesn't change the fact that net neutrality is a good thing, or that traffic shaping is a better fix for network congestion than forging RST packets.
The author of this article is clearly exploiting the novelty of a technological idea to promote his slightly related political agenda, and that's deplorable.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Just because someone comes up with a high-bandwidth protocol or service does not mean that it can be supported or should be supported with our current network capacity - especially at the expense of other protocols. Nor does it mean network providers (and ultimately users) should bare the expense of every new protocol someone on the network edge dreams up. Throttling disruptive protocols may be the least reactive solution. Blocking such protocols may be equally valid. I don't see this as a fairness issue.
The internet should stay as free and open as possible, and if it's to fall under any political philosophy it should be libertarianism.
I read TFA, but he went from jumping to "10x = 10x the bandwidth" to persistent 10x = 100x the bandwidth. Can someone explain? since, he obviously didn't. And I'd like to know if it's a complete load of bollocks or not. The way he explained it in the first page, would mean that this *wouldn't* be the case. Is he twisting the truth? or just failing to explain himself adequately?
How do they get off saying THAT line? By their own admission, the P2P apps simply TRANSFER MORE DATA, it's not an issue of congestion control if one guy uploads 500KB/Day and another uses 500MB in the same period. Hell you could up-prioritize all HTTP uploads and most P2P uploaders wouldn't care or notice. The issue with Comcast is that instead of prioritizing HTTP, they're dropping Bittorrent. There's a big difference in taking a small speed bump to non-critical protocols for the benefit of the network and having those protocols disabled entirely.
Between the data transfer amount, and THAT line, this reads like a puff piece. It's not as if the P2P applications were the first to come up with multiple connections either, I'm pretty sure download managers like "GetRight" did it.
How do you kill that which has no life?
because the Internet is a group of autonomous systems (hence the identifier "ASN") agreeing to exchange traffic for as long as it makes sense for them to do so. There is no central Internet "authority" (despite what Dept of Commerce, NetSol, Congress and others keep trying to assert) - your rules end at the edge of my network. Your choices are to exchange traffic with me, or not, but you don't get to tell me how to run things (modulo the usual civil and criminal codes regarding the four horsemen of the information apocalypse). Advocates of network neutrality legislation would clearly like to have some add'l regulatory framework in place to provide a stronger encouragement to "good behavior" (as set out in the RFCs and in the early history of internetworks and the hacking community) than the market provides in some cases. It remains to be seen whether the benefits provided by that framework would at all outweigh the inevitable loopholes, unintended consequences and general heavy-handed cluelessness that's been the hallmark of any federal technology legislation.
Those networks that show consistently boorish behavior to other networks eventually find themselves isolated or losing customers (e.g. Cogent, although somehow they still manage to retain some business - doubtless due to the fact that they're the cheapest transit you can scrape by with in most cases, although anybody who relies on them is inevitably sorry).
The Internet will be a democracy when every part of the network is funded, built and maintained by the general public. Until then, it's a loose confederation of independent networks who cooperate when it makes sense to do so. Fortunately, the exceedingly wise folks that wrote the protocols that made these networks possible did so in a manner that encourages interconnectivity (and most large networks tend to be operated by folks with similar clue - when they're not, see the previous paragraph).
Not everything can be (or even should be) a democracy. Now get off my lawn, you damn hippies.
illum oportet crescere me autem minui
TCP's fairness attempt (its not perfect, even so) is fairness among flows. But what people desire is fairness among users.
The problem, however, is that the fairness is an externality. You COULD build a BitTorrent-type client which monitors congestion and does AIMD style fairness common to all flows when it is clear that there is congestion in common on the streams rather than on the other side.
But there is no incentive to do so! Unless everyone else did, your "fair" P2P protocol gets stomped on like any other single-flow protocol. Fairness is an externality: you don't have a reason to be fair unless everyone else is, and the only reason the Internet IS even close is that TCP congestion control was done when there were a few thousand cooperating hosts, and any uncooperative entities could be squished.
Today, replacing the current congestion control with a user-weighted congestion control would be lovely, but its notgonnahappen.com, because even if you could get Microsoft on board to push a new TCP stack to 90% of the world, the P2P programs will STILL play games to increase their allocation: Vuse, in its FCC filing, actually calls it a feature how using multiple flows increases its performance.
We are going away from a world where we can trust the endpoints to "play nice" in the network. I'm afraid user-fairness traffic shaping is going to be a necessity and will be widely deployed.
Additionally, you want such traffic shaping to be protocol aware. Not just to degrade P2P, but to enhance VOIP, so even if the user is exceeding his allocation, you make sure the VoIP gets through first.
Test your net with Netalyzr
When you get to his actual proposal, he says that it's up to the application to send a message to the new TCP stack that says "Hey, I'm a good app, gimme bandwidth"? At least, that's how I read it.
I don't think I could walk to the kitchen and get a beer faster than it would take P2P authors to exploit that.
I'd say the internet is more "organized anarchy" than anything. And yes, I do realize that's an oxymoron.
a lot of p2p networks use UDP how does this version of TCP solve that ?
This article is well fine and good, but it fails to recognize that there are two types of packet discrimination being kicked around. Protocol filtering/prioritization, and Source/Destination filtering/prioritization. There are certainly good and bad ways of doing the former, and some of the bad ways are really bad (for a "for instance", see Comcast). However, the basic concept, that network bandwidth is finite over a set period of time, and that finite resource must be utilized efficiently, is not one most geek types will disagree with you on. Smart treatment of packets is something few object to.
What brings a large objection is the Source/Destination filtering. I'm going to downgrade service on packets coming from Google video, because they haven't paid our "upgrade" tax, and coincidentally, we're invested in Youtube. This is an entirely different issue, and is not an engineering issue at all. It is entirely political. We know is technologically possible. People block sites today, for parental censorship reasons, among others. It would be little challenge, as an engineer, to set to a VERY low priority an arbitrary set of packets from a source address. This however violates what the internet is for, and in the end, if my ISP is doing this, am I really connected to the "Internet", or just a dispersed corporate net, similar to the old AOL.
This is, and will be, a political question, and if it goes the wrong way, will destroy what is fundamentally interesting about the net. The ability to, with one connection, talk to anyone else, anywhere in the world, no different then if they were in the next town over.
Where are we going, and why am I in this handbasket?
I don't quite understand this analysis. Of course, switching from per stream fairness to per user fairness (or really, per host) is fine. That part makes sense. The article doesn't really do such a great job of explaining why TCP is per-stream fair, however.
Switches and routers don't work on the stream level, they work on the packet level. TCP handles this by using dropped packets as a congestion control signal. If a single host's TCP stream uses up 50% of the available bandwidth, somebody else's 50 TCP streams will experience packet drops if the aggregate tries to go over the remaining 50%.
In order for this analysis to be true, the congestion control algorithm would have to conspire to allow multiple streams from the same host to be subject to less congestion control than one stream from a single host. I assume this is the case, since I assume the proposer of weighted TCP isn't an idiot.
Now, why does this require a change in the TCP congestion control algorithm, or even to the protocol itself? If the point is to provide fairness to individual hosts/subnets connected to the network, why not just equalize bandwidth per IP/subnet, instead of randomly dropping packets so the one who sends the most packets wins? (Traffic shaping, in other words.)
While I'm all in favor of technical improvements to make the basic protocols better (for example, I have multiple users on my home network, a more responsive Web browsing experience while another host is running BitTorrent would be great), I also think it's a bit pie-in-the-sky to expect a client-end solution to this. Upgrading clients en masse is always a difficult proposition, so it's best when doing so will provide immediate benefits. If you don't get a benefit until someone else upgrades, you'll be waiting a long time for users to upgrade, especially if avid P2P users start to advise each other to the effect of "don't upgrade, Internets in Vista SP2/OS X 10.5.4/Linux 2.6.31 blows chunks".
Unfairness problem of transport protocols can not be fixed in today's internet because it requires cooperation from other nodes that forward your data, and these nodes could be anywhere in the world.
Specifically for TCP, one can just hack into the OS kernel and force TCP to ignore all the congestion notifications etc.. and thus hogging all the bandwidth...(its not that difficult)
Removing latency from voip packets at the expense of FTP is QoS. It's in general a quite good idea, and improves service.
Adding latency to only $foocorp (where $foocorp != $isp) so $isp can get more money violates net neutrality. This is a very bad idea, and borderline legal since the customer has alreaady paid.
SJW n. One who posts facts.
I need coffee before I'll really understand this, but here's a first attempt:
Ok, first of all, that isn't about TCP congestion avoidance, at least not directly. (Doesn't Skype use UDP, anyway?)
But the problem here, I think, is that George Ou is assuming that Comcast is deliberately targeting P2P, and moreover, that they have no choice but to deliberately target P2P. I'd assumed that they were simply targeting any application that uses too many TCP connections -- thus, BitTorrent can still work, and still be reasonably fast, by decreasing the number of connections. Make too many connections and Comcast starts dropping them, no matter what the protocol.
Well, where is our money going each month?
But more importantly, the trick here is that no ISP guarantees any peak bitrate, or average bitrate. Very few ISPs even tell you how much bandwidth you are allowed to use, but most reserve the right to terminate service for any reason, including "too much" bandwidth. Comcast tells you how much bandwidth you may use, in units of songs, videos, etc, rather than bits or bytes -- kind of insulting, isn't it?
I would be much happier if ISPs were required to disclose, straight up, how much total bandwidth they have (up and down), distributed among how many customers. Or, at least, full disclosure of how much bandwidth I may use as a customer. Otherwise, I'm going to continue to assume that I may use as much bandwidth as I want.
Yes, it is a tricky engineering problem. But it's also a political one, as any engineering solution would have to benefit everyone, and not single out individual users or protocols. Most solutions I've seen that accomplish this also create a central point of control, which makes them suspect -- who gets to choose what protocols and usage patterns are "fair"?
Alright. But as I understand it, this is a client-side implementation. How do you enforce it?
Nope. What I wonder is why a P2P user might want to do that, rather than install a different TCP implementation -- one which tags every single TCP connection as "weighted".
Oh, and who gets to tag a connection -- the source, or the destination? Remember that on average, some half of th
Don't thank God, thank a doctor!
The whole article is disingenuous. What he is describing are not "loopholes" being cynically exploited by those evil, and soon to be illegal, P2P applications. They are the intended behavior of the protocol stack. Are P2P applications gaming the system by opening multiple streams between each pair of endpoints? No. While we could have a legitimate debate on what is fair behavior, he poisons the whole issue by using it as a vehicle for his anti-P2P agenda.
Mea navis aericumbens anguillis abundat
3/4 of this article is basically an argument against net neutrality and p2p. It also seems to misrepresent the way ISP currently work for users to make its point. The article says if a user opens up multiple streams (not just p2p, but anything, FTP, HTTP downloads, Bittorrent), they're somehow "hogging" 10x the bandwidth of other users on the network.
But any idiot knows this isn't true, opening multiple streams only hurts you locally (causing everyone else in your house major slowdown and latency). The maximum download rate is the same and governed by your modem speed (1.5mbit, 5mbit, etc). I'm not suddenly downloading at 100mbit and hogging the shared bandwidth of the ISP. Also, if your ISP's TOS has no clause relating to bandwidth usage or limitations, you have the right to use all your available bandwidth 24/7 within reason. You pay for it. If that's not enough then charge more. I've actually called my ISP on this before and specifically asked them "So it's OK if I am downloading at max speed 24 hours a day all month." And they unequivocally stated yes.
Also doesn't anyone else find it funny that the author seems to think everyone should be limited to ONE stream? "Only big corporations need more..." WTF?
There have been plenty of lessons, Japan most recently, that upping the avaible capacity simply ups the amount of bulk-data P2P, without helping the other flows nearly as much.
Test your net with Netalyzr
That's a very good point. On the other hand, it may be the only option to fight against massive corporate internet warfare and overlordship and censorship.
"By mid 1987, computer scientist Van Jacobson who is one of the prime contributors to the TCP/IP stack created a client-side patch for TCP that saved the day. Every computer on the Internet - roughly 30,000 in those days - was quickly patched by their system administrators."...
It must have really been a nice little Internet village at that time.
...is that it expects every client to play nice. Ideas like "I could imagine a fairly simple solution where an ISP would cut the broadband connection rate eight times for any P2P user using the older TCP stack to exploit the multi-stream or persistence loophole." is such a major WTF I can't begin to describe it. If they wanted to control it, there should be a congestion control where packets were tagged with a custom id set by the incoming port on the ISPs router. So that if you have 5 TCP streams coming in to the router they'll be tagged like this:
TCP(1)
TCP(1)
TCP(1)
TCP(1)
TCP(2)
At the next router there'd be two virtual pipes:
ID1 (4 connections)
ID2 (1 connection)
It should then start randomly dropping packets from these pipes, so that half is dropped from each user. That would still be network neutrality to me, since it's content netural and protocol neutral. The "persistance" cheat is complete hogwash though, since there's no cheat. Demanding information 24/7 takes more bandwidth than an application that doesn't, well duh. What's next, sending video when an article woudl do is cheating?
Live today, because you never know what tomorrow brings
When I teach the Computer Merit Badge, I ask this trick question.
....
Q: How many computers exists on the OFFICIAL INTERNET?
A: One! Root DNS server (A)
Later we get to 13. But the rest of the computers, routers, servers, DNS's, DHCP, etc. on the internet belong to a corporation or local government. Only one belongs to the "official" internet, IANA.
Is this correct? I know it is a simplification, but I use this as a training tool to introduce ISP's roles.
Never trust a man wearing a coat and tie!
Yea there are a few issues causes this:
...
1. Porn
2.Pr0n
3. Porn?
Poster above is not a troll on this matter. The issue is pointing at TCP being "Exploited" by Bittorrent and people have failed to look at how biased and full of false information the graphs are.
.1 kbps of upstream, as that would be 40 times slower than dialup. Meanwhile to exaggerate even further they suggest that average upstream usage is .05kb/s. That would be what, 400 times slower than dialup if not more? This is absurd. They even take it a step further and suggest that less than 500 kb is sent per DAY over all the aforementioned methods. I think one or two websites can breach that amount, even on dialup.
There's a graph that shows a bittorrent user as the highest bandwith user over a day and then puts a youtube surfer and a websurfer on the same bandwith level as an xbox gamer and things of that nature. That is so far off from eachother that it is despicable.
Every one of the ones I mentioned in the previous paragraph are listed as using ".1 kbps" of upstream. There is no way in the world even websurfing alone can only use
Anyone who takes a biased study with a clear and apparent lack of research done, should look further at the details here. It's embarrassing that the blog says it submitted this graph to the White House. I don't think they could have tried any harder to vindicate bittorrent than they did with it.
Yes, bittorrent uses more speed through efficiency, not exploitation. No, bittorrent is not the only thing that opens up multiple TCP streams at the same time. Nobody uses a single stream of TCP only anymore. More than one opens the minute you go to any website, so this whole process is flawed.
And I thought senator Ted Stevens was crazy!
http://blogs.zdnet.com/Ou/?p=1078&page=2
I knew I shouldn't have read the article...
We don't need no stinking congestion control
http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf
http://www-cse.ucsd.edu/~whphilli/wsteal.pdf
Figure out the real committable bandwidth (available bandwidth / customer connections). Then, tag that amount of customer information coming into the network with a priority tag. Customers may prioritize what they want, and it will be respected up to the limit.
Example: 1000k connection shared between 100 people who each have 100k pipes. They get a committed 10k. The first 10k of packets in per second that are unmarked are marked "priority." Packets marked "low" are passed as low. Packets marked "high" or unmarked are passed as high up to the committed limit. Use token buckets for this. This would allow customers who care to choose what they want their committed bandwidth to be while leaving a free for all for the rest that's left over. No end user configuration necessary if you don't care or know to. No patches needed.
If you're feeling fancy, use logarithmically growing buckets of multiple tiers where tier always passes, tier one passes when there are no tier zero waiting, and so on.
SIG: HUP
While on a certain level splitting the available bandwidth to separate users fairly seems, well, fair, how about multi user systems? In those cases the whole system would likely put the all the users under the same bandwidth limitation. [Note: I haven't read the white paper describing the proposed system.]
;-)
Well, that might also seem fair, and there aren't that many multi user systems around, atleast compared to desktops. What if you give each user in the system a new IP? Could easily be done in an IPv6 system, or if you otherwise happen to have a few extra C-classes around.. Actually, with this method you could get the bandwidth multiplied by the share of a single host to your desktop too, provided you have enough IP addresses to use.
In practice a bittorrenter would like to have atleast two IPs: one for bittorrenting and one for surfing. This would be because the bittorrenting host would likely to be much slower for surfing the web, unless the system somehow knows that there are two different applications doing the magic. (A local gateway with bandwidth limiting would not be as efficient, although for example stopping bittorrent activity for the duration of surfing should help.) Indeed, that would be one fair approach: each separate application would have its own fair bandwidth, perhaps according to its own bandwidth desires. In some comments this approach was mentioned in a passing, apparently this is what the talk has mentioned also, and it has one undesirable side: obviously an application that attempts to get as much bw as possible would pose as n separate applications.
Hey, I think Vista and MacOSX have a solution for this, I hear they have DRM/Trusted Computing..
I'd think that a simple fix to Jacobson's algorithm could help a lot. Instead of resetting the transmission rate on just one connection on a dropped packet, reset all of them. This would have no effect on anyone using a single stream, and would eliminate problems with the source of the congestion is nearby. Variations on this theme would included resetting all connections for a single process or process group, which would throttle my P2P without affecting my browser. This alone would be more than enough incentive for me to adopt the patch: instead of having to schedule different bandwidth limits during the day, I could just let everything flow at full speed 24x7. And by putting the patch into the kernel, you'd have less to worry about individual applications and/or users deciding to adopt it.
Nothing for 6-digit uids?
Does anyone remember reading about a scheme for turning the usual QoS technique upside down?
That is, instead of marking packets you really care about (VoIP packets, say) high priority, you mark the ones you don't care that much (bittorrent downloads) about as low priority?
I recall reading about low priority marks having interesting advantages over high priority marks. It had to do with the high priority marks relying on perverse incentives (almost all routers would have to play by the rules and the more they did, the higher the payoff for not playing by the rules), while the low priority marks did not (you would start to see benefits if only a few routers amongst a sea of cheaters honored the concept).
This is an interesting point. I think most bittorrent users would agree that their websurfing doesn't seem to suffer much when BT is running, despite what you might expect.
Frankly, I think this article is a dirty trick. The author is talking about making the internet more "fair", but the ramification of his change is that ISPs will be able to charge more for "better" service if they want. In an attempt to make the network more fair, he could make it inherently unfair.
I read the internet for the articles.
Well said. The basic dishonesty in the argument is that p2p is used a boogie-man to allow filtering of traffic (which should be protocol filtering) by those who actually want to differentiate in pricing for source/destination. It needs to be said loudly and repeatedly that the two are both separate issues.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Here is the glaring flaw in his proposal:
So he wants everyone, especially P2P users, to voluntarily update their TCP stack? Why in the world would a P2P user do that, when they know that (a) older stacks would be supported forever, and (b) a new stack would slow down their transfer rates? He does mention this problem:
There are two issues with this solution:
It's nice that he wants to find a solution to the P2P bandwidth problem, but this is not it.
In the UK bandwidth out of BTs ADSL network costs ~ £70/Mbit/Month wholesale. Consumer DSL costs ~ £20/month.
You've got three options,
#1 Have an uncapped uncontended link for the £20/month you pay - you'll get about 250kbps.
#2 Have a fast link with a low bandwidth cap - think 8Mbits with a 50GB cap and chargeable bandwidth after that at around ~ 50p-£1/GB
#3 Deal with an ISP who's selling bandwidth they don't have and expect them to try as hard as possible to make #1 look like #2 with no overage charges.
If you want a reliable fast internet connection you want to go with a company that advertises #2. If you can't afford #2, you can spend your time working against the techs at ISP #3, but expect them to go our of their way to make your life shit until you take your service elsewhere because you cost them money.
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. (Einstein)
If you have a basic understanding of tcp, and reasonable c skills, it is not at all hard to make your kernel play unfair, and it can really make a big difference to your transmission rates, assuming you have a reliable connection. I sometimes wonder how many people out there have an unfair kernel like me.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
If you're using Linux, which TCP Congestion algorithm are you using? Reno isn't very fair; if a single connection is congested beyond the first hop, you'll slow down the rest of your connections when the window slides to smaller units. Have you tried Bicubic, Veno, or any of the other 9 or 10 congestion algorithms?
You can change them on the fly by echoing the name into your procfs, IIRC. Also, if you have the stomache for it, and two connections to the internet, you can load balance and/or stripe them using Linux advanced Routing & Traffic Control (mostly the ip(1) command). Very cool stuff if you want to route around a slow node or two (check out the multiple path stuff) at your ISP(s).
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
WARNING ~! Core dump follows.
It occurred to me this morning that driving on public roadways and surfing the public networks were identical experiences for the vast majority of people. That experience being; "mine, mine, ALL MINE!....hahahaha!" AKA "screw you...it's all about me!"
Now, I have the joy of managing a global network with links to 150 countries AND a 30 mile one way commute. So, I get to see, in microcosm, how the average citizen behaves in both instances.
From a network perspective, charge by usage...period. Fairness only works in FAIRy tales.
We do very good traffic shaping and management across the world. QoS policies are very well designed and work. The end user locations do get charged an allocation for their network costs. So, you'd think the WAN would run nicely and fairly. After all, if the POS systems are impacted, we don't make money and that affects everyone, right?
Hardly. While we block obvious stuff like YouTube and Myspace, we have "smart" users who abuse the privilege. So, when we get a ticket about "poor network performance", we go back to a point before the problem report and look at the flows. 99 out of 100 times, it's one or more users hogging the pipe with their own agenda. Now, the branch manager gets a detailed report of what the employees were doing and how much it cost them. Of course, porn surfers get fired immediately. Abusers of the privilege just get to wonder what year they'll see a merit increase, if at all.
So, even with very robust network tuning and traffic shaping, the "me, me" crowd will still screw everybody else...and be proud that they did. Die a miserable death in prison you ignorant pieces of shit.
Likewise the flaming assholes I compete with on the concrete and asphalt network link between home and office every day. This morning, some idiot in a subcompact stuck herself about 2 feet from my rear bumper...at 70mph. If I apply ANY braking for ANY reason, this woman will collide with me. So, I tapped the brakes so she'd back off. She backed off with the upraised hand that seemed to be "yeah, I know I was in the wrong and being unsafe" She then performed 9 lane changes, all without signaling once, and managed to gain....wait for it.... a whole SEVEN SECONDS of time over 10 miles of driving.
I see it every day. People driving with little regard for anyone else and raising the costs for the rest of us. On the network, or on the highway, same deal. And they feel like they did something worthwhile. I've talked to many users at work and the VAST majority are not only unapologetic, but actually SMUG. Many times, I'll get the "I do this at home, so it must be okay at work". To which I say, "well you cannot beat your wife and molest your kids at the office, now can you?"
My tolerance of, and faith in, my fellow man to "do the right thing" are at zero.
A technical solution (to TCP Congestion Control, etc.) is teaching the pig to sing; horrible results. Charge the thieving, spamming bastards through the nose AND constrain their traffic. That'll get better results than any pollyanna crap about "fair".
I am my own gestalt.
The guy is a jackass and lives in a reality that is more distorted than Steve Jobs'.
At least jobs makes decent computers.
Every year or so somebody else proposes to "fix TCP". It never happens. Why?
1) TCP works well.
2) TCP is in a lot of code and cannot easily be replaced
3) If you need something else, alternatives are there, e.g. UDP, RTSP and others.
Especially 3) is the killer. Applications that need it are already using other protocols. This article, like so many similar ones before it, is just hot air by somebody that did either not do their homework or want attention without deserving it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Where is it?
What's to stop users from using their P2P applications to forge packets that all say that they deserve the best weight? Even if they noticed that a ton of packets were all marked as being weighted highly, what should they do about it without having the same debate we're having now?
This seems like a good idea, but it requires the same algorithm applied to quality of service instead of to the number of packets. It doesn't meant that people couldn't "game" the system just as well.
Google bought Youtube, but you're right about the other stuff.
on the bumfuck other side of the planet from everyone else
I believe that the prime-ministerial term is "ass-end of the world". A proud moment for all Australians =), although, Colin Carpenter made us prouder when he said that Melbourne was the Paris end of the ass-end of the world.
Like all pain, suffering is a signal that something isn't right
I know that only a handful of these have been implemented for Linux or *BSD, even fewer for both. Instead of Summer of Code producing stuff nobody ever sees, how about one of the big players invest in students producing some of these meaty chunks of code?
Schemes for reducing packet loss by active queue management: REM, RED, GRED, WRED, SRED, Adaptive RED, RED-Worcester, Self-Configuring RED, Exponential RED, BLUE, SFB, GREEN, BLACK, PURPLE, WHITE
Schemes for adjusting packet queues: CBQ, Enhanced CBQ, HFSC, CSFQ, CSPFQ, PrFQ, Local Flow Separation,
Schemes for scheduling traffic: Gaussian, Least Attained Service, ABE, CSDPS
Schemes for shaping traffic flows: DSS, Constant bit Rate
Schemes for bandwidth allocation: RSVP, YESSIR, M-YESSIR
Schemes for active flow control: ECN, Mark Front ECN
Schemes for managing queues: Adaptive Virtual Queue, PRIO
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Ask yourself this question: is $BIGWEBSITE one user or millions of users?
Will $BIGWEBSITE be required to use a "weighted TCP stack" and apportion each client their "fair share" of the network or will they get a special deal that allows them to use the traditional AIMD congestion control and rate adaptation algorithms? If the latter and not the former, why? Will ordinary residential customers be able to get such deals? If not, why not?
p.s. Yes, these are rhetorical questions, and the next time I'm in an IETF presentation from one of these people, I'll be sure to put them to the presenter and watch the rhetorical handwaving come back in response.
jhw
Personally, I think they should move to a supply and demand based system, where you are charged per packet or per megabyte, and per-unit prices rise during periods of peak demand.
There are a few power companies who announce 24 hours in advance how much they're going to charge per Kwh in any given hour, and their customers can time their usage to take advantage of slack space, since the prices are based on demand.
If we do the same thing with internet service *both in and out*, a real bandwidth hog is going to wind up paying a shitload of money for his service, especially if he tries to tie up the net during peak hours. However, a casual user won't get burned.
And, coincidentally, it would solve the nasty "RIAA's making me block bittorrent" by comcast, or at least make it much harder for them to hide behind such a statement.
One particular property shared by almost ALL multimedia is that it is friggin HUGE. A movie can easily run into multiple gigabytes.
So start charging per-unit fees, and you'll put a massive leash on filesharing of media files. Suddenly, all those shared movies are costing major beaucoup to get, and they start going away.
The strange thing about this is how he discusses that he "debunked" the use of metered internet.
Now, while I agree that metered internet services are a bad idea, the author missed the point of the statement that we can see a working implementation is much different than saying it's perfect.
What I believe that the eff was suggesting was offering something akin to $5 to $10 services with a cap of monthly service in order to have an a la carte style internet for those housewives that use significantly less than a gig a month to stop the whole argument that people aren't paying more for their excessive net usage.
If a cheap, metered internet existed, it would effectively eliminate that argument. People could pay more for more service (something that we can't effectively do right now). But just like with cables services, the ISPs make their money by offering gluttonous services to people who don't need or want them.
So essentially the argument the eff was making breaks down to "You can't complain about our usage because you don't offer any alternatives." People paid for an unlimited service, and the ISPs will be DAMNED if they'll let people have it.
But like I said, I'd rather see the ISPs make their networks outrageous to support their own offerings then have them offer a la carte services.
That ass is what broadcasters and the people attacking net neutrality would like to shovel on everyone. The issue is free speech and the broadcaster goal is to eliminate competition so we are all forced to keep watching their usual shit.
I don't know why anyone would listen to Ou but his core arguments are easy to dismantle. This is the same ass who savagely attacked researcher Peter Gutmann only to whine later when Vista crapped out for him. The core argument so insultingly put forth is that selective blocking of P2P is not, "violating someone's right to free speech and impinging on their civil rights." Duh! most of the same ISPs have blanket statements prohibit subscribers from operating "servers". They turn a blind eye for the most part, but the language blatantly says "we have the right to chose how you communicate." This is indeed a restriction on your free speech that puts you at the mercy of other ISPs who may also decide to kick you out. The net result of successful censorship is imploding civil rights.
People are angry about domestic spying abuses, torture, arrest without warrant and paranoid airport security that are increasingly being used to punish political opposition. The Republican party is about to get voted out of office under a cloud not seen since the Nixon administration. Those who replace them will feel little compulsion to fix those problems if they can silence mainstream discussion of civil rights abuses and continue abusing real dissidents. They will only be able to do this if they continue the Republican assault on the internet.
Mr. Ou, you need to STFU. Your incumbent favoring rants are not only politically clueless, they are technically flawed. The better answer to congestion is to build out US networks before they sink out of the top 50th in the world. At 26th and falling, it won't be long before places like Cuba have better networks than the US. Censoring equipment steals bandwith because every decision takes time that adds pointless delays. Everything that delays build out and encourages companies to buy censorship equipment is harmful and little better reasoned that Goatse Ass.
As the one who devised much of this congestion control strategy (see my RFC 896 and RFC 970, years before Van Jacobson), I suppose should say something.
The way this was supposed to work is that TCP needs to be well-behaved because it is to the advantage of the endpoint to be well-behaved. What makes this work is enforcement of fair queuing at the first router entering the network. Fair queuing balances load by IP address, not TCP connection, and "weighted fair queueing" allows quality of service controls to be imposed at the entry router.
The problem now is that the DOCSIS approach to cable modems, at least in its earlier versions, doesn't impose fair queuing at entry to the network from the subscriber side. So congestion occurs further upstream, near the cable headend, in the "middle" of the network. By then, there are too many flows through the routers to do anything intelligent on a per-flow basis.
We still don't know how to handle congestion in the middle of an IP network. The best we have is "random early drop", but that's a hack. The whole Internet depends on stopping congestion near the entry point of the network. The cable guys didn't get this right in the upstream direction, and now they're hurting.
I'd argue for weighted fair queuing and QOS in the cable box. Try hard to push the congestion control out to the first router. DOCSIS 3 is a step in the right direction, if configured properly. But DOCSIS 3 is a huge collection of tuning parameters in search of a policy, and is likely to be grossly misconfigured.
The trick with quality of service is to offer either high-bandwidth or low latency service, but not both together. If you request low latency, your packets go into a per-IP queue with a high priority but a low queue length. Send too much and you lose packets. Send a little, and they get through fast. If you request high bandwidth, you get lower priority but a longer queue length, so you can fill up the pipe and wait for an ACK.
But I have no idea what to do about streaming video on demand, other than heavy buffering. Multicast works for broadcast (non-on-demand) video, but other than for sports fans who want to watch in real time, it doesn't help much. (I've previously suggested, sort of as a joke, that when a stream runs low on buffered content, the player should insert a pre-stored commercial while allowing the stream to catch up. Someone will probably try that.)
John Nagle
Maybe a little offtopic, but still relevant in some degree. First of all .. Im tired of reading posts that bash isps. Of course, 99 % of isps suck, but not because they throttle bandwidth for p2p, youtube and rest, but for other reasons.
(Please try to be objective, while reading this...)
I own a little isp in my (suck ass) country. I give internet to the people for cheap prices, 128/128 kbps flat for $15/month (this is the cheapest net possible here).
It is really a problem when many users use p2p, since I need to pay to MY isp and im responsible to other users, who don't use p2p.
So, what I do .. I shape p2p using L7 filters to 64kbps (half od full user link) - in effort to provide the best quality to majority of users.
Ok .. if you want a non shaped full speed link for every protocol, let's say 512kbps .. no problem. I'll charge $400 usd (thats the standard here), but you cant expect to have the same 'position' as those users who don't use p2p, and need responsive http/ssh or other protocols.
Imagine isp with 100K users .. 70 % of them bashing the link with p2p leaving all day long active, and the rest of them bashing the link with youtube... thats unacceptable, not because of materialism, because of common sense. You all got high speeds for little money, and complain all the time ... for god sake. You want quality, pay for it, and if you pay and your isp doesn't provide you with quality, sue them.
90 % of p2p traffic is illegal content sharing anyway (not saying agains it, im downloading often movies and other stuff, mainly because I cant buy it here).
Im giving net in good spirit, while everybody selled 128 kbps for 50 usd, i sold it for 15 .. so if i shape p2p, you shouldnt bash me or other people because of it.
Be objective, and keep an open mind. Everyone got problems, including isps.
Of course.. I don't support sending RST packets to bitorrent ports.
Back in 1994 to 1997 I was in many debates on just this subject.
We were buying T1 and T3 for use with video streaming and the ISP where getting upset that we were using 90% of the capacity they sold us. Apparently they specked out their cost based on office use doing web surfing. And based their models on older Telco traffic models where they needed 100 lines of outbound bandwidth for every 10000+ phone lines based on supporting 95% of the peak throughput.
But we concluded if you are selling us 1.5Mbps I dam well better be able to use 1.5Mbps, don't blame me when I use what was sold to me.
Well I see this as the same problem. If Comcast or Verizon sells me internet at at data rate, then I expect to be able to use all of it. There is nothing unfair about me using what I was sold. If they don't like it then they need to change their contractual agreements with me and change their hardware to match!
Same goes with the internal infrastructure, backbones and exchange point. If you can't support it don't sell it! Don't attack the P2P users, they are using what they PAID FOR and what was sold to them!!! If they are not getting it, they should file a class action suit.
No more then if you local cable company decided that 4 hr of TV was your limit and they would start to degrade your reception if you watched more, though this wasn't in the contract you signed up for.
On the other side, P2P should be given the means to hug the edges of the network. By this I mean communication between 2 cable modem or DSL users running off the same upstream routers (less hops) should be preferable and more efficient, not clogging up the more costly backbones. Currently P2P doesn't take any of that into consideration. Maybe ISP's could consider some technical solution to that rather then trying to deny customers the very access they are contractually bound to provide...
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
"The cable guys didn't get this right in the upstream direction, and now they're hurting."
Yes, that's an understatement. A polite one at that. The fact of the matter is that the rocket-scientists in the Cable world don't understand the Internet, or its protocols, at all. They also think they are Gods Gift to the World. You can't tell them anything, especially when they are wrong,
These are the same people who came up with the brilliant idea several years ago they would be able to tell when someone was sharing a computer on a single cable line, just from the IP traffic going on, and could shut that down easily. I.e. they had never heard of NAT. Needless to say, that idea didn't go too far. But they sure made a big noise about it at the time.
That's just one example of how they don't understand how the Internet works. IMHO, it's blindsided them in a number of ways, and they are are slow to catch up because (again, IMHO) Cable Labs didn't invent it.
I just wanted to pass along some firsthand info on the type of people you're dealing with when you look at Cable Internet implementations. Good luck with ever getting them to really change.
- many P2P protocols use UDP (skype, anyone?)
- proposes a client/application side change in behaviour, while they're whining about a failure of the protocol
- enforcement proposal ignores how the interweb works, there's NO difference (at the IP level) between a user multi-streaming a TCP download of a single file, and a user opening multiple tcp connections to a webserver to simultaneously download *all* the crappy bits-n-shits that make up a web page (ie parallel non-pipelined http requests) rather than one-at-a-time
I could go on for hours.- (think my car needs a grease-and-oilchange, so I'll go walk the dog - proposed solution bears no relationship to the problem)
- yet the first would be argued as an "unfair use* while the second is perfectly normal and acceptable behaviour
- If 'the protocol' is broken, then 'the protocol' needs to change, recommending an app-level change only opens up further opportunity for abuse
- recommending an *external* enforcement will never work, that costs time and money and who is gonna pay me to implement it?
- P2P users are initiating "sessions" (assuming they're still using TCP) to different endpoints, so you don't have a beautiful and neat bundle of parallel-tubes as described in the metaphor
Of course, the entire article starts out from a baseless assumption (that users should get 'fair' access to the interweb).- after all, if the app developers were genuinely interested in playing nicely in the sandbox, they would already
- TCP congestion control "works" (ie as engineered) because it's inherent in the protocol implementation, does not require "enforcement" by the ISP
- ie most of your assumptions about "how this works" are wrong.
Anyone read their ISP Ts&Cs ? Ever?
IP is a *best effort* protocol.... we will punt your packet upstream and hope it gets there - have a nice day.
There is *no* guarantee of *anything*.
Now, as far as anything approaching a "solution" to the supposed "problem".
What about all the P2P developers marking their "data transmission" packets (whatever the protocol) with the lowest-of-the-low QoS markings.
--> "if you need to manage congestion, I am exceedingly eligible for shaping"
That would work nicely.
In fact, if YouTube (and friends) did the same, it would actually *encourage* ISPs to enable proper QoS processing throughout their entire networks.
If applications (and protocols) inherently played nicely in the sandbox, your ISP would bend-over-backwards to guarantee a near-perfect service. (mainly because it'd thusly be near-trivial to do)
And yes I realise this raises the spectre of "Net Neutrality" - but seriously folks how is that argument any different than "because of the terorists" or "think of the children"?
ISPs Applying QoS to traffic in order to guarantee the quality is not inherently bad. The *bad* ness comes about because they will (yes, I said WILL, not MIGHT or COULD) use said QoS practices to push their own services/enforce their own policies (we hate P2P/ignore client-QoS-markings, etc , etc, etc).
All those people who're frothing-at-the-mouth because QoS is BAD need a RABIES shot.
In an ideal world, we'd never need QoS. QoS is a congestion management mechanism. If you have no congestion, then you don't need to apply QoS techniques.
But until the day when we all have quantum-entangled communications processors with near-infinite effective bandwidth we're going to need QoS, somewhere.
Visit CryptoGnome in his home.
It quickly became obvious to me, that the author of that article was way off. When I came across the term "contracted peak bitrates" I realized what the problem was. I have never seen a contract between an ISP and a customer that stated a peak and an average bitrate. They usually just state one bitrate (in each direction). What is the user supposed to consider their allowed average bitrate to be, if not the bitrate specified in the contract? If the ISP really consider that to be just a peak, and the average to be somewhat lower, they should explicitly state the average rate in the contract, and enforce it. The ISP shouldn't filter based on protocol, enforcing an average bitrate should be simpler anyway. If the ISPs would implement this bandwidth management correctly, then TCP would take care of the rest. (They might need to support ECN as well in order to give users the full capacity they are entitled to, otherwise some percentage of packets destined for that user would have to be dropped after they already used capacity).
Throttling individual users (and not protocols) is the way to go. From an ISPs point of view I don't think the definition of what constitutes a user is any problem, each customer they sign a contract with is a user. Put an average bandwidth in the contract, and throttle the link to that. If they want to be nice, they only throttle when necessary, such that outside of peak hours customers can upload and download at will.
It seems the main reason for ISPs not to state the average bandwidth in their contracts is, that they want to change it without telling their customers. When the number of customers in some area increases, the average allowed bandwidth drops, and the ISP does not tell the customers about this.
Do you care about the security of your wireless mouse?
It was because the last mile is IP over DOCSIS and DOCSIS doesn't provide for congestion very well. So goes the theory. The explanation fails the sniff test, though, because TCP/IP does have congestion control and the same behaviors that DOCSIS congestion exhibits would trigger the congestion handling behaviors in TCP/IP.
The type of congestion described by Richard Bennett is a pile-on congestion from which there is no return. This just isn't happening in the field.
> The internet should stay as free and open as possible,
> and if it's to fall under any political philosophy it
> should be libertarianism.
Of course, it is, actually, feudalism. Just as Freedom of the Press only applies to those WITH a press, the freedom to shape or not shape traffic, accept or refuse packets or connections, etc., is an indiviual one, and those individuals (or companies) with more capabilities (like multiple T3 or higher pipes, and control over their routers) thus have more control over the Internet than the little ISPs that hang off of them.
This makes IETF and ICANN the equivalent of HRE Imperial Diets, or semi-permanent Runnymedes. Of course, with this analysis, governments are the Mongol Hordes, tsunamis, hurricanes, and changes in the Solar Constant, almost all-powerful but all-UNknowning, and seldom open to negotiation (instead, they have to be accepted, then worked around when possible).
John,
Fairness is not the problem. Fairness is the wedge-issue that CATV-ISPs are trying to use to justify their behavior.
I personally like the rudimentary aspects of the weighted fair queuing proposal -- so let's image that we had it. Would Comcast still have a problem with too many upload bytes from too many homes competing for the upload path back to the CMTS? Yes.
The real problem is that CATV-ISPs are at their upper limits and FIOS is currently superiour. Most CATV nets are DOCSIS 1.1, neighborhoods of 400-500 homes sharing 9-10 Mbps back to the CMTS. Meanwhile, they have to compete with FIOS advertising 15/15, 15-20/5, 20/20, or etc. Mbps. Due to TCP and higher-layer protocol RETURN overhead, CATV ISPs can only offer download speeds if they can reserve 5% in the upload pipe -- so their download is limited by their upload. For example, downloading 8 Mbps from NNTP requires around 200 Kbps. Their upload was 256 Kbps. What happened next: to increase their download speed offering, they pushed out configuration files allowing uploads of 384 Kbps! Cost $0.00 -- no new equipment, no neighborhood splits -- just "let's pretend that we have the bandwidth." After all, customers don't care about upload speed, they just want to download.
Heh.
> instead of 'fast' movie leeching ?
I think this is a terrible assumption.
Yes many people use P2P for piracy, but it's much more.
Many companies also use it for Legitimate video distribution.
Many Linux Distro's use it to distribute ISO CD and DVD ROM images.
Bit Torrent is a medium for robust large file exchange, HTTP/FTP is far worse, as every time the connect drops the downloads are often resumed at the very beginning and use even more bandwidth.
See my paper http://www.videotechnology.com/economics_of_video.htm
With normal streaming and downloads it doesn't scale because the content offerer gets saddled with 1/2 to bandwidth cost on a $ per bit, where end receiver get a flat rate.
With P2P the end user pays close to 100% of the bandwidth costs, but again this is absorbed by their flat rate.
Nature of the Internet:
To the average FOX news viewer the Internet is just web (HTTP) hyperlink text browser experience.
But the Internet is an open communications channel for anything, and far more then http web.
There is Streaming audio, and video, live web cams, other data feeds, such as weather, news, stock,
grid computing(SETI at home), a research tool, remote monitoring, telepresence, online gaming, video conferencing, VOIP, VPN, IRC, MAIL (POP3, IMAP, SMTP), Professional Video interchange (digital fountain, digital rapids), professional movie production where masters are sent back daily "daily's", real-time medical imaging, and realtime communication with Supercomputers, realtime automotive diagnostics (tis2web), shared virtual environments, remote robotic control, SSH remote server shells and management, X windows, and so so much more.
P2P vs things like web(access to wikipedia) priority should be the choice of the customer.
How they choose to use their bandwidth is their business, you sold it to them, if you don't like it change your sales terms so they can cancel your service and go to someone else that will let them have the service they want.
In my case I used it as an uplink for live video to replace Satellite transmissions.
Also we are using it from a DVR to a remote backup (CoLo) site for 100's of customers. Again close to 100% peak data getting pushed. It's might as well be P2P, it would look the same, 16 connections pushed 24/7 live video up the pipe (Tube , hehe)
How can you discriminate between my non-HTTP vs P2P. All you know is I am using a lot of bandwidth and sabotage it.
if you want to create a spit tier where high bandwidth users pay more, that's fine, but offering unlimited flat rate and then sabotaging some users is bate and switch.
Your not providing to all of your users the service you agreed to provide, just some of them at the expense of the heavy users.
So basically anyone who is a high bandwidth Internet user you trip up, assuming they are pirates and providing a lower quality of service to.
Mean while someone downloading video masters for use with Avid or final cut pro because it is part of their job and why they bought your connection gets identified as P2P because of Bit Torrent. While they use it to do their large file transfers more reliably and faster and to them your service just starts sucks mud when compared to someone who doesn't interfere with BT traffic.
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
The internet is more like a network of roads. We know what causes congestion on roads, the lack of a market price. It's a network of commons all tragically interconnected. Without a price mechanism to signal drivers that they ought to use different routes, it's all hit or miss hoping that everyone else will take a different way to work than we do. Adding more lanes (bandwidth) helps a tiny bit in the short term, but exacerbates the problem in the long term.
Privatized roads are politically unfeasible, but a private internet is not. We are getting congestion because there is no real market price structure. We pay for access, but not for usage. Since it costs us exactly the same whether we download a HD movie or a single email, we end up downloading our movies during peak hours. Adding bandwidth won't help, because it will only encourage more people to download during peak hours. It's perfectly sensible to charge certain users more than others. I'll probably get kicked out of the geek club for saying so, but Net Neutrality is a bad idea. It's socialism for networks. Pure Marxist socialism/communism doesn't work precisely because it doesn't have market prices. It leads to gross over-production in some areas and under-production in others.
There are certainly problems, but the solution isn't big bungling government. Get the government OUT of the internet and allow networks to charge for how they wish to charge, whether that be for access or usage or something else. Let them charge more for certain uses. Let them charge more during peak movie download times. Whatever. Router protocols can handle it. They can get you the cheapest routes. Or fastest if that's what you want. Or a balance of the two.
Don't blame me, I didn't vote for either of them!
What he's describing is not just Freenet. There's also a little bit of Bittorrent in there as well, and some more ingredients. Freenet is about distribution to prevent censorship. What he's proposing is to decentralize to turn the *entire Internet* into a huge broadcast cache. This will also have the effect of making censorship difficult, but that's only a byproduct.
American's think they've got the bees-knees of internet. They're wrong. In Australia, ignoring the two ludicrously expensive ISPs (Telstra and Optus), we typically get up to 24Mbps links (that's constant, not peak) on our standard telephone line, with download quotas of around 10GB per month, for under $50. If 10GB is not enough, additional data costs around $2/GB. Is that expensive? I don't think so.
This all about control of distribution and nothing about bandwidth.
There is more than adequate bandwidth on the back end. Unused fiber is everywhere.
Come on guys. Doesn't it strike you as a bit odd that the only people having bandwidth problems are the same ones having problems SELLING you the same crap that you are now getting for free!!! Yes, I know you may be trafficking Linux or ClamV instead of Ong Bak flicks but you know... those BASTARDS at the telco want to sell you ClamV too. When you're paying for the content, the bandwidth problems will lead to no worse service than you'll experience with cable TeeVee. Don't be surprised if BOTH become worse.
The first quote was supposed to be about DPI. I accidentally pasted the same quote twice.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.