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

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Fri, 07 Feb 2020 06:08:45 -0800

Alexey Melnikov has entered the following ballot position for
draft-ietf-dtn-bpbis-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/

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

1) Routing decisions, discovery of endpoints to contact for forwarding and
retry strategies are listed as out-of-scope for this document. This is not
sufficient for writing an interoperable implementation, unless there is a
separate document that provides such details. 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.)

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

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

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

   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.

Correctness: If two nodes both opt to return failed bundles, how are they to
avoid a ping-pong loop?

3) As pointed out by Benjamin Schwartz:

In Section 5.6

Error handling: What about CBOR parsing failures?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly *
* about perceived successes or failures of this experiment.          *
**********************************************************************

I also have some comments on Benjamin's comments below marked with "[[Alexey]]:"

The following comments were provided by Benjamin Schwartz <[email-masked]>:

Benjamin would have balloted *DISCUSS* on this document. He wrote:
This draft’s content seems sound but the text is difficult to understand and
needs some editorial improvements.

## Abstract

Nit: Abstract should be before status.
Nit: “specification for Bundle Protocol” -> “for the Bundle Protocol”.

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

## Section 4.1.3

Nit: It would be clearer to move the reserved and unassigned flags to an IANA
considerations section, here and throughout.

## Section 4

Phrasing: “The last item of the array ... SHALL be a CBOR "break" stop code.”
 This seems like a misuse of the word “item”.  I would suggest “The array SHALL
be terminated by a CBOR “break” stop code.”  Similarly in Section 4.2.1.

## Section 4.1.4

Clarity: The “(Boolean)” specifiers seem redundant.  What is a non-boolean flag?

Clarity: The two lists here seem redundant.  Can they be collapsed?

Clarity: The phrasing “...the value of the "Transmit status report if block
can't be processed" flag in every canonical block…” suggests that these flags
should be named or numbered before attempting to describe them.

## Section 4.1.5.1

These two sentences seem contradictory:

* “Any scheme conforming to [URIREG] may be used in a bundle protocol endpoint
ID.” * “The first item of the array SHALL be the code number identifying the
endpoint's URI scheme [URI], as defined in the registry of URI scheme code
numbers”

Please rephrase.

[[Alexey]]: This is similar to Roman's DISCUSS.

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

Correctness: If two nodes both opt to return failed bundles, how are they to
avoid a ping-pong loop?

[[Alexey]]: I included these in the DISCUSS portion of my ballot.

##Section 5.6

Error handling: What about CBOR parsing failures?

[[Alexey]]: I included these in the DISCUSS portion of my ballot.

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

## Section 6.1

Formatting: This table is excessive for a single value.

Clarity: The text specifies the contents twice, which is unhelpful for
comprehension.

## Section 10

Formatting: The extra line breaks in the vertical dividers are distracting. 
Please fill them in or remove the breaks if possible.

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 7 Feb 2020 17:19:53 +0000

Thanks.  Some responses in-line below.

Scott

-----Original Message-----
From: Alexey Melnikov via Datatracker <[email-masked]> 
Sent: Friday, February 7, 2020 6:09 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; Fred Templin <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

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:

1) Routing decisions, discovery of endpoints to contact for forwarding and retry strategies are listed as out-of-scope for this document. This is not sufficient for writing an interoperable implementation, unless there is a separate document that provides such details.

**********
	(From my February 6 , 8:56 AM response)

Absolutely, we anticipate that over time a wide variety of strategies for topology discovery and route selection will be developed to support BP forwarding in a variety of operational scenarios.  Most implementations to date have simply used static routing tables, just to enable interoperability testing.  One published standard for BP routing does exist, but it's not yet an IETF standard: the Schedule-Aware Bundle Routing "Blue Book" published by the Consultative Committee for Space Data Systems (https://public.ccsds.org/Pubs/734x3b1.pdf) is currently in operational use on-board the International Space Station.  SABR was developed in the context of version 6 of the Bundle Protocol, not the current draft, but it is equally applicable to BPv7 since the representation of endpoint IDs has not changed.

