Slashdot Mirror
ARPANET Co-Founder Calls for Flow Management
An anonymous reader writes "Lawrence Roberts, co-founder of ARPANET and inventor of packet switching, today published an article in which he claims to solve the congestion control problem on the Internet. Roberts says, contrary to popular belief, the problem with congestion is the networks, not Transmission Control Protocol (TCP). Rather than overhaul TCP, he says, we need to deploy flow management, and selectively discard no more than one packet per TCP cycle. Flow management is the only alternative to peering into everyone's network, he says, and it's the only way to fairly distribute Internet capacity."
He seems to agree. This surprised me but it seems that equipment can do this fairly.
Oh, from his company of course.
Larry Roberts was co-founder of the ARPAnet, but he did NOT invent packet switching. That invention goes to Donald Davies of the National Physical Laboratory in the UK. His work was well-credited by the ARPAnet designers.
The problem is, some people will start throwing away 2 packets instead of 1 so that they can get more "throughput" on more limited hardware. Someone else will compete by tossing 3, and the arms race for data degradation will begin.
Will this method really offset the retransmits it triggers? Only if not everyone does it, unless I'm missing something.
What might work better is scaled drops: if a router and its immediate peers are nearing capacity, they start to drop a packet per cycle, automatically causing the routers at their perimeter to route around the problem, easing up on their traffic.
It still seems like a system where an untrusted party could take advantage to drop packets in this manner from non-preferred sources or to non-preferred destinations however.
I'm not big on networking but if I'm sending data to someone and some "flow management" dumps one of the packets, won't my computer or modem just resend it? Seems like not such a good idea to me.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
Why didn't he think of that 40 years ago?
Can someone explain why this hasn't already been implemented?
Seems like there would have to be a good reason, otherwise this would just make more sense, right?
So now we actually DO need to make the Internet more like a series of tubes??? brain asplode
I have been told that the ability to do this has been around since the 1970s. Don't all equipment makers have some version?
Doesn't the picture kind of look like the juice-man? Or more generally, "Active old guy, excited about stuff, selling nearly worthless Ronco trinkets"
Can you be Even More Awesome?!
This does not sound like a correct solution. Rather, emphasis should be placed on installing more links, both in parallel to existing links, and "bypass" links that will shorten the number of hops from one given location to another. Whether based on copper, fiber, satellite, or other technology, the sheer number of separate paths and additional routing points will make a huge difference. Special emphasis should be placed shortening the hop count between any two given areas.
McCain/Palin '08. Now THAT's hope and change!
ANy device sophisticated enough to do the flow fairness described can also do "user" fairness by averaging behavior across multiple flows from the same soure, and the behavior of the source over time.
This solves the P2P problem, and has a bunch of other advantages.
Note, also, you only need to do this at the edges, as the core is pretty overprovisioned currently.
Test your net with Netalyzr
It seems to me that by moving knowledge of flows into the routers, you make it easier to tap into these flows from a centralized place - i.e., the router.
Not that tapping connections can't be done now by spying on packets, of course, but it would make it much cheaper to implement. High-overhead packet matching, reassembly, and interpretation is replaced by a simple table lookup in the router.
Donning my tinfoil hat, I can foresee a time when all routers 'must' implement this as a backdoor...
I couldn't help but laugh a bit at his solution. He talks about "flow management" being put into the core of the network to solve TCP's unfairness problem, but at the end of the article he says:
So, in other words, his solution to the "P2P problem" is just a fancy version of a token bucket.
Comment removed based on user account deletion
Could you elaborate on this?
Why bother feeding the trolls?
When using Linux as a router there are already several ways to per-flow fairness. The simplest and most obvious one is Stochastic Fair Queuing. The problem is that commercial routers can't do that in hardware.
http://www.tampax.com/
http://www.kotex.com/
Remember "News for Nerds, Stuff that Matters"? Help make it a reality again! http://soylentnews.org
While approximately fair is not quite as good as fair, avoiding hard state makes for a cheaper and more reliable network, which allows you to more easily over-provision your link capacity. Unless, of course, you're in the business of selling routers that implement hard state...
The problem is, without user fairness, the heavy users get MORE bandwidth. This is the multiflow problem.
Your neigbor and you share a common bottleneck. Your websurfing, he's got 6 torrents downloading. He is going to have at least 24 active flows, running full bore, and you will have 1 or 2 (which are bursty even). Thanks to how TCP works, without traffic shaping, you will receive 1 packet for every 24 he gets.
User fairness is necessary to be implemented in the network to keep his traffic from walking all over you.
Test your net with Netalyzr
when a big hose will do the job better
.then they will come
just build the capacity,
...from one's own TCP stack.
I think this proposal is a bit reckless and naive at the same time. Not a good combination. Add to that he is trying to set a precedent for data degradation when none is needed.
If networks want to reduce traffic in a civil manner, they will price their service similar to the way hosting providers do: Offer a flat rate up to a set cap measured in Gb/month, with overages priced at a different rate. People would then pay for their excesses, allowing the ISP to spend more on adding capacity.
End-users like this arrangement for cellphone service. They would understand and appreciate such a thing coming to their Internet service, especially if it meant that most of them ended up paying $10 less on their monthly bill.
I think we are not seeing a transition to cap-and-overage pricing structure because the ISPs are more interested in becoming monopolies, not with competing the way wireless services naturally do. Verizon is turning its back on many lower-middle-income areas while it tears out common-carrier POTS lines from the neighborhoods it does serve. Comcast winks, nods and accepts its role for the lower-end neighborhoods, degrading throughput and behaving as a paternalistic manipulator of data in the process. They are carving up the market, so don't expect rational and time-tested solutions that benefit the customer.
wonder if routing algorithms themselves aren't contributing to the problem.
BGP and the intra-domain routing protocols assume there is at most one correct route from a given source address to a given destination address. That assumption could give rise to unnecessary congestion. For example, suppose the source wants to use bandwith of 100 units and the destination is capable of keeping up. But between them there are two routers, in parallel, each of which can supply only 50 units. If there's exactly one path, source and dest can't talk any faster than 50 units because everything has to go through one of the two routers. (There are mechanisms to share bandwith in some situations, like the simple parallel routers one I described, but they dont' work for arbitrarily complex routing topologies across multiple BGP domains.)
It's possible, though, to imagine a network that routes in such a way that data could use both routers. For instance, in circuit switched networks the preestablished path tends to hang around even as the current "best" route changes, so in the earlier example two 50 unit connections between source and dest might end up being spread across both routers.
Rather than taking the congestion as a given, and figuring out work-arounds, I wonder if someone's done some research into why it exists and whether it's due to hot spots forming in the traffic flow.
Everyone's got their favorite experts and they are often a shortcut to lots of research you don't have time for. He's an independent expert who cares more about your rights than other things, happens to be an expert in OS design who's been working since the early 70s and knows something about networking as well. Finally, he likes to answers email.
TCP is mostly controlled by round trip time measurement and window size. Response to packet loss is a backup mechanism. If packet loss were the primary control mechanism, TCP would never work.
It's much better to throttle back before packet loss occurs, since any lost packet has to be resent and uses up resources from the sender to the drop point. Since the main bandwidth bottleneck is at the last mile to the consumer, the drop point tends to be close to the destination.
Don't trust the "Clean Slate Internet" project too much. That started as telco-supported scheme to move more functionality to the telcos so they can add charges for specific services, like cell phone providers.
Like all technologies, the effects depend on how the technology is used. While there are issues of unfairness with random drops, one can *imagine* ways that (from TFA), "What is really necessary is to detect just the flows that need to slow down" - however, it would seem just as easily networks could "detect just the flows that need to slow down" based on who is paying more for that flow (the sender or the receiver) - leading to even more "unfairness" (read: non-neutral network a la net neutrality) than we currently have.
What I've noticed the most, particularly since I'm running about a dozen machines over a DSL line (just now switched from the T1 I had for many years), is that packet management depends heavily on how close the packet is to the end points. Packet management also very heavily depends on whether the size of your pipe near the end point is large relative to available cross country bandwidth, or small (like a DSL uplink).
When the packet is close to an end point it is possible to use far more sophisticated queueing algorithms to make the flow do precisely what you want it to do. It's important for me because my outgoing bandwidth is pegged 24x7. Packet loss is not acceptable that close to the end point so I don't use RED or any early drop mechanism (and frankly they don't work that close to the end point anyway... they do not prevent bulk traffic from seriously interfering with interactive traffic), and it is equally unacceptable to allow a hundred packets build up on the router where the pipe constricts down to T1/DSL speeds, (which completely destroys interactive responsiveness).
For my egress point I've found that running a fair share scheduler works wonderfully. My little cisco had that feature and it works particularly well in newer IOS's. With the DSL line I couldn't get things working smoothly with PF/ALTQ until I sat down and wrote an ALTQ module to implement the same sort of thing.
Fair share scheduling basically associates the packets with 'connections' (in this case using PF's state table) and is thus able to identify those TCP connections with large backlogs and act on them appropriately. Being near the end point I don't have to drop any of the packets, but neither do I have to push out 50 tcp packets for a single connection and starve everything else that is going on. Fair share scheduling on its own isn't perfect, but when combined with PF/ALTQ and some prioritization rules to assign minimum bandwidths the result is quite good.
Another feature that couples very nicely with queueing in the egress router is turning on (for FreeBSD or DragonFly) the net.inet.tcp.inflight_enable sysctl. This feature is designed to specifically reduce packet backlogs in routers (particularly at any nearby bandwidth constriction point). While it can result in some unfair bandwidth allocation it can also be tuned to not be quite so conservative and simply give the egress router a lot more runway in its packet queues to better manage multiple flows.
The combination of the two is astoundingly good. Routers do much better when their packet queues aren't overstressed in the first place, only dropping packets in truely exceptional situations and not as a matter of course.
The real problem lies in what to do at the CENTER of the network, when you TCP packet has gone over 5 hops and has another 5 to go. Has anyone tried tracking the hundreds of thousands (or more) active streams that run through those routers? RED seems to be the only real solution at that point, but I really think dropping packets in general is something to be avoided at all costs and I keep hoping something better will be developed for the center of the network.
-Matt
This sounds like a pretty good idea until you start thinking about NAT'ed networks. Is it really fair to treat an entire office or dorm (or even a small country) the same as a single user who happens to have a unique IP from their ISP? And what about the transition to IPV6, when presumably IP addresses are no longer going to be scarce?
One reason why that might be problematic in practice, is that, iirc, TCP doesn't like getting packets out of order, and tends to respond to out-of-order packets similarly to dropped packets. If you have packets taking multiple paths, they are very likely to arrive out of order.
One could mitigate this, I suppose, by making sure all packets that are part of the same flow take the same path.
Comment removed based on user account deletion
Roberts has been harping on the same thing since 2000, probably earlier. Guess why he has built several failed companies around the concept. It seems that Slashdot forgets this every few months and posts another one of his rants.
I have a lot of respect for Larry Roberts. The idea of only discarding a single packet per flow on a congested interface in order to slow things down is a good one.
If WRED didn't exist on every production-grade router made in the last 10+ years then there would certainly be a need for this technology. However, I'm not really sure how much benefit the "multi-flow fairness" concept would provide vs. just configuring WRED to discard only payload packets & not TCP control traffic. The tradeoff is the added complexity of the congestion avoidance mechanism having to be flow-aware, which increases cost, time to market, heat & power consumption, etc.
Such a technique combined with microflow policing would come closer to what he describes. In fact one could probably refer to the congestion avoidance technique described in the article as "adaptive microflow policing".
A pretty standard config used with OpenBSD's PF firewall is to prioritize ACKs in both directions so that a line congested in one direction is still useful in the other.
BTW, TCP has already been re-engineered; it's called SCTP. If you've got a custom high-bandwidth point-to-point application where you have complete control over both ends (mostly research stuff at this point), check it out.
A different approach to bandwidth management that is being developed by the major router vendors is the application-aware network. Imagine if the router was smart enough to read a field in an XML stream that indicates that this particular flow requires 64kbps or it should be dropped, it should have 256kbps to work well, and giving it more than 1mbps is not useful and you start to get the idea. That's just the tip of the iceberg.
Anyway, congestion control is useful & necessary, but "quality of service is no substitute for quantity of service"...
instead of TCP. IP is the future. I've heard that LMNOP is to be even better though.
One problem with this idea is that packets can follow different paths through the network. That is one of the fundamental principles of packet-switched networks. The concept in TFA works if you have choke points in the network, but such choke points also defeat the power of the Internet.
Calling qualities of the protocol 'unfair' is a bit disingenuous. The fact that the data being carried is bigger and takes more bandwidth doesn't make things 'unfair', it just means that the network needs to be properly provisioned, and guess what, routing can make allowances for those things.
By the way, 'clouds, not strings' is a catch-phrase from Van Jacobsen to challenge ideas like those in TFA when they were bandied about many years ago. The network is supposed to be a cloud, not a string, so trying to control traffic streams in which each packet may follow a different path through the cloud is problematic.
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
is that whoever pays more gets more. period.
Wait... Twitter managed to post without saying M$? Unbelievable!
Complete sentences... somewhat stable personality... You must have taken your pills today. Good job! Just don't burn all of your well-earned karma in one day now.
...is this guy going to float his company.
You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
having only the RX/TX and ground wires twisted together isn't going to cut it anymore. We'll leave RI disconnected though as it's an obvious security hole.
"Although the multi-flow unfairness that P2P uses remains, flow management gives us a simple solution to this: Control each flow so that the total traffic to each IP address (home) is equally and fairly distributed no matter how many flows they use. This eliminates the need for peering into everyoneâ(TM)s data to stop P2P and creates a fair distribution of Internet capacity."
Therein lies the rub. The bandwidth hogs will simply acquire more "flows" so they won't be throttled, and they'll get a wider bandwidth no matter what.
What needs to happen is to identify packets for what they are. Flows that can tolerate delay better (e.g., P2P file transfers) should be delayed (by dropping packets or whatever). Packets with more immediacy (e.g., human, game, machine interaction) should get priority.
I personally could give a damn about people sharing or downloading music or video, realtime video or TV, etc. I specifically could give a damn about someone's phone call quality! That's not what the Internet was built for, and I'm oldfashioned that way. Delay that crap all you want.
Toad-san
Why bother feeding the SPAM posts which main purpose seems to be a link to a commercial company anyway? ;-)
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...