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, responses in-line below.

Scott

-----Original Message-----
From: Alexey Melnikov <[e-mail]> 
Sent: Thursday, February 20, 2020 3:47 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,

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

 [snip]

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

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

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

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

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