Re: Are next claims true about ILP?


Interledger Community Group ‎[public-interledger@w3.org]‎

> I really dislike how we keep saying that ILP "requires" X or Y with
regard to the HTLA or talk about protocol requirements in terms of
implementation details.

IMHO, this is just about pure-abstractions versus pragmatic-abstractions
 on how the RFC describing the protocol must be written.

As I see it, the RFC describing the protocol must be free (actually is encouraged)
 to choose any detail implementation that helps in designing proper working
 implementations (even if such details are not mandated but just suggested).

While it's perfectly possible to describe the protocol just around communication
 semantics, ignoring how the state must be kept in the host (that is, what minimum
 data-structures are expected to be handled by the software implementation)
  makes the job harder for anyone interested in implementing the spec. In practice,
 any software implementation is supposed to keep an internal state-machine
. The state  and time transitions  will be driven by the incomming/outgoing (ILP)
 protocol messages. Ignoring such internal state-machine in the RFC just hurts
 developers interested in implementations with no advantage for anyone else.

A pure abstraction with no hints on implementation details can be great for pure
mathematicians, but I'm not so sure that would be ideal for software developers.

 Taking for example the original TCP RFC,
 the paper is full of references detailing how the host is supposed to implement
 the TCP stack, with state buffers and input/output queues. It could have been
 perfectly possible to ignore such details, but for sure TCP  would have not been
 that much easier to understand and port to different platforms.
Note that actually the RFC does NOT "requires" but actually "imagine" some pieces in
 places on the host.
( Actually those "imagined" pieces exists in 100% of TCP real implementations)

Extracted from https://tools.ietf.org/rfc/rfc793.txt

_____________________________________________________________

      To store this information we imagine that there
      is a data structure called a Transmission Control Block (TCB).
      ...
      Before we can discuss very much about the operation of the TCP we need
      to introduce some detailed terminology. Among the variables stored in
      the TCB are the local and remote socket numbers, the security and
      precedence of the connection, pointers to the user's send and receive
      buffers, pointers to the retransmit queue and to the current segment.
      In addition several variables relating to the send and receive
      sequence numbers are stored in the TCB."""
     ...
      TCPs consume sequence number space each time a segment is formed and
        entered into the network output queue at a source host.
     ...
_____________________________________________________________



Regards,

Enrique


De: Adrian Hope-Bailie [adrian@hopebailie.com]

Enviado: lunes, 28 de agosto de 2017 23:25

Para: Evan Schwartz

CC: Enrique Arizon Benito; Interledger Community Group

Asunto: Re: Are next claims true about ILP?







I really dislike how we keep saying that ILP "requires" X or Y with regard to the HTLA or talk about protocol requirements in terms of implementation details.




For example, I disagree with with 1. ILP does not have any requirements with regards to implementation details like where the HTLA status is kept. If we say ILP requires it be kept in the ledger or connector plugin that is incorrect because those are implementation
 details. ILP only requires that the condition and fulfillment are passed along.




I agree with 2 because that is a functional requirement not an implementation requirement.




I think Enrique is correct regarding 3.2. The protocol has no requirement that connectors use the conditions and fulfillments. An ILP payment will still work if one of the host-to-host transfers in the middle ignores the condition and fulfillment with
 respect to the validity of the transfer and simply passes them on to the next host.







On 25 August 2017 at 06:50, Evan Schwartz
<evan@ripple.com> wrote:


1-3.1 are correct.



3.2 Connectors use conditions and fulfillments even in trustlines. They only update their balance with their peer when they agree that the (valid) fulfillment has been submitted before the timeout.



4 is kind of correct. The current view is that the most important thing to standardize are the protocols that will be used across ILP "Autonomous Systems", and that's more likely to be universal mode than atomic. Atomic is very useful for removing connector
 risk but since it requires commonly trusted parties anyway, it's slightly less important to have widespread standards for how you do it. That said, I think there will be standards for atomic ILP, so if others are interested in working on that we can definitely
 start some discussion about it.





On Fri, Aug 25, 2017 at 3:39 AM Enrique Arizon Benito <enrique.arizon.benito@everis.com>
 wrote:



Hi,



Trying to keep in sync with this long thread "An attempt to clean up the protocol architecture" and the current state of ILP in general, I just would appreciate if someone can correct me about next claims:



1. During the payment process, ILP requires to keep the current HTLA status in a ledger (using the escrow).



  1.1 If the ledger does not support HTLA this status must be kept in the connector plugin.



2. During the payment process, fulfillments and errors must be returned through the same payment path that initiated the payment (same set of  connectors/ledger) forcing to keep an status on each connector mapping incomming to outgoing transfers.



3. For  trust-lines, connectors can connect without a "real" intermediate  ledger, but they will still use a plugin that certainly will act as a virtual ledger to keep balances.



  3.1 That means a ledger always exists, either real or virtual.



  3.2 For trust-lines, connectors are allowed to ignore conditions/fulfillments but must still forward them.



4. There is no support for atomic mode in ILP, but can be build in a non-standard (non-ILP-defined) way on-top of it using for example an external arbiter for all connectors in the payment proccess.



Regards,



Enrique



________________________________



AVISO DE CONFIDENCIALIDAD.

Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción
 o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.



CONFIDENTIALITY WARNING.

This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction
 or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.






--




Evan Schwartz






Software Engineer
Managing Director of Ripple Luxembourg




















________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.

Received on Tuesday, 29 August 2017 13:33:15 UTC