[Sis-dtn] IP networking within DTN-based protocol architectures
Vint Cerf
vint at google.com
Mon Mar 11 10:57:42 UTC 2024
thanks Felix, these comments are very helpful.
v
On Mon, Mar 11, 2024 at 5:39 AM Felix Flentge <Felix.Flentge at esa.int> wrote:
> Hi,
>
>
>
> On the the IP / BP Networking discussion:
>
> 1. I believe from CCSDS / IOAG / IPNSIG perspective (please correct me
> if I am wrong), we see BP as the E2E (inter-)networking protocol (see, eg IOAG
> Recommendations on the Selection of ETE Space Internetworking Protocol
> (002).pdf
> <https://www.ioag.org/Public%20Documents/IOAG%20Recommendations%20on%20the%20Selection%20of%20ETE%20Space%20Internetworking%20Protocol%20(002).pdf>).
> As such, I would see IP networks eg on lunar surface as isolated Local Area
> Networks without IP routing into other IP networks. As pointed out by
> Jeremy, we should avoid (naïve) IP / BP encapsulation.
> 2. For CCSDS / IOAG we should focus on the near- to medium-term use
> case. For me this means mainly spacecraft M&C, bulk data downlink,
> voice&video, teleoperations, last-hop/first-hop, messaging. Of course, it
> is interesting to think and experiment with terrestrial applications over
> BP but I don’t believe this should be an CCSDS / IOAG task priority right
> now.
> 3. We need to be aware of the on-going activities, in particular
> LunaNet Interoperability Specification and IOAG Work (SC#2 update; I will
> present at spring meeting). IMHO, we might already have to many WG related,
> so I am not in favour of creating a new one.
> 4. It certainly would make sense to consider the IP / BP networking
> case in the SEA architectures (with support from DTN WG)
>
>
>
> 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/e5f7eb4d/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/e5f7eb4d/attachment-0001.bin>
More information about the SIS-DTN
mailing list