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

Vint Cerf vint at google.com
Thu Mar 21 08:14:17 UTC 2024 

TAPS sounds like a good formulaic solution
v


On Thu, Mar 21, 2024 at 3:46 AM Marc Blanchet via SIS-DTN <
sis-dtn at mailman.ccsds.org> wrote:

>
> Le 21 mars 2024 à 17:15, Sipos, Brian J. via SIS-DTN <
> sis-dtn at mailman.ccsds.org> a écrit :
>
> All,
> I meant to post this earlier to the mailing list instead of individual
> people.
>
> Another thought related to kernel vs. userspace implementations of
> protocols are the pattern described in [3], specifically the design in
> Figure 3 where a kernel module implements the socket API for a new address
> family but delegates all behavior to a userspace daemon. This is akin to an
> AF_BUNDLE implementation delegating actual behavior to a userspace BPA
> implementation (as others have mentioned).
>
> Finally, there is also an IETF Transport Services (TAPS)
>
>
> I said exactly that on this mailing list a while ago. One looking at
> defining a new Transport API should really look into TAPS. TAPS is a
> generic API for any transport: tcp, quic, udp, sctp, … It has generic
> transport semantics and a modern approach (all asynchronous).
>
> effort to create a socket API [4] that has similar logic and behavior to
> POSIX sockets but presumably not directly tied to kernel implementation so
> easier to adapt to new AFs and protocols. It looks preliminary, but could
> be an interesting avenue for prototyping these ideas without getting into
> kernel module stuff.
>
>
> It is more than preliminary. A well-known implementation is Apple, in
> production, in iOS and MacOSX: i.e. in your hands. I developed networking
> apps using it, and it is very modern. See:
> https://developer.apple.com/documentation/network . TAPS is an IETF
> working group that has almost completed its work. See:
> https://datatracker.ietf.org/wg/taps/documents/ (most documents are in or
> near IESG queue for publication).
>
> Regards, Marc.
>
>
> [3]
> https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-o_neill.pdf
> [4]
> https://www.ietf.org/archive/id/draft-dreibholz-taps-neat-socketapi-14.html
>
> *From:* Sipos, Brian J.
> *Sent:* Wednesday, March 20, 2024 1:09 AM
> *To:* 'sburleig.sb at gmail.com' <sburleig.sb at gmail.com>; Jeremy.Mayer at dlr.de
> ; Felix.Flentge at esa.int; vint at google.com
> *Subject:* RE: [EXT] Re: [Sis-dtn] BP Sockets [was RE: IP networking
> within DTN-based protocol architectures]
>
> All,
> I agree that the POSIX socket interface provides all of the needed
> mechanisms do the job of datagram sending/receiving. One thing that I think
> is an important aspect of BP agent--application interface is the ability
> for the application to influence sourced metadata and have visibility into
> delivered metadata (e.g. in addition to the primary block EIDs, things like
> the Lifetime value or Hop Count values). Since there is a similar need in
> IP land there are mechanisms like IP_PKTINFO and “control data” like IP_TOS
> / IP_RECVTOS or IP_TTL / IP_RECVTTL with recvmsg [1].
>
> All of that is when used with SOCK_DGRAM -type sockets sending/receiving
> ADUs as the msg data. A separate interface with SOCK_RAW -type sockets
> could have the entire encoded bundle present as the msg data. Similar to
> using (AF_INET, SOCK_RAW) sockets this allows full visibility into header
> contents but puts a quite large burden on the application to properly
> handle and process that data.
>
> On the other hand, implementations of recent transports like QUIC have
> specifically opted out of in-kernel processing with an associated POSIX
> socket API. Just something to consider from another recent transport
> protocol development. Putting implementation into kernel space is quite a
> large hurdle to clear. But also nothing says you cannot implement a
> ‘prototype’ userspace API modeled after the sockets API like `bp_socket()`
> `bp_sendmsg()`, etc.
>
> [1] https://man7.org/linux/man-pages/man7/ip.7.html
> [2]
> https://stackoverflow.com/questions/16165542/is-it-possible-to-read-the-ttl-ip-header-field-when-receiving-udp-packets
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *sburleig.sb---
> via SIS-DTN
> *Sent:* Monday, March 11, 2024 10:22 AM
> *To:* Jeremy.Mayer at dlr.de; Felix.Flentge at esa.int; vint at google.com
> *Cc:* sis-dtn at mailman.ccsds.org
> *Subject:* [EXT] Re: [Sis-dtn] BP Sockets [was RE: IP networking within
> DTN-based protocol architectures]
>
> *APL external email warning: *Verify sender
> sis-dtn-bounces at mailman.ccsds.orgbefore clicking links or attachments
>
>
> 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).
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>
>
> _______________________________________________
> 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


until further notice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240321/d9abcfc1/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/20240321/d9abcfc1/attachment-0001.bin>

More information about the SIS-DTN mailing list