Re: [Ledger] Reading the old design papers of the internet

[Per Lind <[e-mail]>]

Hi Akash,

I agree wholeheartedly.

Best,

Per Lind
Co-founder
Toridion Quantum Computing Lab


On Sun, 3 Feb 2019, 22:52 AKASH KHOSLA, <[e-mail]> wrote:

> [image: Boxbe] <https://www.boxbe.com/overview> AKASH KHOSLA (
> [e-mail]) is on your Guest List
> <https://www.boxbe.com/approved-list?tc_serial=47652602796&tc_rand=2077553940&utm_source=stf&utm_medium=email&utm_campaign=ANNO_SELF&utm_content=001&key=pfp9o0aprdql4jCeEcR8wp5d76lT0nDuooTwJ3X1HpQ%3D&token=t42fpyKw2nSmy2htq36aT2Z2J%2Fp7PtVo2GNwWs%2B%2BT7YGlF4iR1fuCrvnmVNr4vbp>
> | Delete this guest
> <https://www.boxbe.com/anno?action=remove&tc_serial=47652602796&tc_rand=2077553940&utm_source=stf&utm_medium=email&utm_campaign=ANNO_SELF&utm_content=001&key=pfp9o0aprdql4jCeEcR8wp5d76lT0nDuooTwJ3X1HpQ%3D&token=t42fpyKw2nSmy2htq36aT2Z2J%2Fp7PtVo2GNwWs%2B%2BT7YGlF4iR1fuCrvnmVNr4vbp>
> 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
> <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
> [e-mail]
>