Re: [dtn] [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

["Alexey Melnikov" <[e-mail]>]

Hi Scott,

On Sat, Feb 8, 2020, at 12:45 AM, Burleigh, Scott C (US 312B) wrote:

 [snip]

> > I think you need to create a new section in this document specifying 
> > requirements on URI scheme documents and include this as a MUST level 
> > requirement there. (If you already have a document that does this, you 
> > can just normatively point to it.)
> > 
> > 		Can you please explain what you mean by "requirements on URI scheme 
> > documents"?
> > 		I don't know of any requirements on URI scheme documents that are 
> > implied by this specification.  Can you give an example?
> 
> When a new URI scheme is registered for use with DTN (to get a new 
> scheme specific number), a document describing this registration needs 
> to be written. Let's imagine that I want to use "mailto:" URIs with 
> DTN. In the document describing use of mailto: with DTN I would 
> describe how routing is going to be performed. This might be something 
> like this:
> 
>    When "mailto:" URIs are used with BPv7, SMTP protocol [RFC 5321] 
> would be used for convergence layer. Location of the next node is done 
> by using standard SMTP mechanism which is use of MX DNS records on the 
> domain extracted from the right hand side of mailto: address.
> 
> (The above text happens to cover both routing and discovery of a next 
> node to forward to by referencing SMTP.)
> 
> 
> So the section with requirements on use of URI schemes with DTN would 
> have something like:
> 
> When registering a new URI scheme with BPv7, the document registering 
> the URI scheme MUST describe how URIs are used for next forwarding node 
> location discovery. Such document MUST also define whether the URI 
> scheme depends on any specific convergence layer(s).
> 
> Does this help?
> 
> 	***	Thanks, I think I understand what you mean.  My original thought 
> was that the URI-scheme-specific information that needed to be captured 
> was limited
> 		to CBOR representation rules, which I figured could simply be 
> included in the entries of the BP URI Scheme Type registry.  What 
> you're talking about
> 		here is additional URI-scheme-specific information.
> 
> 		From that perspective, it sounds like each entry in the BP URI Scheme 
> Type registry needs two references: one to the document that the 
> defines the URI
> 		scheme itself and a second reference to a document that defines the 
> manner in which the URIs formed in that scheme are used as BP endpoint 
> IDs: how
> 		such an endpoint ID must be represented in transmission (CBOR), what 
> convergence-layer protocol(s) may be used to forward a bundle to a BP 
> destination
> 		endpoint identified by such an ID, and how the ID of the 
> convergence-layer protocol endpoint to use for that purpose can be 
> inferred from that destination 			endpoint ID.

Exactly.

> 		Note, though, that in the general case the next BP node to forward to 
> -- in a multi-hop path to the final destination node -- cannot be 
> inferred from the
> 		destination EID.  Nor can the convergence-layer protocol that should 
> be used to forward the bundle to that BP node.  This is the "late 
> binding" concept that
> 		has been fundamental to the DTN architecture from the beginning.

To continue my mailto/SMTP example: it has exactly the same properties and the rules to discover the next hop are done by each intermediate note at the time a relay/delivery attempt is made.

> 		Taking up your example: suppose I am on Mars and I want to use BP to 
> send an email.  My destination EID is a "mailto:" URI, but there is no 
> SMTP server
> 		on Mars and SMTP itself does not run over BP.  My bundle will be 
> forwarded to its final destination by an SMTP server on Earth, but I 
> have to convey the
> 		bundle to that server somehow.  To do so, I need to forward the 
> bundle to a relay node that uses two convergence-layer protocols: SMTP, 
> for forwarding 			"mailto:" bundles to SMTP servers (acting as an SMTP 
> client), and some protocol stack that operates over the space network 
> (BP over LTP over encapsulation 			packets, for example), for receiving 
> bundles forwarded from Mars.

This is perfectly fine. In this example you would use DNS MX records (mechanism used by SMTP) to get a bundle to an intermediary node that can gateway (possibly rewriting mailto: URI into another URI scheme in the process) to the space network.

> I need to use that space network stack to 
> get the bundle to the relay node, and the 				destination EID doesn't 
> tell me how to do that.

The destination EID might tell you how to get to a relay node that knows how to gateway to another transport. EID doesn't have to describe the destination node, just a node that knows what to do with a bundle.

> 		Mechanisms for route selection and convergence-layer protocol 
> selection in DTN are going to be developed in multiple companion 
> specifications as DTN is 			deployed in new environments and new 
> requirements emerge.  Appealing as it would be to nail these things 
> down in this specification somehow, we cannot.

I think my problem with the current document is that it is not sufficient to implement complete system. If these are future documents to be produced by the WG, that would be Ok with me.


 [snip]

> > ## Section 1
> > 
> > Title: If this document doesn’t describe the operation, routing, or 
> > management of bundles, maybe it doesn’t describe a complete protocol.
> > Consider retitling to “Bundle Protocol Version 7: Format and 
> > Architecture”
> > 
> > [[Alexey]]: This relates to my DISCUSS points, but my DISCUSS position 
> > is stronger than this statement.
> > 
> > 		Please see my response to the DISCUSS position.
> > 		I would note that RFC 791 doesn't include procedures for making 
> > routing decisions (absent source routing) or retrying transmissions.
> 
> But there are other documents that do. They are required to implement 
> an interoperable system.
> 
> To give you an example of why specifying retry behaviour is important:
> 
> a) one system implements no retries. As you don't specify that it is 
> illegal, it is legal.
> b) another system always retries once and only once. Again, as you 
> don't specify that it is illegal, it is legal.
> 
> Systems a) and b) are not going to be interoperable.
> 
> I don't think you need to require a specific number of retries, but 
> maybe specify that at least N retries should be attempted (unless the 
> bundle expires before that) and maybe specify some minimum time period 
> for retries.
> 
> 	***	I disagree.  Systems (a) and (b) will interoperate; they will just 
> exhibit different performance characteristics.

No, if one node doesn't retry, it degrades the whole service, because no sender can rely on nodes retrying.

>  Why don't we let 
> network operators make
> 		these kinds of decisions, based on the specific conditions under 
> which their nodes run, rather than try to decide everything for them in 
> this specification?
> ...

I am not saying that this information need to be specified in this document, but some document needs to specify this. And having minimum requirements (e.g. "MUST retry 3 times, unless the bundle expires before that") on all implementation would improve interoperability.

Best Regards,
Alexey