|
3
Nerd-Its
|
|
Internet Architecture Papers
End-to-End Arguments in System Design (Saltzer, Reed, and Clark)
This paper is a classic, though its true beauty lies in that it is often cited as justification on both sides of end-to-end discussions. The main idea is that for correctness, functionality should be placed at the ends of a network - not within. Applications will perform their own functions regardless of what checking the underlying levels do. Thus, there is no sense wasting effort on pushing functionality into the network.
This paper definitely needs to be kept on the syllabus. If for nothing else than the joke on p 285. I love older style papers, where the authors come up with some ridiculous applications to real life. When talking about error correction in audio, he refers to a recovery procedure in which one person says, "Excuse me, someone dropped a glass. Would you please say that again?" Ridiculous.
It is fairly simple, except when you try to figure out where the ends are. The paper was published in '84 and was aimed at people trying to design the protocols of the Internet. The paper also acknowledges some low-level functionality can improve performance, and that is okay. They also mention "one must use some care to identify the endpoints to which the argument should be applied". When I first heard about this paper, I thought it was an argument for TCP. After further review, it seems he is arguing for UDP, letting applications provide whatever sort of reliability functions they need in place of TCP. "Use some care" indeed.
The arguments of 'application knows best' are fairly common (Exokernel), though I am of the opinion that TCP is sufficient for most applications and it is a service worth providing. Still, there are cases where the application needs its own additional functionality. If TCP interferes too much, then just use UDP. This is the line of thinking that led to the next paper's design choices (same author).
The authors make several other points to support their main ideas, such as file transfer programs needing to apply their own checksums in case of failures on the disk, in RAM, or the program. Arguably, if the latter two happen, their programs checking method is compromised too, so it isn't the strongest argument. Another point of theirs is that pushing functionality into the network makes all apps who don't need it pay the price. Specifically, audio traffic can handle packet loss, but not latency - which makes TCP horrendous.
Instead of the end to end argument, I prefer the "deal with your own issues" argument. If the issue is that disks are storing corrupted files, deal with that at the filesystem or block layer. If the problem is duplicate packets due to network congestion/replay/etc, then let the network layers (talking about TCP here) handle it. In general, layers that cause a problem are best suited to deal with it. The important thing is to just provide an option to higher levels in the API in which those safeties can be turned off if you want. And it is usually better for performance to deal with things quickly and appropriately. (Think of MAC layer checksumming).
There are other things I can talk about in this, but I'll save it for another day.
The Design Philosophy of the DARPA Internet Protocols (Clark)
This is another great paper. It explains the design decisions behind the Internet, mainly to connect existing networks and a variety of future networks, be survivable in the face of disaster, have distributed management, and a couple of lesser things (cost, accounting, ease of connecting a host).
The main thing people probably bring up now is that survivability is not as great a concern as cost and accounting - given the major commercialization of the system. I don't completely agree. I like the idea of a system that can recover from losing a major chunk (nuclear blast, power outage, Comcast, etc).
Another thing to consider is what they were really talking about when they discuss survivability in the face of failure. The guarantee the transport layer (TCP) provides is that the virtual circuit will stay up except in the face of total failure. Either the packets make it, check summed and in-order, or the network is partitioned. Transient failures are masked. They did this by pushing state to the extremities of the system (end-to-end). The internals did one thing, and did it well (routing).
That being said, there are other types of degraded service - latency, bandwidth shrinkage, jitter - that applications care about. Post-meltdown TCP tries to be a good citizen about these things, but one could argue that some functionality could be added in to the network. How is not nearly as clear. Clark hints at this in his conclusions when he talks about gateways tracking flow state. It's performance/feature-friendly state that isn't critical to the survival of the network. He calls it "soft-state", and thinks of using it to provide accounting and resource management, though it can be used for any number of things.
Star This to Save in Your Profile 
Add a Comment (3)
Email This
Message Author
Statistics
Thread parent sort order:
Thread verbosity:
1 Nerd-It
One Solution is NEVER a Good Idea
I find it somewhat amusing that debating the matter is even warranting of architecture designer's time. The classic consultant response "it depends" is aptly applicable to the design requirements for any particular application. As you've pointed out in your review above, there are always critical cases where having the network perform some functionality transparently to the application is appropriate just as there are times when the application itself needs to be able to make those decisions.
So I wonder - what is the merit of even having the discussion to go all functionality heavy or functionality lite? Perhaps if the protocols didn't already exist, I could somewhat see the value in discussing an approach. But even then it would seem ridiculous to even consider restricting folks to "just one" choice.
Even when you're sitting at the coder's desk writing your program and interfacing with the socket library you have the option of choosing RAW as a socket type which allows you to craft the packets yourself - effectively bypassing all the functionality built-in by cheating.
I guess I just take the view that forcing somebody to pick one and say it's "the way" shows a remarkably limited amount of vision by he who demands such a thing. Black boxes are great, but in a realm where you can pick and choose your black box, arguing for the ultimate box and making things fit around it seems a waste of time when you can simply choose a box that fits the solution.
Of course, I assume a professor's point of view is that a student should realize this and that the exercise merely forces them to better understand one of the boxes.
This comment has 1 reply.
RSS
Interesting multipurpose blog site by Anonymous :: NR0 :: Show
I agree with you re: e2e paper -- it is often referenced and less frequently read. It is very pragmatic in the way it frames the argument and applies it. As for the DARPAnet Protocol Design paper, it is interesting to look at it from the view of some of the mighty failures of that design -- particularly that of security -- and where that fits with respect to the set of requirements.