Slashdot Mirror
Smart Routers
Lukenary writes: "For years, Cisco and Juniper have been stuck in the "smart fringes, dumb core" view of routers and the Internet. If Larry Roberts and his new company, Caspian Networks, have their way, all those promises you've heard about the Web being the new entertainment medium may play out. "Smart" routers will be able to pick out different types of packets (text, voice, media, etc.) and intelligently sequence them to their destination more efficiently. Broadband that can really stream high-quality multimedia. Worldwide, high-quality IP-based long-distance telephone. Even faster dialup connections." While the Wired reporter doesn't question the greatness of these new routers, what it means is that the backbone companies gain greater control over what traffic they will and won't permit, what they'll speed up and slow down, etc. This is likely to increase their profits at the expense of the health and dynamicism of the overall network. ("You're a residential customer, you can't serve data, only consume it!") These are the issues we've looked at before here and here.
2) Unlike IPv6, this doesn't require widespread deployment before it can be used (the chicken-and-egg problem that is delaying IBv6 deployment). Even if you are the only ISP on the planet using it, there will still be some benefit to your users.
--
Well, it could always just look for known protocols, such as those used for video vs email, etc, tag that packet, and treat all other packets to the destination port/host as the priority of that it has 'decided' it should be.
It's really a vague mapping of what the routers think the data really is. Not the best idea, but if they could flag at least the more common video/audio streaming 'paths', it could help deliver these with a lower latency. Personally, I dunno if I'm comfortable about it. If you look at it on a really theoretical lvl, providers could start to analyze what kind of traffic I'm 'consuming', and hence, target my email with yet more spam based on what I've been doing. Blech.. More data to profile on..
-- I'm the root of all that's evil, but you can call me cookie..
Yea, but the issue I can see is how it's going to actually be enforced. It's a great idea, but beyond the ability to prioritize based on either destination or source, it seems to m that developers will eventually spoof it, and hence, negate it.
-- I'm the root of all that's evil, but you can call me cookie..
This is a darned good post, I gotta say. IPv6 provides the 'smart network' by simply stating in the actual packets what priority needs to be given, and negates the need for some sort of a predictive algorithm to logically figure out what needs a higher priority.
My main concern, however, is that fact that application developers would still spoof this out, providing a higher priority for their traffic, hence, a higher thoughput, then needed. Blech...
-- I'm the root of all that's evil, but you can call me cookie..
Well, right now, there is quite literally NO intelligence involed beyond a simply netmask to determine where to hell to send the packet. I'm not so sure that intoducing *SOME* intelligence is such as bad idea, if it could be enforced somehow.. 8-(
-- I'm the root of all that's evil, but you can call me cookie..
Yea, thats what I was thinking, really. The idea is great, but the enforcement of it simply can't exist beyond a simply source/destination based rule..
-- I'm the root of all that's evil, but you can call me cookie..
Exactly what I'm thinking of. And I'm not so sure it'd b so hard to spoof the protocol into thinking it eas something else. I'm taking for granted that the routers/switches aren't going to be doing such an indepth analyses of each packet do to processing considerations, and hence, it shouldn't take to long to figure out what makes the higher priority 'kick in'.
-- I'm the root of all that's evil, but you can call me cookie..
I'd imagine it'd deal with SSL as a standard 'web' traffic packet. Things like streaming video and audio wouldn't be transfered over SSL, so hence, SSL would have a lower priority, presumably the same as standard port 80 traffic.
-- I'm the root of all that's evil, but you can call me cookie..
One has to wonder, if these 'smart routers' ever come to fruition on the internet on a large scale, how long it would take developers to beging to 'camaflague' their applicaitons data to be those of higher priority purposes, and use this as a 'selling point'. Even if there would be really no basis for this, could it simply become a selling point for 'High Priority' instant messaging of web browsing, and hence make the entire idea innefective?
As a disclaimer, I'm not saying that this SHOULD happen, simply that I could see developers trying to get their applications to utilize smart switches and routers at a higher priority then they should. Some people just don't know how it all really works, and might be 'sold' on the idea of their emails going thru at a higher priority then they really need to.
-- I'm the root of all that's evil, but you can call me cookie..
A few misconceptions here:
1) QoS (quality of service, the main use of 'smart routers', and doable today) is nothing to do with censorship. First of all, it is fairly pointless to deploy QoS on one part of an end to end Internet connection, so QoS is not used in the average Internet network. Instead, QoS technology is used on private IP networks used by businesses - either 'true' private networks, which run over leased lines or ATM/Frame Relay virtual circuits; or virtual private networks (VPNs), which in the IP world typically use IPSec or MPLS.
What happens is that businesses are sold more expensive, more secure, and higher QoS value added IP services that still save them money over separate ATM/FR services. The carriers rely on these value added services to make a profit(particularly given the telecoms downturn), particularly compared to basic dialup and ADSL/cable Internet access services. In other words, business users subsidise consumers.
This is very similar to the airlines - the existence of first and business class, etc, is another form of subsidy for consumers. You should be happy that QoS, VPNs and other value added services are being sold to businesses - they will fund network expansion (as business Internet access has done for the last five or more years) and generally make things faster and better for consumers.
2) *No new standards are required* - I work for a company that enables carriers to do all this stuff with plain old IPv4 routers. The biggest myth about IPv6 is that it will improve QoS - it won't make any difference, and has only one QoS feature (the flow label) over IPv4, which feature will require a new end-to-end QoS reservation approach that is unlikely to take over.
The people who have designed IPv6 have taken immense care to make the transition from IPv4 as easy as possible, e.g. through allowing automatic creation of IPv6 tunnels over IPv4 domains (6to4).
As with QoS, the transition to IPv6 will be funded by companies - with modern technology, the extra cost of running IPv6 on hosts vs. IPv4 is quite trivial, so even your mobile phone will have IPv6 in time, avoiding the hassles of NAT and making mobile IP much more efficient (roaming from wireless LAN to 3G networks without changing your IP address or having your sessions drop).
You might like to try reading up on these technologies before forming opinions on them - good places to start are qosforum.com, mplsrc.com and ipv6forum.com.
Theres a fundamental flaw with the theory that interior network nodes should be intelligent. The rate of progress in optical bandwidth improvement is increasing faster than Moore's Law. As a result, any intelligence that is built into the core using optical-electical-optical (OEO) technologies will actually cause the core to get slower (with respect to the overall bandwidth available) over time.
Something to think about...
FM
Frank W. Miller
Did you give that customer the option for a higher bandwidth contract, say at double the price for double the bandwidth? If so, then I would agree thc customer is cheating you. But if not, then I think you're in the wrong and the contract is agreed to under duress. If the physical link can handle 10 meg up, and the customer wants to use 10 meg up, and pays you for it, then adjust your core pipe accordingly, make more profits, and be a nice guy. Of course you need to use QOS either way.
now we need to go OSS in diesel cars
How much more bandwidth, and how much more cost? I'm just curious if this offering is priced appropriately. Also, if the tier step is too steep, I can see why the customers are wanting to cheat on you. Of course if you were charging per usage, they wouldn't be cheating, although I suspect they might not like that (since they would have to pay for what they get).
now we need to go OSS in diesel cars
There was a story a while back about a company (not sure if it was cable or DSL) that was doing similar bandwidth monitoring. When they did find someone going over their levels for a month, even by 40% over, they would also have sales contact them about an "upgrade". But the upgrade was a change from around $35 a month to over $300 a month.
If you have a big pipe to the consumer, and can monitor their usage accurately, then you really can put them in incremental tiers of service level. If they need (want) twice the bandwidth, then double the bandwidth part of the cost. Let customers set their own levels with their wallets! Why not?
And if you're going to fall back on saying the software can't do that, yet, then let's get together and go over to the development department and kick some pointy haired arse because the software should have been able to do that right from the start, and any good developer would be able to do that easily if management had wanted it.
now we need to go OSS in diesel cars
This problem already exists. This is why (some) people get excited about zero-copy network code for Linux. If your network is 1 Gbps, but the bus between your computer's CPU and RAM (say) 400 Mbps, if you copy your data once, then you have effectively halved your network throughput.
cpeterso
"For years, Cisco and Juniper have been stuck in the "smart fringes, dumb core" view of routers and the Internet.
/. to realize it, we've tried all these grand ideas before, and they've failed miserably each and every time they've been tried.
This just shows this guy doesn't have a clue about the lessons that countless thousands have learned the hard way about where complexity can be economically exploited in large scale networks.
Those of us who have had to deal with the inane complexities of "smart" networks (like, for example, OSI and ATM) recognize that the original Internet philosophy of pushing the intelligence to the edges is the *only* way to build networks that have any staying power.
Both the Internet Protocol itself and Ethernet have succeeded far beyond what most "experts" predicted specifically because they embody the dumb network idea. Although I don't expect many people here on
There are *really good reasons* why dumb networks are better - I don't have time for the whole rundown, here are a few of the biggies:
1) Pushing the intelligence to the edge puts it where it can be most easily and flexibly be changed. This is a huge win, and it allows each node to accomodate its own needs, as well as adapte reasonably to meet ongoing needs. Smart networks are, almost by definintion, static networks. They *may* be appropriate in 100 years when the Internet has a mturity level similar to the switched telephone network. (Of course, that network will then have long been replaced by IP telephony, so you're never really safe, are you?)
2) It's orders of magnitude cheaper to put these capabilities at the hosts than to put them in the network. Yes, you pay a little performance penalty for that, but remember, we've got Moore's law on our side: CPU cycles to burn, and increasingly intelligent network adapters at the volume prices that make the whole thing work. This is the whole reason why nearly all of us use the "simple, stupid" Ethernet almost exclusively and the elegant smart and complex networks like Token Ring, FDDI, and ATM will be footnotes on the ash heap of history. Because the intelligence of these networks was very expensive and in the wrong place (the core), they were not able to effectively compete with a standard that has evolved from 3 megabits/second to 10 gigabits/second, and will nearly certainly move to terabit speeds in the next few years. (For you flamers out there, I realize that 10Gb Ethernet isn't standardized yet, but the IEEE 802.3ae working group is making good progress on it and some vendors (Foundry for one) are already selling "pre-standard" 10 Gb products. It's likely we'll see a 100 Gb working group formed in the next several months...)
3) Putting the intelligence in the cheap stuff at the ends is the best way to "future-proof" the network. Centralized planning only works if you have both a crystal ball and a perfect plan, perfectly executed (ask the former Soviet Union.) The real world is (and should be) messier than that, and we *want* networks (well, everyone but the RIAA/MPAA) that accomodate serendipitous re-use.
Bottom line: History clearly shows that "Dumb" networks are in almost every case far preferable to "Smart" ones. They definitely work better in the real world, with real world economic considerations, and support the freedom to "misuse" the network by using it for things that were not foreseen by the inevitably short-sighted designers of the smarts...
"The future's good and the present is nothing to sneeze at." - Roblimo's last
This might be the first company I've seen outdo StarBridge in the "blatantly obvious BS" category. Slashdot has yet again fulfilled one of it's major roles in my life: letting me know about companies I should *avoid* investing in
Slashdot - News for Herds. Stuff that Splatters.
At my current job at Net.com I'm currently implementing what Caspian is talking about. I'm working on a BRAS - Broadband Remote Access Server which is able to interface with a portal and various services to allow the subscriber to do what they want to do.
For example, say it's Friday night and you want to watch that new movie that just came out. You log into your ISP's portal and go to the video selection, click on the movie you want and go watch it. Behind the scenes, the portal tells our box that you need, say, 5Mbps of bandwidth to the video server. Our box will guarantee that you have the bandwidth needed for the video, even if your roomate starts downloading a bunch of porn in the middle of a really exciting action scene.
This has other applications, for example gaming, video conferencing, or anything where a certain quality of service is required.
Now the BRAS needs to identify various flows and be able to individually shape flows as needed. Usually all that is needed is to look at either the layer 3 or layer 4 information, but unlike a traditional router, both the source and destination are important.
The product I am working on can guarantee bandwidth on a per-flow basis, where a subscriber might have multiple flows. That way traffic from a video server, or packets going to other gamers, will have the bandwidth and/or latency needed.
Our product is controlled via an open API, which is based on Corba and XML. This allows our box to be easily integrated into existing infrastructure (i.e. web portals and billing packages).
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Not that this will actually solve that problem. It just means that all the routers on the path across the country and back will decide to deprioritize your traffic so the connection will be slower.
The reason it bounces across the country isn't technological, it's 'business'.
Business is exactly why that won't happen. How many routers will implement this stuff at once? Not too many. One corporation's segment of the Internet backbone at a time, at the fastest. Result: angry customers - lawsuits and courts interpreting contracts for guaranteed bandwidth broken - cat and dogs, living together - et cetra until the features are disabled.
Most of the router buyers won't purchase processing power beyond what is needed for plain vanilla routing anyway, plus processing some access lists at most, and the ballooning of the routing tables is likely to suck up enough router cycles that any multi-homed network will have to pass on the new "features".
Maybe it will come in as a lump feature everywhere simultaneously along with actual IPv6 usage. I doubt it.
Still, video and audio data will be - probably is - transmitted in encrypted form when confidentiality is required, over PPTP links for company "extranets", etc.
I suspect (hope) that with a secure protocol it would be difficult to classify the traffic inside, as I understand is beingh proposed.
>To the untrained eye, Caspian's product, the Apeiro, is a
>new kind of router. But Roberts says it's not a router at
>all, because where traditional routers are "dumb" - Roberts'
>shorthand for the fact that they don't differentiate between
>the kinds of bits running over a network - his "optical IP
>superswitch," as he calls it, is smart. It can identify
>packet types (voice, text, video, et cetera) and priorities,
>allowing it to determine one packet's relation to others,
>and expedite traffic in a way that's impossible today.
Roberts sounds like a jerk. He also sounds like he's trying to do multiple label router switching (MPLS). The idea is the originating device adds a short label in a shim layer between the transport medium (ATM, for example) and the IP layer. The label is read by the label switched routers (LSR) to route the packets through the network. Contrast this with the "best guess" method that's used with regular routers or even the QoS features of ATM.
The idea is that voice packets, various types of data packets, or anything that has different requirements on latency or jitter can be served on the same network.
And the "big gorillas" are happily implementing MPLS for their next generation data networks; Alcatel, Juniper, Cisco (although -- surprise! -- they're initially implementing a proprietary approach and just calling it MPLS), and others are all doing this for their core and edge router products.
But, hey, who am I to rain on this guy's parade?
Insert simplistic political, ideological, or personal proselytization here.
The pro and anti QOS issue is quite old. When I first developed fair queueing, it was obvious to me that the queuing system could be biased to be "unfair", and that this would aid in making the Internet a billable transmission system. I deliberately didn't put that in RFC970, because I didn't want to make that happen.
A truism of modern transmission systems, including voice telephony, is that the billing process costs more than actual transmission. Worse, once you have a traffic-based billing system in place, prices tend not to decline as rapidly as tranmission costs decline. This is the major argument against QOS in the Internet.
John Nagle
'He designed the Internet to be dumb at the core, so he could keep control at his lab' What a load of crap.. The Internet of his day bears little resemblance to the Internet of today. The reason the core doesn't get into complexities is just because of CPU power. The relatively low bandwidths on the edge was the only place that had enough CPU power to do heavy processing. If you tried to do that in the core, where all the links were aggregated, you could not keep up with the load and do complex processing.
And, the junk about smart routers telling different data types is REALLY simplistic. Labelling packets for their type of data is not the challenge. Allocating bandwidth per customer, billing per usage were more difficult. And, for a really tough issue to overcome.... Your ISP, say AT&T, labels your packet high priority voice data.. It zips through their network, then goes through a NAP & gets passed to MCI's network.. You don't pay MCI a dime.. Why should they honor your priority & preempt their paying customers?
Also, he tries to make it out to be a big benefit to everyone. As if, my WWW browsing will get faster if they do prioritized switching in the core. But, in reality, today my packets are treated equally with everyone else's. With prioritized routing, I will be at a lower priority than Mr. Deep Pockets at GM, CitiBank, GE, and other high paying customers.
("You're a residential customer, you can't serve data, only consume it!")
That's okay with me, I wanna consume p0rn not serve it.
--- Metamoderating abusive downgraders since my 300th post.
It's not "just because you use different ISPs". It's because your ISPs just don't have enough traffic in your town to justify peering with each other locally. Believe me, if there were a significant amount of local traffic, they'd just as soon avoid forwarding halfway across the country.
The reason your traffic goes all over the place is largely because of the influence of current or former telecom employees in companies providing internet services.
Let's take a 10-year-old telco, for example. In 1991, if they sold data services, the value was added in getting bits from one place on their network to another. Salespuke: "Hi. MyTelecom will get your bits from your office in New York to your office in LA over our great network. Latency is X, availability is Y"
Contrast that with the internet. Where does the company find its <buzzword>value proposition</buzzword>? If their excellent fiber (or whatever physical asset) is what adds value, then they want traffic *on* their network, and not hopping off of it.
What about private peering? Oh. Well, if I'm selling transit to my customers, why am I going to give it for free to (UUNet, Genuity, Qwest, AT&T, etc.) and if I do, because peering is in my interest, well... let's do it in 3 or 4 places. New York... San Jose... maybe D.C. and Chicago if they're lucky. So... if you're sending something from Dallas to Fort Worth... well... sure, your packets have to go through San Jose, and we're wasting bandwidth on our backbone, but if they want to get better connectivity to us, they're going to have to pay for it.
<cough>
OK... enough free clues. Time to go back to looking for a job.
-Nev
Cheaper?
Internet2, if it's cheaper for anyone, is so because of the services and equipment which get donated.
But there is definitely an elitist viewpoint out there, and inside club for some of these types. I was speaking the other day to may MIS manager, and he recalled dealing with an Upper Level Manager (TM) whose attitude was that if you didn't come from the right kind of school, then you were scum and disposable.
Whether you know it or not, for some people, there is a caste system, in their own minds, and it is good because they are on top. And if you aren't part of it, well too bad. You were not born lucky.
This leads us to the viewpoint of "We can do what we want"; it is just that there is less of a social veneer to the whole thing, so that they are being less hidden about it. It is more in the open, because they feel that there is nothing to stop them. Most of the public have been tamed and domesticated. The wild (but educated) Human is a rare breed indeed these days.
Check out the Vinny the Vampire comic strip
"It is a greater offense to steal men's labor, than their clothes"
The use I would expect to see these put to is shakedown for ISPs by the bandwidth providers (Worldcom, etal.) . With them being able to tell what the packet contains and speed it up or slow it down accordingly it is not any kind of leap to do it based on packet source. This means that they will be able to sell you a T1, but if you want the premium upgrade that will cost you. The premium upgade will contain an automatic speed up of one step for packets originating at your IP range. Want another step, that's another "premium" package purchase. If you are AOL and want you packets to route faster than the packets from mindspring you just need to get the next "premium" upgrade. That way you can run ads saying that your network is faster than theirs. It will make the final days of the ISP wars a bidding adventure.
Writers of software could kick in also on this. If the packet contains a word document then give it a speed step, microsoft pays for it, Star office on the other hand gets nothing. The individual effect is negligable, but the overall impression people will get is that Office is faster than it's compitition.
The ultimate effect will be that the larger providers and software publishers will be able to pay to get increased performance on the net. The little guy will be squeezed out of the market by a lack of being able to pay for bandwidth ability.
And let's not even talk about paying to have your competion slowed down on the net...
Papa Legba come and open the gate
I dont think anyone can deny that we need some change in the way packet routing happens now. If I am trying to ftp from my machine to a client across town, why on earth does it need to be bounced across the country, because we use different ISP's. The main problem I see with this system is that there really is no way to stop the large backbone providers from selling 'priority' access for particular streams. In other words, your for pay info from foo.com will be a lot faster than your not for pay look at Slashdot. I think that if you CAN abuse it, a corporation will figure out a way to do it, no?
That's a good point, although I'd think, in order to spoof a protocol, to the extent that a QOS capable router would assign it some higher priority than it would otherwise get, the protocol being modified would have to be extremely close to the target protocol (being spoofed); so much so that it would be unlikely to be successful.
Spoofing one protocol into another to the point where a router wouldn't be able to distinguish the two is far more complex than spoofing the source or destination of packets.
Presumably, we're not talking about something simple like wrapping FTP inside SSH. I guess it's concievable that someone might wrap FTO or some other protocol inside Real Networks PNM, or something (that's the first example that came to mind) but I'm not sure how much of a value-add even that would be for a developer, to have his transfer given that marginally higher packet priority. I guess it's an issue that could be debated extensively...
As I compose this, i'm convincing myself that perhaps prtocol spoofing might be a more substancial problem... hmmm. Well I can see a scenerio where a vendor sels an FTP client ans server product set, where the vendor can garuntee a higher transfer rate than with any competing FTP client/server packaged product set. Customers would only realize a benefit when using this hypethetical across similar systems, for example enterprise remote offices.
--CTH
--
--Got Lists? | Top 95 Star Wars Line
The point was made that network dynamism will be reduced. While this is certainly true, in that new protocols will be slower to take hold, because with the introduction of new protocols would require each router to be re-tuned to handle them at a suitable priority, this is really no different than current firewalls. If you assume that the first thing a network engineer is going to do when he gets one of these QOS capable routers, is lock down his network, in essance firewalling each subnet, well then the hypothesis will be accurate.
If, on the other hand, the majority on network engineers are smart enough to know that while QOS is important, it only has business value where the benefit it offers meshed with the services offered by the provider in question, for example, the first thing every network engineer is going to do as soon as he/she gets her hand on one of these is to lock down a test enviroment, but hopefully, they will be smart enough to see if, for example, their company doesn't provide VOIP services, there's no point to tuning the routers to handle it (unless they're just trying to be neighborly or something.
The example given is, however completely valid, about choking off upstream trafic for residential broadband customers, however, this is already being done , although not with the level of rranularity with which it could be done.
While router based QOS is neat, it's really only a tiny step forward. We need IPv6 before QOS really becomes a reality. Router based QOS is just no substitute for protocol based QOS.
--CTH
--
--Got Lists? | Top 95 Star Wars Line
So these routers can analyze my packets and "determine the most efficient way to transmit them?" Is anyone else just a little bit uncomfortable with this?
I agree with those who say the Internet is not running up to spec, but I'd sure like to see a thorough discussion on how the technology can avoid actually looking at the content, not just the content type. I agree with michael (for once) that this introduces an ability for ISPs which may not be in the best interests of free expression of ideas - something I was led to believe the internet would bring us.
political_news.c: warning: comparison is always true due to limited range of data type
1) On the topic of encryption, you're talking about something at layer 5 or 6, whereas these routers would be looking at layer 4. At least, that's my view of how they work.
2) QoS. Again, we are talking about the core. The backbone providers presently use a 'dumb' core. It doesn't care about QoS and can't implement it. They route purely at layer 3, usually using IS-IS as a routing protocol. What Caspian is proposing is to enable the backbone to route at a higher layer - presumably 4 - to prioritize packets, and to keep packets of the same stream together, rather than scattering them all over the place, hoping that they all get to the destination in some useful order.
3) The ISP's and backbone providers to a degree can already favor one customer over another. They can adjust BGP costs, set static routes, etc. so that certain traffic flows in a certain way.
4) They new routers are meant for the backbone/ISP level. Your typical business won't have them. The biggest barrier is going to be replacing the existing hardware with the new stuff. That's a lot of hardware to replace, and it doesn't look like an ISP can replace things piecemeal.
If people had bothered to read the Wired article in the first place, a lot of these questions would not have been asked in the first place.
If you can't beat them, embrace and extend them.
The whole idea of smart routers is nice, but it has two major problems.
1) It is another form of corporate censorship. Before the days of big ISP (i used to use a ma and pa operation!), a host was a host was a host: ie, if you had an ip, be it dialup or a t1, you could use your bandwidth as you pleased. Granted, and FTP server on a 33.6k connection was sad, but that was your choice. Now that bandwidth at the doorstep exists, we're limited in how we can use it: if @Home had their way, all you'd be able to use is their "premium content".
2) Its a new standard. It will never fly. The internet hasn't really changed since IPv4 & TCP/IP were implemented over a decade ago. Remember: we need IPv6, and we need "intellegent" routers if we want what people have been promised, the great "information superhighway". However, there are 10's of millions of hosts on the internet, and they all have to start using new protocols for packets, and IPv6. Before we start implementing major new changes online, we need an international, independent, governing body for DNS and the internet, not an American-controlled company. The internet used to be open and democratic, lets try and make it that way once more.
-MR
-Michael Roy Some people are like Slinkies. Not really useful, but you can't help smiling when you see one tumble down
How hilarious - and how slashdot that 24 posts didn't notice...
--
"I'm not downloaded, I'm just loaded and down"
QOS, or "quality of service" doesn't mean "we're going to make your service better and better," it means "we're going to give you what you paid for it."
And it's not draconian, it's business. Anyone who doesn't devolve to the profit-maximizing model will not be profitable, he will be out-competed, and his perhaps shinier technology will be marginalized, then forgotten.
--Blair
"This is why in 2001 there are no flying cars, only five oil companies, six banks, and one internet."
This isn't such a revolutionary idea.
o ftware/ios120/12cgcr/qos_c/qcpart2/qccq.htm
It says in the article:
"The Apeiro technique is based on a standard called multi-protocol label switching, which Roberts has tweaked and renamed D/MPLS - the D is for dynamic."
Basically, in a large network the border routers would take parts of the header of the IP packet (dest/source IP address, etc just like MPLS), along with parts specific to D/MPLS (probably pulling certain information from the payload of packets, among other things), and sticking it in the ATM cell header, allowing things to be switched at Layer 2.
If your just grabbing data from the header of the IP packet, then MPLS already does this (mind you, it could be better). However, as far as being able to look at portions of the payload of packets, and switching them based on that data.. This is not feasable for a backbone router, the latency this would add would be unacceptable in most cases (versus the benefits), unless the data your looking for is always a certain length, etc.
Besides, the important part is you can impliment custom queueing on gateway and border routers, along with MPLS allowing you to do the same thing (minus a few "features", but not enough to make this anything revolutionary). Custom queueing on a Cisco will give certain types of traffic priority over others. I.E. it can give packets with a destination port (TCP/UDP) of 1720 (H.323) the highest priority, while giving FTP traffic (port 21, etc) lower priority. How to set it up on a cisco (and information on it) is at http://www.cisco.com/univercd/cc/td/doc/product/s
You can also do nifty things like give priority to traffic with a source of a certain subnet (custom queueing can't do that, but using route-map's, etc it can be done), etc.