Re: [dtn] AMA question and DTN Data Mules

[Carlo Caini <[e-mail]>]

Dear Bryce,
     This is a partial answer, which aim to clarify only a subset of the questions you have raised.
First, let me thank you for your interest in DTNbox, whichu you have correctly referenced. I can only add for the interewsted readers that an extended version of the IEEE coference paper can be freely downloaded from
https://www.mdpi.com/1999-5903/11/8/173
Moving to status reports, you should consider that, although very useful, they are only informative bundles, like e-mail sent by a courier (or Amazon) to inform you about the state of your parcel.
They are issued if the source request them, by setting the corresponding flags in the primary bundle block. DTN nodes can fulfill this request, or not, at their discretion. They are sent to the "report to" (alias "reply to" in DTN2) address, which does not necessarily coincides with the source node. E.g. it is extremely useful in test to collect SRs on a specifically devoted node, acting as a monitor node. This may be accomplished for example by running an instance of DTNperf (--monitor mode), another application of DTNsuite, on the "report to" node. This way, you can have the full telemetry of your experiment in a .csv file. You can also follow your experiment in real time, which is useful to immediately intercept problems (e.g. lack of connectivity between nodes to to errors in configuration files, etc.), saving a lot of time for trivial problems. 
Alternatively, you can send them to the BP agent itself, e.g. by using the demux number 0 in the ipn scheme, such as in "ipn:128.0". In this case, at least in ION, the content of the BP status report is inserted in the ion.log. 

Although it is technically possible, I would not rely on SRs to trigger retranmissions form the source or things like this, for the following reasons (lesson learned with DTNperf v2.0, which relyed on SR delivered status report sent by the BP running on the server node to let the client know that the bundle sent to the server was delivered):
1) if you want to use the SR this way, you are obliged to set the "report to" the same as the source node, which prevents you from collecting all other SRs on different nodes. This may be very annoying, it is much easier and faster to sollect SRs on the destination node, or in a devoted monitor node, than on the source, because of intermittent connectivity.
2) It is preferable that the application on the source node be confirmed by its peer at the same layer, i.e. the corresponding application on the destination node. The current DTNperf version, 3.x, works this way.   

That said, a few quick answers to your questions:
Q1: An SR destined to a BP agent is read by the BP agent, which may include the content on a log (if it likes, I suppose). I think that no other actions should be triggered, being the bundle purely informative. 
Q2: The BP agent should never delete anything on the basis of an SR, in particular if not destined to it, for the same reason as before.
Q3: Duplicate bundles may be delivered to the application. The BP does not prevent this from happening. It is matter of the client-server application to cope with possible duplicate bundles. Note that a bundle sent twice by the source is easily distinguishable from duplicate copies, as it would have a different timestamp (eother time or seqaunce numbewr or both).
Q4: What do you mean for with "when loops form"? Could you exapnd a little your question? Loops are a routing matter, nothing to doi with SRs.

I fully agree with you on the possible use of smartphones as data mules. I carried out a few experiments in 2009 (many years ago!), after reading an interview to Vint Cerf, when the Nokia N900, running Maemo OS was released. It was easy to install DTN2 on it, and in fact I used it as a data mule. Unfortunately, Linux phones faded away (as Nokia...), and this possibility became more difficult. There were several attempt of bringing BP on Android, among which IBR-DTN for Android (you can easily install and test it on your smartphone). However, the reliability as never been the same as that of BP implementations for Linux. This is why we aborted, after many efforts (euphemism) the DTNbox version for Android, running on top of IBR-DTN for Android.

I hope of having at least partially managed to clarify your doubts!
Yours, 
   carlo


________________________________________
Da: dtn [[e-mail]] per conto di Nordgren, Bryce -FS [bryce.l.nordgren=[e-mail]]
Inviato: mercoledì 14 aprile 2021 19:17
A: Wesley Eddy; [e-mail]
Oggetto: Re: [dtn] AMA question and DTN Data Mules

I believe my monologue was unclear on at least one point. I was not thinking to use USB sticks to manually sync directories. I envisioned the task of sync'ing directories being implemented as the BP application "DTNbox" (https://ieeexplore.ieee.org/abstract/document/8734214), (https://gitlab.com/dtnsuite/dtnbox).

The task of moving BP bundles via a mass storage convergence layer apparently has (an old, unmaintained) implementation. Wesley told me DTN2 had a file convergence layer but it is marked as "do not use" since either 2009 or 2012, depending on date formatting. It does seem to me that in terrestrial challenged networks, USB sticks and smart phones will probably be the most common link between sites not having internet connectivity. Hence worth standardizing.

A closer read of draft-ietf-dtn-bpbis v 31 leaves me a bit confused as to what happens:

  *   ...when a DTN node/BP agent receives a "bundle status report" destined for itself. It shouldn't get delivered, so does it just eat it? Does it notify the requesting app of bundle delivery (or more importantly, failure to deliver the bundle?) Does it try to retransmit on failures...or certain failures (relay N ran out of storage space)? Some of these actions can be configuration items, but some things really should be consistent. ("Hey App, your last message didn't get thru...")
  *   ...when a DTN node/BP agent receives a "bundle status report" (delivery receipt/reason code "no additional information") destined for someone else, but referring to a bundle it is currently storing. Can it/must it/should it delete the copy of the bundle it is storing?
  *   ...when a DTN node/BP agent receives a duplicate bundle. Is it even required to check whether it's received the bundle before? How can the app differentiate between duplicate delivery and the same message actually sent twice?
  *   ...when loops form...

