[Sis-dtn] [EXTERNAL] [BULK] Re: BP Sockets [was RE: IP networking within DTN-based protocol architectures]

Mon Mar 11 15:19:08 UTC 2024

I think the intent is to provide an API that would work for a variety of
underlying carriage (IP, UDP, TCP, LTP, ...???)
v

On Mon, Mar 11, 2024 at 9:40 AM Deaton, Joshua E. (MSFC-HP27)[MOSSI2] <
joshua.e.deaton at nasa.gov> wrote:

> Just to make sure I am following correctly; the current suggestion is to
> create a POSIX (BSD) Socket Specification for BP where we are putting BP
> directly on top of IP without TCP/UDP or are we trying to fully displace IP
> all the way down and so BP replaces IP at layer 3.
>
>
>
> Sincerely,
>
> Joshua Deaton
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> * On Behalf Of *sburleig.sb---
> via SIS-DTN
> *Sent:* Monday, March 11, 2024 9:22 AM
> *To:* Mayer, Jeremy P. (JSC-OT/ESA)[EUROPEAN SPACE AGENCY] <
> jeremy.mayer at dlr.de>; Felix.Flentge at esa.int; vint at google.com
> *Cc:* sis-dtn at mailman.ccsds.org
> *Subject:* [EXTERNAL] [BULK] Re: [Sis-dtn] BP Sockets [was RE: IP
> networking within DTN-based protocol architectures]
>
>
>
> *CAUTION:* This email originated from outside of NASA.  Please take care
> when clicking links or opening attachments.  Use the "Report Message"
> button to report suspicious messages to the NASA SOC.
>
>
>
> Right, the service interface in the CCSDS BP specification -- like all
> service specifications -- is abstract; it defines the properties of a BP
> API for the purpose of explaining the required behavior of a Bundle
> Protocol Agent.  Any number of existing and future BP implementations with
> very different APIs can be wholly conformant to that specification.  But a
> BP sockets specification would enable any application that currently
> communicates over POSIX (BSD) sockets to use BP instead of UDP without
> extensive code changes; the syntax is already in place.  That’s the
> compelling advantage of the idea.
>
>
>
> Scott
>
>
>
> *From:* Jeremy.Mayer at dlr.de <Jeremy.Mayer at dlr.de>
> *Sent:* Monday, March 11, 2024 3:48 AM
> *To:* Felix.Flentge at esa.int; sburleig.sb at gmail.com; vint at google.com
> *Cc:* sis-dtn at mailman.ccsds.org
> *Subject:* RE: BP Sockets [was RE: [Sis-dtn] IP networking within
> DTN-based protocol architectures]
>
>
>
> Hi,
>
> In the abstract, I’d say so, but (let’s be honest) many developers tend to
> ignore the abstract notion of the service interface and prefer to have a
> tangible set of API operations.
>
>
>
> Thanks,
>
> Jeremy
>
>
>
> *From:* Felix Flentge <Felix.Flentge at esa.int>
> *Sent:* Montag, 11. März 2024 11:46
> *To:* sburleig.sb at gmail.com; Mayer, Jeremy <Jeremy.Mayer at dlr.de>;
> vint at google.com
> *Cc:* sis-dtn at mailman.ccsds.org
> *Subject:* BP Sockets [was RE: [Sis-dtn] IP networking within DTN-based
> protocol architectures]
>
>
>
> Hi,
>
>
>
> I like the idea but isn’t this already covered (partially) by the CCSSDS
> BP service interface, eg:
>
>
>
> ·         Bind – register EID in passive state
>
> ·         Listen – register EID in active state
>
> ·         Connect – sets a default destination for future send.request
>
> ·         Send – send.request
>
> ·         Recv – poll.request
>
>
>
> Regards,
>
> Felix
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *sburleig.sb---
> via SIS-DTN
> *Sent:* Saturday, March 9, 2024 6:56 PM
> *To:* Jeremy.Mayer at dlr.de; vint at google.com
> *Cc:* sis-dtn at mailman.ccsds.org
> *Subject:* Re: [Sis-dtn] IP networking within DTN-based protocol
> architectures
>
>
>
> Thanks for that analysis, Jeremy.  We’ve been talking about at least since
> STINT several years ago, and I really think it’s an idea whose time has
> come.
>
>
>
> Scott
>
>
>
> *From:* Jeremy.Mayer at dlr.de <Jeremy.Mayer at dlr.de>
> *Sent:* Saturday, March 9, 2024 8:01 AM
> *To:* vint at google.com; sburleig.sb at gmail.com
> *Cc:* Tomaso.deCola at dlr.de; sis-dtn at mailman.ccsds.org
> *Subject:* RE: [Sis-dtn] IP networking within DTN-based protocol
> architectures
>
>
>
> Hi,
>
> That’s a fair point. Generally, I’d say that BP-POSIX could work with the
> following:
>
> ·         Bind – works: sets source EID.
>
> ·         Listen – works; sets source EID and opens reception.
>
> ·         Connect – UDP style, sets default destination address.
>
> ·         Send – only valid for connected bundlesocks.
>
> ·         Sendto/sendmsg – works.
>
> ·         Recv – works.
>
> ·         Recvfrom/recvmsg – works, probably should support “wildcard”
> EIDs, at least for services.
>
> ·         Getaddrinfo and friends – not required
>
> ·         Select – Works, highly implementation dependent.
>
>
>
> BSD sockets really do work for everything!
>
>
>
> Thanks,
>
> Jeremy
>
>
>
>
>
> *From:* Vint Cerf <vint at google.com>
> *Sent:* Samstag, 9. März 2024 16:51
> *To:* Scott Burleigh <sburleig.sb at gmail.com>
> *Cc:* Mayer, Jeremy <Jeremy.Mayer at dlr.de>; de Cola, Tomaso <
> Tomaso.deCola at dlr.de>; Dr. Keith L Scott via SIS-DTN <
> sis-dtn at mailman.ccsds.org>
> *Subject:* Re: [Sis-dtn] IP networking within DTN-based protocol
> architectures
>
>
>
> Yes generally speaking
>
>
>
> On Sat, Mar 9, 2024, 10:43 <sburleig.sb at gmail.com> wrote:
>
> I think we get closer to BSD/POSIX if we use UDP as a model.  The
> attenuated UDP notion of connect() would work for BP, I think.
>
>
>
> Scott
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *Jeremy
> Mayer via SIS-DTN
> *Sent:* Saturday, March 9, 2024 12:35 AM
> *To:* vint at google.com; Tomaso.deCola at dlr.de
> *Cc:* sis-dtn at mailman.ccsds.org
> *Subject:* Re: [Sis-dtn] IP networking within DTN-based protocol
> architectures
>
>
>
> Hi,
>
> I’m tempted to agree. I’ve seen limited utility in IP->BP encap, as (other
> than some unidirectional UDP-based applications), the assumptions made in
> IP networks (especially TCP) do not scale well to DTN environments. The two
> largest issues I see are:
>
> A.      The assumption that relatively low-latency and bidirectional
> communication is available.
>
> B.      The layering of stream and message-based semantics.
>
>
>
> Almost every TCP-ish application which I’ve seen run over BP winds up with
> exceptionally low performance, unless some sort of PEP is integrated, which
> adds complexity, failure points, and fragility.
>
>
>
> +1 for the notion of a standard API though, with the additional caveat
> that we should standardize nomenclature across implementations. We could
> likely reuse about 80% of the BSD/POSIX interface for BP, with the notable
> exception of connect.
>
>
>
> Thanks,
>
> Jeremy
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *Vint
> Cerf via SIS-DTN
> *Sent:* Freitag, 8. März 2024 12:31
> *To:* de Cola, Tomaso <Tomaso.deCola at dlr.de>
> *Cc:* sis-dtn at mailman.ccsds.org
> *Subject:* Re: [Sis-dtn] IP networking within DTN-based protocol
> architectures
>
>
>
> The more I think about this, the less I like trying to manage off-Earth IP
> networks remotely. I think I would much rather see native applications
> running over BP. In any case we need to develop standard APIs for BP, such
> as the Sockets interface for Linux/Unix/Posix.
>
>
>
> We do need to figure out how IP-based and BP-based applications interwork.
> What do Domain Names mean in the BP context for example.
>
>
>
> v
>
>
>
>
>
> On Fri, Mar 8, 2024 at 4:24 AM Tomaso de Cola via SIS-DTN <
> sis-dtn at mailman.ccsds.org> wrote:
>
> Dear All,
>
>
>
> as mentioned yesterday during our DTN weekly, during the past Fall meeting
> a presentation was given by University of Nanjing with the support of
> Chinese agency about IP-networking within DTN-based protocol stacks,
> especially for planetary network segments (i.e. what is often referred to
> as IP-islands).
>
> The link to that presentation is as follows:
>
>
>
>
> https://cwe.ccsds.org/sis/docs/SIS-DTN/Meeting%20Materials/2023/Fall%202023%20SIS-DTN/Possible%20BOF%20Discussion.pptx?d=w44d31f0b3be649e4bf24ec4ae50479a1
>
>
>
> The proposal made there was for a BOF (i.e. towards a WG formation), which
> I see however too premature. On the contrary, I’d be more in favour for a
> SIG (Special Interest Group), happening outside the DTN WG.
>
>
>
> As discussed yesterday, key points to clarify/agree are:
>
>
>
> 1.       Is the proposal sound and meaningful to be addressed?
>
> 2.       Is appropriate for the SIS area or should be better addressed at
> architectural level in SEA (maybe it can be even a cross-area initiative)?
>
> 3.       In the case of SIS, is there significant support to start this?
> In other words, which agencies have interest in contributing to this
> activity?
>
>
>
> Thank you for sharing comments/objections/suggestions.
>
>
>
> Have a nice weekend,
>
>
>
> Tomaso
>
>
>
> ————————————————————————
>
> *Deutsches Zentrum für Luft- und Raumfahrt* (DLR)
> German Aerospace Center
> Institute of Communications and Navigation | Satellite Networks |
> Oberpfaffenhofen | 82234 Wessling | Germany
>
> *Tomaso de Cola, Ph.D.* |
> *Integrated Satellite Systems (INS) Team Leader *Telefon +49 8153 28-2156
> <+49%208153%20282156> | Telefax  +49 8153 28-2844 <+49%208153%20282844> |
> tomaso.decola at dlr.de <sandro.scalise at dlr.de>
> http://www.dlr.de/kn/institut/abteilungen/san
>
>
>
>
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>
>
>
>
> --
>
> Please send any postal/overnight deliveries to:
>
> Vint Cerf
>
> Google, LLC
>
> 1900 Reston Metro Plaza, 16th Floor
>
> Reston, VA 20190
>
> +1 (571) 213 1346 <(571)%20213-1346>
>
>
>
>
>
> until further notice
>
>
>
>
>
>
>
> This message is intended only for the recipient(s) named above. It may
> contain proprietary information and/or protected content. Any unauthorised
> disclosure, use, retention or dissemination is prohibited. If you have
> received this e-mail in error, please notify the sender immediately. ESA
> applies appropriate organisational measures to protect personal data, in
> case of data privacy queries, please contact the ESA Data Protection
> Officer (dpo at esa.int).
>

-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346

until further notice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240311/0f9d16d6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4006 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240311/0f9d16d6/attachment-0001.bin>