BP typically relies on the retry strategies of the transport ("convergence layer") protocols it runs over, in hop-by-hop fashion, as end-to-end retransmission is suboptimal in a delay-tolerant network.  One element of retry strategy that is identified in the BP draft, though, is this: as noted in Step 5 of section 5.4, failure in transmission at the convergence layer may cause the bundle protocol agent to initiate another attempt to forward the bundle, possibly using a different route and/or different transport protocol.

In addition, a "custody transfer" mechanism for retry at the bundle layer itself is defined in the Bundle-in-Bundle Encapsulation protocol specification, a separate Internet Draft that we hope to advance to IESG review soon.  (The most recent edition of that draft expired a couple of days ago, and I haven't yet had time to re-post it.)

As noted in section 8, three implementations of BPv7 have been announced to date, and two of those implementations -- PyDTN and uPCN -- have been shown to be interoperable.

**********

Below I describe 3 relevant places in the text and suggest some possible ways of addressing my DISCUSS:

5.4. Bundle Forwarding

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.

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?

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.

Also having some (even non normative) information about which convergence layer to select if multiple are available would be useful.

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.

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.

In Section 5.6

		A CBOR parsing failure would constitute a malformation of the block; Step 3 of 5.6 explains how block malformations are handled.

Benjamin would have balloted *DISCUSS* on this document. He wrote:
This draft’s content seems sound but the text is difficult to understand and needs some editorial improvements.

## Abstract

		The document was prepared using Joe Touch's  2-Word-v2.0.template.dot, and it passes the idnits check. 

		Sure.

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

## Section 4.1.3

Nit: It would be clearer to move the reserved and unassigned flags to an IANA considerations section, here and throughout.

		They appear in the IANA considerations section as well.

## Section 4

Phrasing: “The last item of the array ... SHALL be a CBOR "break" stop code.”
 This seems like a misuse of the word “item”.  I would suggest “The array SHALL be terminated by a CBOR “break” stop code.”  Similarly in Section 4.2.1.

		Good catch, will fix this.

## Section 4.1.4

		Okay.

Clarity: The phrasing “...the value of the "Transmit status report if block can't be processed" flag in every canonical block…” suggests that these flags should be named or numbered before attempting to describe them.

## Section 4.1.5.1

* “Any scheme conforming to [URIREG] may be used in a bundle protocol endpoint ID.” * “The first item of the array SHALL be the code number identifying the endpoint's URI scheme [URI], as defined in the registry of URI scheme code numbers”

Please rephrase.

		Other reviewers have remarked on this as well; revision will appear in version 23 of the draft.

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

		Yes, will be addressed in version 23.

Correctness: If two nodes both opt to return failed bundles, how are they to avoid a ping-pong loop?

		Please see my response to the DISCUSS item.

##Section 5.6

		Please see my response to the DISCUSS item.

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

## Section 6.1

		We anticipate additional values in the future.  Let's have the table.

Clarity: The text specifies the contents twice, which is unhelpful for comprehension.

		I think it's actually helpful.  The 3-line overview introduces the concept of an administrative record and the last 3 paragraphs mandate the representation.

## Section 10

Formatting: The extra line breaks in the vertical dividers are distracting. Please fill them in or remove the breaks if possible.

		I am hoping this is something that the RFC editors handle.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Fri, 07 Feb 2020 18:01:41 +0000

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:
> Cc: [email-masked]; Fred Templin 
> <[email-masked]>; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: [EXTERNAL] Alexey Melnikov's Discuss on 
> draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)
> 
> 1) Routing decisions, discovery of endpoints to contact for forwarding 
> and retry strategies are listed as out-of-scope for this document. This 
> is not sufficient for writing an interoperable implementation, unless 
> there is a separate document that provides such details.
> 
> **********
> Absolutely, we anticipate that over time a wide variety of strategies 
> for topology discovery and route selection will be developed to support 
> BP forwarding in a variety of operational scenarios.  Most 
> implementations to date have simply used static routing tables, just to 
> enable interoperability testing.  One published standard for BP routing 
> does exist, but it's not yet an IETF standard: the Schedule-Aware 
> Bundle Routing "Blue Book" published by the Consultative Committee for 
> Space Data Systems (https://public.ccsds.org/Pubs/734x3b1.pdf) is 
> currently in operational use on-board the International Space Station.  
> SABR was developed in the context of version 6 of the Bundle Protocol, 
> not the current draft, but it is equally applicable to BPv7 since the 
> representation of endpoint IDs has not changed.
> 
> BP typically relies on the retry strategies of the transport 
> ("convergence layer") protocols it runs over, in hop-by-hop fashion, as 
> end-to-end retransmission is suboptimal in a delay-tolerant network.  
> One element of retry strategy that is identified in the BP draft, 
> though, is this: as noted in Step 5 of section 5.4, failure in 
> transmission at the convergence layer may cause the bundle protocol 
> agent to initiate another attempt to forward the bundle, possibly using 
> a different route and/or different transport protocol.
> 
> In addition, a "custody transfer" mechanism for retry at the bundle 
> layer itself is defined in the Bundle-in-Bundle Encapsulation protocol 
> specification, a separate Internet Draft that we hope to advance to 
> IESG review soon.  (The most recent edition of that draft expired a 
> couple of days ago, and I haven't yet had time to re-post it.)
> 
> As noted in section 8, three implementations of BPv7 have been 
> announced to date, and two of those implementations -- PyDTN and uPCN 
> -- have been shown to be interoperable.
> 
> **********
> 
> 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.)
> 

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

> requirement there. (If you already have a document that does this, you 
> can just normatively point to it.)
> 
> 		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?

> 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").
> 
> 		A specification for the TCP convergence-layer adapter is being 
> proposed concurrently with the BPv7 and BPsec specifications.

Great.

> Also having some (even non normative) information about which 
> convergence layer to select if multiple are available would be useful.
> 
> Similar to the above: retries affect interoperability and should be 
> documented as description of a convergence layer document.

Good.

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

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

> This draft’s content seems sound but the text is difficult to 
> understand and needs some editorial improvements.
> 
> ## Abstract
> 
> 		The document was prepared using Joe Touch's  
> 2-Word-v2.0.template.dot, and it passes the idnits check. 

I wouldn't worry too much about this, this can be handled by RFC Editor. I just wanted to include Benjamin's comments pretty much verbatim.

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

> ## Section 4.1.3
> 
> Nit: It would be clearer to move the reserved and unassigned flags to 
> an IANA considerations section, here and throughout.
> 
>  This seems like a misuse of the word “item”.  I would suggest “The 
> array SHALL be terminated by a CBOR “break” stop code.”  Similarly in 
> Section 4.2.1.
> 
> Clarity: The phrasing “...the value of the "Transmit status report if 
> block can't be processed" flag in every canonical block…” suggests that 
> these flags should be named or numbered before attempting to describe 
> them.
> 
> ## Section 4.1.5.1
> 
> * “Any scheme conforming to [URIREG] may be used in a bundle protocol 
> endpoint ID.” * “The first item of the array SHALL be the code number 
> identifying the endpoint's URI scheme [URI], as defined in the registry 
> of URI scheme code numbers”
> 
> Please rephrase.
> 
> 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.
> 
> 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.
> 

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.

> 		I think it's actually helpful.  The 3-line overview introduces the 
> concept of an administrative record and the last 3 paragraphs mandate 
> the representation.

Ok.

> ## Section 10
> 
> Formatting: The extra line breaks in the vertical dividers are 
> distracting. Please fill them in or remove the breaks if possible.
> 

Ok.

Best Regards,
Alexey

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 7 Feb 2020 13:33:11 -0500

> worth pointing this out in the document.

I'm still concerned with this type of solution.  This tight loop situation
is a problem that is likely to happen often in some applications, creating
serious inefficiencies when bundle lifetimes are large.  A more efficient
solution could be straightforward, e.g. don't update the "Previous Node"
block when returning the bundle on failure.  Then receipt of a block with
Previous Node == my Node ID indicates that this is not an ordinary
forward-routed bundle, and I can choose to drop this bundle instead of
continuing to route it.

A more explicit indication of return-on-failure would probably be even
better.

More generally, this is an example of how this draft's scope of intended
applications is hard to understand.  The Bundle Protocol makes some
assumptions about the topology and dynamics of its routing layer, but those
requirements are not made explicit anywhere, and the protocol is presented
as suitable for DTN applications universally.  For example, the behavior of
concern here would make Bundle extremely inefficient on large tree-shaped
networks.

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

The text on fragmentation in RFC 791 seems reasonably clear, and might be a
good basis for this description.

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Sat, 8 Feb 2020 00:45:24 +0000

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

Scott

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

Hi Scott,

> draft-ietf-dtn-bpbis-22: Discuss

...

	***	Okay, I'll do that.

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.

> Similar to the above: lack of description of how convergence layers 
> are discovered (for example this might include discovery using DNS or 
> something

Great.

Good.

	***	Okay.

	***	Sure, I will do that.

...

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

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

...

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 10 Feb 2020 11:39:04 +0000

Hi Scott,
Quickly replying to a single issue:

On Sat, Feb 8, 2020, at 12:45 AM, Burleigh, Scott C (US 312B) wrote:
> 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.

Think of it from the point of view of a receiving system: if there were several nodes before it, it can't rely on only being 2 fragments, it has to expect arbitrary number of them.

So the text you have is possibly helpful for the sending system, but not for the receiving one.

Best Regards,
Alexey

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Mon, 10 Feb 2020 17:08:13 +0000

Thanks, Alexey.  I would expect an implementer who is coding section 5.9 of the spec would normally read section 5.8 as well, but maybe not.  I will gladly add some clarifying text in the Reassembly section as well.

Scott

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

Hi Scott,

On Sat, Feb 8, 2020, at 12:45 AM, Burleigh, Scott C (US 312B) wrote:
> > actually present in the protocol.  I suggest removing it from the 
> > text as well.
> > 
> 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.
> 

Best Regards,
Alexey

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 20 Feb 2020 11:46:50 +0000

Hi Scott,

 [snip]

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

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]

> b) another system always retries once and only once. Again, as you 
> don't specify that it is illegal, it is legal.
> 
> 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

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 20 Feb 2020 15:52:21 +0000

Thanks, Alexey, responses in-line below.

Scott

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

Hi Scott,

 [snip]

>> SMTP server	on Mars and SMTP itself does not run over BP.  My bundle will be 
>> have to convey the bundle to that server somehow.  To do so, I need to forward the 

Well, just as there is no SMTP server on Mars, there might not be a DNS server on Mars.  (In fact, the cost of DNS transfers over interplanetary communication links was one of the considerations that motivated development of new protocols.)

But certainly there has to be *some* mechanism on Mars that is able to look at the destination EID of this bundle and use it to determine that the initial waypoint for the bundle is an intermediary node that can gateway to the space network.  That mechanism might be some sort of private DNS or it might be something else TBD, but whatever that mechanism is, clearly it needs to be fully explained in the document that defines the manner in which the URIs formed in that scheme are used as BP endpoint IDs.

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

Exactly.

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

There definitely are going to be future documents produced by the WG.

 [snip]

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

Can we say in this specification that the minimum number of times the node will attempt to re-forward a bundle upon convergence-layer protocol failure is a node configuration parameter that must be exposed to all other nodes in the network as required?

My concern is that in some DTN environments the nodes (IoT sensors, maybe) might be so resource-constrained that they can't afford to retry a failed transmission even once - they just "fire and forget".