A common architecture pattern potentially worth expressing "informationally" for terrestrial challenged networks may be that mobile relays (DTN nodes) travel between disconnected LANs. This suggests to me a couple of things:

  *   The option to be chattier should exist. Mobile nodes should be able to sync up with each other and with fixed nodes when there's N of them connected on a LAN and none of them knows which will travel to a different LAN next. Talk on a LAN or bluetooth link is cheap. Storage is also pretty cheap.
  *   Perhaps an XMPP or PEP convergence layer is the more natural way to handle "mobile nodes popping up on a LAN to deliver bundles to whatever other nodes are connected." Also handles the situation where a mobile node squats on a LAN for most of the day till it's human needs to travel to a different LAN-supported-area.--The phone is always "ready to go, fully loaded with current bundles".

I'm sorry if some of this is just stuff I haven't wrapped my head around yet. Please point out incomplete or erroneous thinking to me.

Thanks,
Bryce



________________________________
From: Wesley Eddy <[e-mail]>
Sent: Wednesday, April 14, 2021 6:53 AM
To: Nordgren, Bryce -FS <[e-mail]>
Subject: Re: [dtn] AMA question and DTN Data Mules


It's been a long time (like 15 years), but the file-based convergence layer adapter in the DTN2 software has been used to do something similar to what you say with removable USB-stick storage.


I think there are interesting distinctions though (and don't know about your use case) between sync'ing distributed copies of file stores or sync'ing or importing updated data tables in a distributed database that partitions frequently, versus sending bundles between DTN applications.  I think the bundle sending/receiving is a more primitive operation, and still requires other significant application intelligence above to satisfy the use case, as I understand it.



On 4/13/2021 5:23 PM, Nordgren, Bryce -FS wrote:
Tangent: on cursory inspection, draft-ietf-dtn-ama-01 seems unnecessarily limited to "network management", since nearly all the concepts seem applicable to management of any distributed application operating across challenged links. The draft would seem to describe the case of an "Autonomous Parameterized Procedure Call" commanding a remote Kubernetes cluster to roll out a new deployment of some app to a local network on the other end of a challenged link--except it seems to be focused on network management.

A conceptual piece that may be missing from AMA is synchronized data, or data that should be eventually consistent across application instances present at multiple nodes, where each serves users local to their own node (to offer better response times or conserve bandwidth). Data such as the collection of "users" of the app (Who Are The Actors? Who Are The Managers? Did Someone Get Fired? Is There A New Guy? Did User A Change Her Password?). It may not be appropriate to specify a particular method to pursue consistency, but defining the syncronized data type and its binding to a set of endpoints may be useful. Also, and I haven't read closely enough to understand if this is a problem...Actors and Managers in terrestrial networks may access the network from different nodes, and user generated content (even if it's just a state change due to their interaction) may be supplied from any node. The draft doesn't actually define permissible management operations on individual DTN nodes, so is there a reason to limit these generic concepts to "network management"?

The meat: during the development of the DTN concept, has there been any thought to the use of "dumb media" to connect isolated network islands?

Use Case: An Incident Management Team (IMT) splits some of its essential functions between an Incident Command Post (ICP), chosen for connectivity reasons; and a Forward Operating Base (FOB), chosen for proximity to the fire/earthquake/disaster. The current communication flows between locations may include paper forms or electronic files shared via flash drives.

Deployment scenario: Two "fixed" DTN nodes are set up, one at each location, running a DTN app like 'DTNbox' to sync one or more directories between the two. They also participate on a local network at each facility (where the FOB does not have internet connectivity) and run a webserver. The webserver allows end users to view or download published data (such as the day's Incident Action Plan or maps), as well as upload admin info, like electronic time cards and COVID screenings.

Writing an app to make a smartphone into a "mobile" node (data mule) seems a conceptually straightforward thing to do. This is because a smartphone is smart, and can act like a DTN node that's doggedly trying to join WiFi and pester whatever "fixed" nodes it finds. However, it requires that users install something on their phone, which is likely forbidden if it's an agency phone.

My question is: Is there a spec or a strategy regarding how to dump bundles which need to be moved between nodes to "dumb" media, like a flash drive or a USB hard drive? Someone then carries the dumb media from place to place, plugging it into the DTN node when they arrive. Seems like an on-media structure would need to be developed so nodes could add what they need to transmit and consume bundles destined for them. And since there's no guarantee that two nodes are running the same DTN implementation, it seems that the structure (and allowable operations on said structure) would need to be standardized. Would this be a "mass storage" convergence layer in your parlance?

Has this come up before, and is it dumb?

Thanks,
Bryce




This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.


_______________________________________________
dtn mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dtn<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn&data=04%7C01%7C%7C69e4c719f98947d32c0c08d8ff444c30%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637540016090763975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=QKnAA%2FfD2qHT2AHNOaa1gKgBoImkWm6AmBr4zK6oG78%3D&reserved=0>