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

["Burleigh, Scott C (US 312B)" <[e-mail]>]

Thanks, Alexey, I think we may be converging somewhat.  Further replies below (***), with some excess text removed.

Scott

-----Original Message-----
From: Alexey Melnikov <[e-mail]> 
Sent: Friday, February 7, 2020 10:02 AM
To: Burleigh, Scott C (US 312B) <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; Fred Templin <[e-mail]>; [e-mail]; [e-mail]; Benjamin Schwartz <[e-mail]>
Subject: Re: [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

Hi Scott,

Thank you for your responses. My replies below:

On Fri, Feb 7, 2020, at 5:19 PM, Burleigh, Scott C (US 312B) wrote:
> Thanks.  Some responses in-line below.
> 
> Scott
> 
> -----Original Message-----
> From: Alexey Melnikov via Datatracker <[e-mail]>
> Sent: Friday, February 7, 2020 6:09 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Fred Templin 
> <[e-mail]>; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: [EXTERNAL] Alexey Melnikov's Discuss on
> draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-dtn-bpbis-22: Discuss
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I am looking forward for this document to be finished and approved as 
> an RFC.
> Before I can recommend this, I have several DISCUSS points and 
> comments that I would like to address:

...

> Below I describe 3 relevant places in the text and suggest some 
> possible ways of addressing my DISCUSS:
> 
> 5.4. Bundle Forwarding
> 
>    Step 2: The bundle protocol agent MUST determine whether or not
>    forwarding is contraindicated (that is, rendered inadvisable) for
>    any of the reasons listed in Figure 4. In particular:
> 
>      . The bundle protocol agent MAY choose either to forward the
>         bundle directly to its destination node(s) (if possible) or to
>         forward the bundle to some other node(s) for further
>         forwarding. The manner in which this decision is made may
>         depend on the scheme name in the destination endpoint ID 
> and/or
> 
> Lack of this information (how node to forward to are discovered) would 
> prevent interoperability. (By comparison, SMTP specification which has 
> somewhat similar design contains information about how next nodes to 
> forward to are selected.)
> 
> 		This information is provided in other documents, such as the CCSDS Schedule-Aware Bundle Routing standard.

Adding a reference here would address my concern about the above paragraph.

	***	Okay, I'll do that.

> 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.

		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.

		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.  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.

		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.

>         on other state but in any case is beyond the scope of this
>         document. If the BPA elects to forward the bundle to some other
>         node(s) for further forwarding but finds it impossible to
>         select any node(s) to forward the bundle to, then forwarding is
>         contraindicated.
> 
>      . Provided the bundle protocol agent succeeded in selecting the
>         node(s) to forward the bundle to, the bundle protocol agent
>         MUST subsequently select the convergence layer adapter(s) whose
>         services will enable the node to send the bundle to those
>         nodes.  The manner in which specific appropriate convergence
>         layer adapters are selected is beyond the scope of this
>         document.
> 
> Similar to the above: lack of description of how convergence layers 
> are discovered (for example this might include discovery using DNS or 
> something
> else) or, alternatively, a mandatory to implement convergence layer 
> would affect interoperability. I think you need to add this as a 
> requirement to section 7 ("Services Required of the Convergence Layer").
> 
> 		Adding a mandatory-to-implement convergence layer adapter in section
> 7 is an excellent idea.
> 		A specification for the TCP convergence-layer adapter is being 
> proposed concurrently with the BPv7 and BPsec specifications.
> 		If the Working Group agrees, we can simply reference that 
> specification in section 7.

Great.

> Also having some (even non normative) information about which 
> convergence layer to select if multiple are available would be useful.
> 
>         If the agent finds it impossible to select any
>         appropriate convergence layer adapter(s) to use in forwarding
>         this bundle, then forwarding is contraindicated.
> 
>    Step 5: When all selected convergence layer adapters have informed
>    the bundle protocol agent that they have concluded their data
>    sending procedures with regard to this bundle, processing may depend
>    on the results of those procedures.  If completion of the data
>    sending procedures by all selected convergence layer adapters has
>    not resulted in successful forwarding of the bundle (an
>    implementation-specific determination that is beyond the scope of
>    this specification), then the bundle protocol agent MAY choose (in
>    an implementation-specific manner, again beyond the scope of this
>    specification) to initiate another attempt to forward the bundle.
> 
> Similar to the above: retries affect interoperability and should be 
> documented as description of a convergence layer document.
> I think you need to add this as a requirement to section 7 ("Services 
> Required of the Convergence Layer").
> 
> 		I think mandating implementation of TCPCL in section 7 would address 
> this issue.

Good.

>    In that event, processing proceeds from Step 4 of Section 5.4.
> 
> 2) As pointed out by Benjamin Schwartz:
> 
> In Section 5.4.2
> 
> Consistency: This section relies on the presence of a Previous Node 
> block, but nothing in the forwarding procedure instructs any agent to 
> add a Previous Node block.
> 
> 		Right, Ben Kaduk pointed this out as well.  Language will be added 
> in version 23 of the draft.
> 
> Correctness: If two nodes both opt to return failed bundles, how are 
> they to avoid a ping-pong loop?
> 
> 		But on what basis would you terminate the ping pong, since on one of 
> those cycles a way out of the loop might appear?
> 		I think the answer is that the bundle lifetime and hop count 
> mechanisms will eventually cause the bundle to be destroyed, stopping 
> the routing loop.

Fair enough. I agree that hop count should be sufficient. So it would be worth pointing this out in the document.

	***	Okay.

> 3) As pointed out by Benjamin Schwartz:
> 
> In Section 5.6
> 
> Error handling: What about CBOR parsing failures?
> 
> 		A CBOR parsing failure would constitute a malformation of the block; 
> Step 3 of 5.6 explains how block malformations are handled.

It was not clear to me that the current text covers this. Step 3 mostly talks about CRC. If the following text was supposed to cover invalid CBOR:

 If any block of the bundle is malformed according to this specification ...

then I suggest you clarify:

 If any block of the bundle is malformed according to this specification (including syntactically invalid CBOR) ...

	***	Sure, I will do that.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

...

> ## 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.  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?
...

> ## Section 5.8
> 
> Clarity: The insistence, here and earlier, that a bundle is only 
> fragmented into two packets, and that this can then be performed 
> recursively, seems unhelpful.  Bundles can be fragmented into 
> arbitrarily many pieces, and this binary subdivision concept is not 
> actually present in the protocol.  I suggest removing it from the text 
> as well.
> 
> 		Why is this unhelpful?  It's the formal procedure by which bundles 
> are fragmented.  Let's not remove it.

I think saying that a bundle can only be fragmented into 2 pieces is a lie, because the algorithm says that it can be fragmented into more than 2. I found this text to be confusing as well. Just say that it can be fragmented into 2 or more non overlapping fragments.

	***	It is absolutely not a lie.  A bundle can be fragmented into exactly 2 pieces, each of which is a bundle.  There is no defined mechanism for fragmenting a single 		bundle into 3 pieces, or 4, other than the recursive exercise of the binary fragmentation mechanism defined in detail in section 5.8.  But I will try to make this 		clearer in the text.

...