Slashdot Mirror
David Clark: Rebuild the Internet
boarder8925 writes "David Clark, who led the development of the internet in the 1970s, is working with the National Science Foundation on a plan for a whole new infrastructure to replace today's global network. The NSF aims to put out a request for proposals in the fall for plans and designs that could lead to what Clark called a 'clean slate' internet architecture. Those designs, Clark said, could be tested on the National LambdaRail, the nationwide optical network that researchers are using to experiment with new networking technologies and applications."
Obligatory
Get your Unix fortune now!
I think the time is now... look at all this dynamic javascript applications...just a band-aid on a bad system.
:-)
Actually, that's not true. Putting aside your confusion of the Web vs. The Internet, JavaScript Applications fullfill a design that was started nearly 20 years ago by James Gosling. The design I'm referring to is NeWS. The concept behind NeWS was that a Postscript renderer would be modified to allow for true Object Oriented Programming, and client/server communication. This half-document/half-program Postscript would then be downloaded to a client (potentially over EMail no less!) where it would execute and obtain remote data from its server.
Having the application at this level meant that only absolutely necessary data was transferred over the network. The application was loaded once, then only updates and file accesses would occur remotely. This design was far more powerful than X-Windows because it transferred far less data, could run over any network, and could render complex primitives from standard vector drawing programs. No other windowing system up until NeXT could do that!
It's amazing how the more things change, the more they stay the same.
Javascript + Nintendo DSi = DSiCade
"Remember: The Internet was supposed to be a network of networks NOT _THE NETWORK_."
You're misusing terms here. "Network of networks" means "routable ip networks". From an IP point of view, boxes behind a NAT are irrelevant. Nobody ever claimed that every machine should be connected to the Internet, but hosts on the Internet *were* intended to be routable.
The management and security benefits you alluded to are separate issues and can be achieved with less drastic measures than NAT.
NAT doesn't seem to completely solve the addressing problem. According to this report by Cisco to Congress (warning: pdf), we're going to run out of addresses for real somewhere between 2015 and 2025.
Yeah, I know they're a vendor, but this is a really reasonable report. They counter a lot of the hype, but they say we're going to need IPv6 eventually, so let's start now, before the Japanese and Koreans have built all the infrastructure and Americans are left to buy from them.
see that is laughable - you can't draw a curve and you are calling this the graphics drawing level
More correctly, this is a document drawing level. No one ever expected HTML/CSS to go beyond simply displaying textual data to users. As a result, it still needs some beefing up. But for regular use, the lack of things like curved objects is not a show-stopper. The fact that the document elements are solid objects is actually kind of nice, because you're *not* redrawing the screen every time. You just shift your elements around and the web browser figures the rest out.
Also, as I said before, SVG provides a nice solution to the lack of curved objects and rotation. The advantages to SVG are:
1. The image can be built in memory, then displayed.
2. Modifications can be made by walking the XML DOM Tree.
3. SVG is a good intermediary or long term format for storing drawing data.
Point #3 is rather important. Consider the case of a DHTML SpreadSheet application. If you wanted to create a Pie Chart, you can either have the server generate you an image (slow) or create an SVG on the fly (fast). Since you created the image as an SVG, you can then shunt the raw XML data back to the server for optional translation and long term storage. The server could even take the spreadsheet data and generate you an Excel file to email your coworkers.
It's quite an amazing paradigm shift.
P.S. There is some existing work demonstrating the use of dynamically generated images. The game at the link I've provided creates a new XBM image for every frame. (Info) While I don't recommend using HTML for Wolf3D, this method works perfectly for business applications.
Javascript + Nintendo DSi = DSiCade
As one of the other replies noted, DEFINITELY DEFINITELY have multicast. Anycasting (multicast from user, unicast from server) would be good, too, for informational content such as DNS requests. PIM-2 (sparse, dense or bi-directional) is at the point where if it isn't in use, it damn well should be. There is sufficient Internet Radio, webcasting and other pseudo-broadcasting over Point-to-Point protocols to justify multicasting on the bandwidth it would save.
I wrote a number of scathing articles on Internet 2 for the Guardian newspaper and I think it was the Sunday Telegraph - I forget the exact details, it was about 8-9 years ago now. I didn't believe it would be useful, I thought the naming was largely an illusion (the Internet is a federation of networks, so adding another network to that federation isn't really building anything new, no matter how fancy the gateway), most of the benefits were provided by IPv6 anyway and not the network - and those could have been had by putting IPv6 on the existing Internet instead, and most of the security was from IPSec and the same logic applies.
As for processing power, yes, TCP/IP is a hog on the processor. Not enough, on its own, to make offloading onto an I/O processor worthwhile as that is often done over a common bus not a local bus, so the extra bus traffic ewats most of the gains.
However, a local bus would be doable, or - because networking is now the norm rather than the exception - it would be possible to build network layers 1, 2 and 3 either into the CPU or into a co-processor. If you did that, you'd better have either a VERY comprehensive stack, or some damn good support for uploadable microcode, but I don't see any technical objections to it - provided you don't run through the main bus more than present and preferably less.
More likely to be useful would be hardware packet filters in the network device. Something like the packet filter from OpenBSD, in hardware, on the transciever itself, would likely speed things up a lot.
Encryption is another biggie on the CPU, and encryption hardware certainly exists. Having network devices do IPSec and SSL/TLS in hardware would likely make a big difference for secure sites and secure connections. If it became cheap enough (which would happen if used enough, as higher quantity makes for lower costs per unit) it would likely improve network security overall, as people would feel they could use it without impacting performance.
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)
What the...? Are you confused by the name? I2 is just another semi-private backbone. That's all. It's occasionally a testbed, but mostly it's just a bunch of fast routers, nothing magical. It serves much the same purpose as the early Internet: connecting universities and a few large organizations.
LOAD "SIG",8,1
They both did.
Load balancing can be also be done with iptables. See also this thread on the netfilter mailing list.
My blog
Ok, the posts by other folks above clearly explain it, but I'll take a swing at it since people are still missing it.
... duh! That's hardly a showstopper. Some consumer/home ISPs won't provide multiple IPs, but some will and absolutely all business class ISPs will provide multiple IPs. You may have to pay extra for the extra IPs.
NAT meant translating an IP address to another IP address.
PAT means translating a TCP (or I suppose UDP) port to another TCP (or UDP) port.
You can do one, the other, or both, depending on the capabilities of the software doing the translating. Obviously the cababilities of a sub $100 home router may not be the same as a custom configured Linux/BSD/Windows firewall/routing stack or a dedicated $10000+ firewall or load balancer.
If you want two web servers behind a NAT device to both run on port 80 then you need two public IPs
Any halfway decent firewall or router will have absolutely no difficulty translating 2 or 20 or 200 registered IP addresses into 2, 20, or 200 unregistered addresses of servers on your privately addressed network.
Need more power? Load balancers (available as both software and dedicated hardware) will take incoming requests to a single virtual IP and dole them out to hundreds of machines with private IPs and they use NAT to do it.
I can even distribute requests to servers based on any portion of the URL if I want to. Not just hostname, but any pattern anywhere within the full URL can be used to distribute requests to different servers.
I can put a dozen different machines on a dozen different IP addresses while simultaneously having half of them plus a separate bunch of fifty other machines all appear as a single high capacity server on a single other IP address. On top of that I can allow all of them to run their web server on a high numbered port so that the httpd doesn't need to run as root (great security enhancement) while appearing to the public Internet that all my servers are running on port 80 or any other port I choose. Nobody will ever know or care that all those machines have 10.0.0.0/8 addresses unless some developer is stupid enough to embed the machine's IP address in dynamically generated content. Any developer who does that needs to rethink the design because there's never any real need to do that; there's always a better alternative.
There is nothing wrong with NAT or PAT. You're just upset about the limitations of consumer grade hardware and consumer ISP service levels.
I think you're missing his point...All these guys are squatters from waaay back, except this one new allocation. The whole continent of Africa has to make do with half as many addresses as HP, or a quarter as many as the DoD NIC.
FTP actually predates TCP/IP, back when connections were made on IMPs that didn't do things like multiplex streams. FTP as it is now is a port of the older protocol, when third-party FTP was more common. Mail was originally implemented with FTP.
I am no longer wasting my time with slashdot
You just don't get what he's saying, and you're not making any sense.
"The only time FTP has less overhead than TCP is when you're retrieving several files."
I'm going to make a guess here and assume you mean HTTP, not TCP.
First, take a look at the FTP RFC.
http://www.freesoft.org/CIE/RFC/959/index.htm
Then, take a look at the HTTP 1.1 RFC:
ftp://ftp.isi.edu/in-notes/rfc2616.txt
You tell me which has more overhead? A notable part of the difference is the encoding; FTP can transfer data straight binary - no MIME types or special encoding to send the data over the channel.
"the overhead of FTP can be significantly higher than HTTP (logon banners)."
Are you kidding?
" For HTTP, you send the request and sit back and wait for the data. "
If browsers were as simple as an FTP client, this might be true. But don't forget about all the banners and lots of extra data that gets communicated between your average browser and HTTP server these days. Not to mention cookies.
"With FTP, you have to login (USER, PASS), which both require you to wait for confirmation before you can PORT and RETR."
All of this is is likely done in less then 100 bytes of data transferred.
"Not to mention the overhead of establishing another TCP socket to pass the data over."
Here's a quick run down of how a TCP connection is established:
1. Packet sent from initiating machine. Very small packet (bytes) with the SYN flag set.
2. Recieving machine gets packet with SYN. Sends packet back (bytes) with the SYN and ACK flags set.
3. Initiating machine sends back another small packet (bytes) with the ACK flag set.
The amount of data necessary to open a raw TCP connection is so miniscule that it's almost not worth mentioning.
"If you need to retrieve a tree structure of files, download several files from a single server, or need to upload files, FTP is the way to do it. If you need to download only one file, or several files in parallel (typical webbrowsing), then HTTP is your friend."
You're looking at this from a user perspective, not a technical one.
FTP is very low overhead (read: almost zero,) it's a very intelligent design, and it works great over slow and unreliable connections to boot.
Nobody is saying we should replace HTTP with the FTP protocol.
- It's not the Macs I hate. It's Digg users. -