Re: [Ledger] An attempt to clean up the protocol architecture

I have to echo Ben's question about where this conception of layering comes
from.

In RFC 1122: Requirements for Internet Hosts -- Communication Layers
<https://tools.ietf.org/html/rfc1122#page-15>, it says:

> Protocol layering, which is generally used as an organizing principle in
implementing network software, has also been used to organize this
document...strict layering is an imperfect model, both for the protocol
suite and for recommended implementation approaches. Protocols in different
layers interact in complex and sometimes subtle ways, and particular
functions often involve multiple layers.  There are many design choices in
an implementation, many of which involve creative "breaking" of strict
layering...*This document describes the conceptual service interface
between layers using a functional ("procedure call") notation*, like that
used in the TCP specification [TCP:1]. A host implementation must support
the logical information flow. implied by these calls, but need not
literally implement the calls themselves.
> In general, each major section of this document is organized into the
following subsections:...*(4)  Interfaces -- discusses the service
interface to the next higher layer.*...

As far as I understand it, the idea is that each layer provides a set of
functionality or interface to the layer above. Each layer SHOULD NOT (in
the RFC sense, meaning it's wrong to do it but implementations may do it
anyway if they think they know better) inspect or try to understand the
data of higher-level protocols.

> From the perspective of the Interledger Protocol the implementation of
the lower layers is not important, that's the whole point of layering.

I'm pretty sure this is incorrect. Layers are defined by what functions
they provide to the layer above them. *How* they provide that functionality
is an implementation detail but not *what* functionality they provide.

> ILP doesn't care if the layer below even has a concept of HTLAs. I can do
ILP over Bitcoin without the overlay layer if I want to but I need to find
a peer that is prepared to do that with me.

I think you're missing the point of the HTLA idea. It is precisely the
functionality that Interledger requires. When you say you need to "find a
peer that is prepared to do that with me", the "that" means "use a pre or
post-funded trustline with Bitcoin settlement" (also using a specific
method and protocol for communication).

Interledger doesn't care how you implement HTLAs but that is the interface
it expects from the layer below it (+ request/response-based messaging).

We could have defined ILP differently to have lower requirements on the
layer below it. We could have said that all messaging goes over IP and is
thus part of the Interledger layer implemented by connectors. We also could
have said that we assume only that ledgers can do simple transfers so that
connectors are also the ones that implement the conditional transfer
semantic and always use simple ledger transfers for settlement. There is no
one right place to put this functionality. Where it should go depends on
the benefits it brings.

By abstracting both the messaging and the implementation of conditional
transfers we have allowed for implementations of the ledger layer to vary
from nothing being provided by a ledger to everything. If Interledger is
successful, I would expect future networks to be built with it in mind. I
think it's better to build for the assumption that ledgers will implement
whatever Interledger needs from them and create a way to overlay that on
existing ledgers that don't, rather than assuming ledgers will always be
built in the least useful way possible.

> *we should try to test our design against a number of lower and upper
layer protocols to make sure our thinking is sound.*

As Ben mentioned, we have. The current design has allowed Ledger Layer
implementations to change dramatically without affecting higher levels
(going from on-ledger transfers to trustlines and payment channels). It has
also allowed higher level protocols to change dramatically (going from IPR
to PSK).

On Fri, Aug 18, 2017 at 5:58 PM David Nicol <davidnicol@gmail.com> wrote:

> On Fri, Aug 18, 2017 at 3:07 PM, Adrian Hope-Bailie <adrian@hopebailie.com
> > wrote:
>>
>> Because that's not how you build a protocol stack. A protocol stack is
>> not defined through interfaces. It's defined through layers of data where
>> each layer has a standard packet format with headers carrying data for that
>> layer and encapsulates the data of layer(s) above in the payload.
>>
>
>  Also: defining a protocol stack informs the design of more robust and
> maintainable interfaces. That is, interfaces designed to an explicit
> protocol stack are more maintainable and robust than interfaces designed
> without one.
>
> Hoping my generalities are useful
>
> dln
>
> --

Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
<http:> <http:>