Re: [dtn] draft-blanchet-dtn-email-over-bp-00.txt

[Marc Blanchet <[e-mail]>]

> Le 20 janv. 2023 à 12:14, Stuart W. Card <[e-mail]> a écrit :
> 
> Marc et al --
> 
> Yes please, pursue email/BP!
> 
> I am a big fan of these 3 related but distinct things:
> 
> - email encapsulation over BP;
> - BP encapsulation over email;
> - email <-> BP translational gateways.
> 
> Before BP, we developed a mostly transparent gateway that provided DTN services to legacy applications for the U.S. Navy submarine force.

Thanks for the papers. Will read thoroughly.  Have a question, for BSMTP, you were encapsulating RFC2442? Which implementation have you used for BSMTP?

Regards, Marc.


> I tried to summarize that work in a post 2004 JAN 22 to what was then the DTN Research Group mailing list, with subject line
> 'lurker describes related work (was: DTN "Community Rapporteurs"?)',
> which can be found in the archive at
> https://mailarchive.ietf.org/arch/browse/dtn-interest/
> I am amused to see that the day after tomorrow, it will have been exactly 19 years since I posted that. ;-/
> Attached are 2 papers we presented at MILCOM later in 2004 and a PowerPoint presentation from 2003 when we were still working on automatic rule-based prioritization of traffic (I will have to ask our marketing guy to look for a block diagram of its final configuration).
> 
> Our [non-real-time web browsing proxy over] email stack on the SATCOM segment was something like this (from my hazy memory):
> 
> [HTTP]
> PBS
> BSMTP
> bzip2
> GnuPG
> MDPv2
> UDP
> IPv4 multicast
> 
> I can't find GnuPG/OpenPGP in the block diagram but am sure it was there (eventually, in some version), between compression and bundle transport.
> 
> Of course, later we replaced the Naval Research Lab (NRL) Multicast Dissemination Protocol (MDPv2) with the NACK Oriented Reliable Multicast (NORM) transport protocol, which I believe remains the _only_ IETF standards track reliable multicast transport protocol that uses Type II hybrid ARQ/FEC to efficiently provide reliable delivery by adapting to widely dynamically varying error rates on network paths. Last I knew, somebody had a BP convergence layer for NORM, and I have long owed the DTN WG a draft on it. :-/
> 
> We used stack variants for different traffic types, e.g. SCPS-TP for TCP connections of applications for which we lacked an app layer proxy.
> 
> PBS was the Portable Batch System. This was an "active network" where each bundle we transported contained a shell script that invoked the necessary service on the DTN destination Internet to do the appropriate thing for the encapsulated payload type.
> 
> The ability of Postfix to deliver mail to a process was a big help. We just hand-whacked the Postfix transport database to use our homegrown DTN stack for specific domains that we knew were on the other end of the SATCOM segment.
> 
> BSMTP (Batch SMTP) enabled us to use actual SMTP (then RFC2821) envelope information ("MAIL FROM" and "RCPT TO") rather than Internet Message Format (IMF, then RFC 2822) content header information. Inferring the former from the latter has long been known to be dangerous, so please look at some of what has been written on that subject before deciding. Sadly I can't remember any specific references but do remember reading about mail routing loops and other problems.
> 
> Sorry for the huge and poorly referenced data dump. Also, to be clear, I am not trying to claim priority or anything like that, just trying to provide some potentially helpful information based on our experience. Happy to chat if you like. Now back to nominally paying work...
> 
> On 1/17/2023 7:32 PM, Marc Blanchet wrote:
>>> Le 17 janv. 2023 à 19:14, Jorge Amodio <[e-mail]> a écrit :
>>> 
>>> Why not BSMTP using CFDP ?
>> I looked at that too... Having a raw RFC822 payload is as simple as it can be. I like things simple...
> 
> -- 
> Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc.
> * Creativity * Diversity * Expertise * Flexibility * Integrity *
> Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
> 315-793-0248 x141 FAX -9710 <[e-mail]> www.critical.com
> <MILCOM_Paper_910_V3.doc><MILCOM_Paper_1024.doc><SWC-CTI-ATC.ppt>