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

A huge advantage to federated topologies or hub and spoke is that by having
pools of capital you can more effectively net flows against one another.

If the topology is truly decentralised this is very inefficient. The result
is that the network locks up more capital.

On Tue, 5 Feb 2019 at 17:29, AKASH KHOSLA <akhosla@berkeley.edu> wrote:

> One quote I like from The Design Philosophy of the DARPA Internet
> Protocols: "The goal of permitting distributed management of the Internet
> has certainly been met in certain aspects." certainly. "For example, not
> all of the gateways in the Internet are implemented and managed by the same
> agency."
>
> In today's world, we see a push for decentralization happening with all
> these new crypto protocols pushing for sound, open money standards. But
> what degree of distribution makes for a good monetary datagram protocol?
> And what does distribution mean in the case of Interledger and payment
> channel networks in general? Should we shy away from these internet designs
> for money because they aren't decentralized enough?
>
> From what I gather after these reading papers and others (will post
> another email this week with more readings) hub and spoke is the best way
> to speed up adoption/deployment and I think makes the best balance between
> performant networks and end-to-end arguments. Escaping this convergence
> requires a devolution of the monetary system because network-flow
> market-share needs to be measured by resources for security purposes, and
> only way to not have that is to be communist, essentially.
>
>
> *Akash Khosla*
> Fourth Year EECS
> akhosla@berkeley.edu
>
> On Sun, Feb 3rd, 2019 at 1:55 PM, Per Lind <per.lind@farmorcloud.asia>
> wrote:
>
>> Hi Akash,
>>
>> I agree wholeheartedly.
>>
>> Best,
>>
>> Per Lind
>> Co-founder
>> Toridion Quantum Computing Lab
>>
>>
>> On Sun, 3 Feb 2019, 22:52 AKASH KHOSLA, <akhosla@berkeley.edu> wrote:
>>
>> [image: Boxbe] <https://www.boxbe.com/overview> AKASH KHOSLA (
>> akhosla@berkeley.edu) 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
>> akhosla@berkeley.edu
>>
>>
> _______________________________________________
> Ledger mailing list
> Ledger@ietf.org
> https://www.ietf.org/mailman/listinfo/ledger
>