A reflection on the birth of the the network and transport layers of the TCP/IP model protocol stack. Over 15 years countless individuals contributed to the development of a network stack that could support continued growth of the ARPANET. Their design was inspired by 7 goals:
- Robustness (it was a military project after all, network gateways might be bombed)
- Different applications need different service guarantees (i.e. TCP vs. UDP)
- Support variety in the Link Layer (not everybody was running a LAN, e.g. there were radio)
- since different companies/gov agencies will own different chunks of the Internet, management must be distributed (not centralized)
- Low cost
- Adding new hosts must be easy
- Accounting must be feasible/easy
This list was sorted by priority with the items near the bottom receiving little attention at the time of the protocol design.
One big lesson to take away from the entire process is that a system that does the job good enough can become popular and be very hard to replace with a future system, even if it does the job much better.
Provide relevant background/related material as appropriate (1-2 short paragraphs)
This was a historic paper, most of the related material consists of other historical papers.
Critique the paper and suggestion discussion topics (2-3 paragraphs)
At a high level, the paper does a great job distilling design principles out of a huge complex project. To be nit-picky, I found section 10 confusing and poorly worded. I got lost on the third paragraph of "pg 113." The paper was also wrong in its conclusion with the intuition that a better building block than the datagram might win over eventually.
At a high level, the paper does a great job distilling design principles out of a huge complex project. To be nit-picky, I found section 10 confusing and poorly worded. I got lost on the third paragraph of "pg 113." The paper was also wrong in its conclusion with the intuition that a better building block than the datagram might win over eventually.
Why or why not keep this paper in syllabus?
Keep it in the syllabus because it contains both a fascinating perspective into the history of the internet/networking as we know it as well as useful system design principles (e.g. references to the end-to-end principle, and insight into the iterative process of systems design).
What issues are left open for future research?
He basically ends the paper with a suggestion for a direction he calls "soft state" which he sees as an improvement over the purely stateless datagram model. To my understanding, this idea didn't represent the direction the Internet went.
He basically ends the paper with a suggestion for a direction he calls "soft state" which he sees as an improvement over the purely stateless datagram model. To my understanding, this idea didn't represent the direction the Internet went.
What are the important implications of the work?
Uhh... The Internet. (e.g. this blog, the whole entire world, the future of humanity!)
No comments:
Post a Comment