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.

Application Developers..

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.

Fundamental flaw...

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

Re:Application Developers..

no you anonymous dumbass. its not the URGENT field. its bits 8 thru 16 of the IP packet -- the TOS. and its not part of TCP either...maybe you should reread whatever crap reference you gave me.
i quote from RFC 791 : Internet Protocol :

Type of Service: 8 bits

The Type of Service provides an indication of the abstract parameters of the quality of service desired. These parameters are to be usedto guide the selection of the actual service parameters when transmitting a datagram through a particular network. Several networks offer service precedence, which somehow treats high precedence traffic as more important than other traffic (generally by accepting only traffic above a certain precedence at time of high load). The major choice is a three way tradeoff between low-delay,high-reliability, and high-throughput.

111 - Network Control
011 - Flash
110 - Internetwork Control
010 - Immediate
101 - CRITIC/ECP
001 - Priority
100 - Flash Override
000 - Routine

Why we don't have QOS

I read the original article. They're implementing quality of service via something that looks vaguely like circuit-switched pipes. We've seen that before. Anyone remember Tymnet, from the 1960s, the predecessor to X.25? Same idea, but with newer technology. Very telco-oriented, with explicit setup and teardown. Well-defined for billing purposes. Some people think that's a good thing, and some don't.

The pro and anti QOS issue is quite old. When I first developed fair queueing [fh-koeln.de], 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

The article is a pure piece of Marketing

The stuff he says about the "smart network" is a big piece of crap, intended to make them look better than the giant, cisco.

'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.

Bah :)

("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.

Re:Application Developers..

They've already done it. Not every protocol in use on the Internet is "TCP-friendly". I won't name names, since, um, I was one of the offenders.

In a similar vein, there once was a little project to build a graphical hypertext browser, and they didn't like TCP's slow-start algorithm, so they made it open multiple simultaneous connections to the file server to bypass slow-start. They called that thing Netscape, IIRC.

Re:Fundamental flaw...

The problem with your argument is that for intelligence, you still need OEO conversion. The all-optical part is the data path only. To distinguish/analyze packets or to set up connections and tunnels still requires OEO conversion.

Pay to play?

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...

Network Dynamism issues

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

--

...when pigs fly and IPv6 is implemented

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

This isn't new...

This isn't such a revolutionary idea.

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/so ftware/ios120/12cgcr/qos_c/qcpart2/qccq.htm

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.