search

interledger / rfcs

Specifications for Interledger and related protocols
https://interledger.org
Other
454 stars 111 forks source link

Clarify STREAM Connection Details Functionality #573

Closed sappenin closed 4 years ago

sappenin commented 4 years ago

This PR clarifies STREAM functionality by tightening the language related to ConnectionAssetDetails and ConnectionNewAddress frames.

Specifically:

  1. ConnectionNewAddress is useful for a receiver that wants to change its ILP address or for a client that wants to become a receiver. Therefore:
    1. ConnectionNewAddress Frame is optional, and can be sent at any time (e.g., a non-routable sender shouldn't send it unless it has other reasons to send it -- see below).
    2. A client only emits a ConnectionNewAddress once it wants to enable the receiver to start sending to it (this generally happens near the beginning of a Connection, but doesn't have to).
    3. A receiver (i.e., a client or server playing that role) emits a ConnectionNewAddress frame if it needs to migrate the connection.
  2. Info in ConnectionAssetDetails is typically only used by senders, and only when the sender needs to verify the amount received on a path. Therefore, a sender doesn’t generally emit this frame (the receiver does).

Signed-off-by: sappenin sappenin@gmail.com

sappenin commented 4 years ago

I met with @kincaidoneil and @nhartner and we reached a rough consensus around how to clarify the verbiage in this RFC (i.e., what should be in this PR). Those PR changes have been made and this PR is ready to be reviewed.

We also discovered that there is lack-of-consensus around one commonly-deployed STREAM topology. That is, in the case where the client is the sender, and is non-routable (i.e., "send only") how should the client expect to get a ConnectionAssetDetails from the server/receiver (see below for more details)?

For now, here's what we agreed to:

  1. Clarification to RFC-29
    1. See PR description above.
  2. JS Sender/Receiver Changes
    1. Receiver: Don’t close stream when receiver’s rate probe fails.
    2. Receiver: Don’t close stream when data-reporting back to the client fails
    3. Backward Compatibility: JS client send a CNA with empty ILP address.
  3. Java Sender/Receiver Changes
    1. StreamCore: Make ConnectionNewAddress frame allow an empty address.
    2. StatelessReceiver: If you get a ConnectionNewAddress frame, even with an empty address, always respond with a ConnectionAssetDetails (and sometimes CNA will have empty address).

**Question: How does a client-sender tell the receiver server to send it a ConnectionAssetDetails frame?

No consensus. Some people think, “get it from a higher layer protocol” and some people think “get it from the receiver somehow by allowing the client to 'trigger' the frame somehow" -- implementations support both, and triggering a CAD is done by sending a CNA frame until you get back a CAD.

Nobody really likes the current state of affairs, because the spec is silent which makes for ambiguity. We identified that if the future state of the world is, "STREAM should allow a client-sender to "request" a ConnectionAssetDetails", then we should change the RFC. However, if the future state of the world is that ConnectionAssetDetails are only obtained from higher-layer protocols, then the RFC should be silent here because nobody will get ConnectionAssetDetails in this manner.

This probably deserves more community weigh-in, but for now all implementations use the CNA/CAD dance, which is OK in the short term.