Reading the old design papers of the internet

Hello all, I was talking to Evan about this, and we think it would be a good idea to read up on some of the old designs that led to the modern internet by reading the seminal works and highly cited papers.

There's a couple I've read recently as part of a graduate networking course at UC Berkeley. These ones would be of interest to any person designing protocols or systems over internet infrastructure, which I believe is most of the ILP devs.

*The Design Philosophy of the DARPA Internet Protocols
*
https://people.eecs.berkeley.edu/~sylvia/cs268-2019/papers//darpa-internet.pdf 

What's really fascinating about this one is that Clark acknowledges the internet would have been very different even if some of the second level goals been shifted around.

The fundamental goal was interconnecting existing networks. Sounds familiar :)

The second goal was availability despite loss of networks or gateways. This was after all funded by the department of defense. The next three goals focus on flexibility in terms of communication services, networks, and management of resources. The others include cost effectiveness, etc. There's loads of wisdom here we can discuss in further detail, would be curious to hear more about the initial designs when determining the various layers and how they would function.

*END-TO-END ARGUMENTS IN SYSTEM DESIGN
*
https://people.eecs.berkeley.edu/~sylvia/cs268-2019/papers//saltzer-e2e.pdf

I suggest reading this paper if you haven't before since it really set the foundation for why the internet is the way it is today. There are later papers in the course that I've read which summarize it well. 

From " A Case for End System Multicast":
" According to the end-to-end arguments, a functionality should be (i) pushed to higher layers if possible; unless (ii) implementing it at the lower layer can achieve large performance benefits that outweigh the cost of additional complexity at the lower layer. "

This was in the case of routers, so depending how you look at your stack, you can quite elegantly apply the argument for having dumb logic in the lower layers too. ILP lower layers are very different than what the internet had in the sense that it's all software based. And this goes for pretty much every system today. The end to end argument is so pervasive that we've gone into recursively putting things at the ends whenever possible. 

This design choice is responsible for the quick development of the internet because the endpoints were malleable compared to routers/middleware and rapid deployment is much easier that way.

I like to use the analogy of Lightning vs Interledger for a lesson in complexity. Not just in terms of HTLCs: https://cyber.stanford.edu/sites/default/files/htlcs_considered_harmful.pdf

But also in terms of weak interoperability/decentralized exchange support. I think there's some fundamental issues with such that once it's finished for Bitcoin with all the bells and whistles (Neutrino, watchtowers, etc.), it is going to be a very stubborn protocol to deploy for more than just Bitcoin. I do like that there's a lightning plugin in progress for ILP to ensure interconnection between these network down the line. ILP is going to be a stubborn protocol to get rid of if it grows to be the connection network for a lot of payments.

If we think about the fundamental goals here, Lightning obviously had very different ones than Interledger. But if the fundamental goal of IP was interconnect, then clearly Interledger is on to something here in terms of future proofing. I'm curious to here what anyone thinks the fundamental goals were for either platform and perhaps formalizing them to further clarify the RFCs. 

*Towards an Active Network Architecture
*
https://people.eecs.berkeley.edu/~sylvia/cs268-2019/papers//active.pdf

This was a paper suggesting that it made sense to move more functionality into the middleware, and have people pay for computation. Make routers not just packet forwarders, but program executors and storage providers - basically servers that sound infra-structurally similar to many of the blockchain platforms we see.. Funnily enough, one of the biggest criticisms with this paper is authentication and billing, if you could solve it, you have feasibility. It's quite interesting to see a proposal this while Codius exists. This paper also was the inspiration for Software Defined Networking. 

They're all coming from a class here if you're interested in following along, but I'll post what I think are valuable ones every now and then: 
https://people.eecs.berkeley.edu/~sylvia/cs268-2019/syllabus.html

Hope that we can start an interesting discussion here!

*Akash Khosla*
Fourth Year EECS
akhosla@berkeley.edu

Received on Friday, 1 February 2019 16:00:34 UTC