[Sis-dtn] Corrections Re: DTN Comm "Scenarios"

Tue Oct 22 18:55:32 UTC 2024

Apologies for any misinformation and misconceptions I (and others) have had about things going on at GSFC. We are largely in the dark on things going on in PACE or NSN, so thanks for correcting any misperceptions..

Interoperability testing between implementations / agencies etc. is in the planning stage now; fair enough to say there are no formal requirements or formal agreements now on what implementations will be tested; the FY25 aim is to test and develop a fully qualified and CCSDS-compliant end-to-end DTN system that will handle the requirements for the future lunar and deep space programs. We expect to start with support for interoperability testing to get a BPv7 bluebook, and to agree on reference test scenarios, including control plane and operations concepts, and when planning tests and participants, the WG will arrive at consensus for the way forward.

Regards,
Leigh

From: "Israel, David J. (GSFC-4500)" <david.j.israel at nasa.gov>
Date: Tuesday, October 22, 2024 at 11:33 AM
To: Keith Scott <keithlscott at gmail.com>, "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Cc: "Lux, Jim (US 3370)" <james.p.lux at jpl.nasa.gov>, "Howard.Weiss at parsons.us" <Howard.Weiss at parsons.us>, "Shames, Peter M (US 9740)" <peter.m.shames at jpl.nasa.gov>, "Keithlscott at gmail.com" <keithlscott at gmail.com>, "durst at mitre.org" <durst at mitre.org>, "Radulescu, Costin (US 9300)" <cradule at jpl.nasa.gov>, "Edward.Birrane at jhuapl.edu" <Edward.Birrane at jhuapl.edu>, "Torgerson, Jordan L (332M)" <jordan.l.torgerson at jpl.nasa.gov>, "Wyatt, E Jay (US 9730)" <e.jay.wyatt at jpl.nasa.gov>, "Sanchez Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov>, "Baldwin, Philip J (HQ-CG000)" <philip.j.baldwin at nasa.gov>, "Evans, Wendy C. (HQ-CG000)" <wendy.c.evans at nasa.gov>, "Anderson, Benjamin F. (GSFC-4502)" <benjamin.f.anderson at nasa.gov>, "Jain, Peyush (GSFC-4502)" <peyush.jain at nasa.gov>, "Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC]" <jonathan.j.wilmot at nasa.gov>, "Hylton, Alan G. (GSFC-4570)" <alan.g.hylton at nasa.gov>, "Raible, Daniel E. (GRC-LCP0)" <daniel.e.raible at nasa.gov>, "Dudukovich, Rachel M. (GRC-LCI0)" <rachel.m.dudukovich at nasa.gov>, "Asmar, Sami W (US 9100)" <sami.w.asmar at jpl.nasa.gov>, "Pham, Timothy T (US 3300)" <timothy.t.pham at jpl.nasa.gov>, "Ristovski, Ivica (MSFC-HP27)" <ivica.ristovski at nasa.gov>
Subject: Corrections Re: DTN Comm "Scenarios"

Hello All,

It has been a while since I directly participated in any of the DTN meetings and email threads, but I’m still here at NASA Goddard Space Flight Center working to move DTN forward. Most relevantly, I am currently the Near Space Network Chief Architect, a lead for LunaNet Interoperability, and the Principal Investigator for the Laser Communications Relay Demonstration (LCRD). I am writing to provide some corrections to the inaccuracies related to Goddard and LunaNet activities included in an email sent out to this wide distribution. I did not want these to go uncorrected. I am not saying that everything else stated about HDTN, HOSC, and other items is correct. It is just not my place to address any of those.

Enumerated quotes from the email are below with my responses. The full email thread is included below that.

I don’t want to get into a long back and forth email thread, so if anybody wants to discuss this, let’s schedule a call.

I am excited about the progress towards DTN infusion and I believe we are all working towards the vision of the Solar Systems Internet.

Regards,
Dave Israel

  1.  “At Goddard, the PACE project is flying cFS with BPLIB, a library based on the ION BP implementation”
This is false. GSFC developed a cFS library, named BPLIB developed and certified to NASA Class B (mission critical) processes, that does not incorporate any ION code. The ground station and PACE mission ops center nodes use ION with a wrapper around it called BPN-GND that was developed at GSFC to add support for interfaces unavailable in ION.

  1.  “the NSN has no DTN capability at present.”
This is false. The NSN has been supporting 15 passes per day by the PACE spacecraft since 2/8/2024 with operational DTN nodes at four NSN ground stations (Alaska (AS4), Svalbard (SG12), Punta Arenas (PA11), Wallops (WG5)). At this time, the NSN has supported approximately 3600 total passes and over 16 million bundles to date and counting.

There are also DTN nodes installed in the Laser Communications Relay Demonstration (LCRD) ground network that are available for continuing demonstrations.

  1.  “The DSN supports the Artemis program now, as well as an LCRNS lunar relay satellite – eventually as the other LCRNS satellites come online, the NSN will start using them to provide LunaNet services, providing they get the budget to build several new 18 or 20 M dishes, and when they do that, they’ll have to put DTN in the NSN. “
This is false. There are currently no plans for the DSN to support any lunar relay satellites. The NSN has awarded the Near Space Network Services Subcategory 2.2 GEO to Cislunar Relay Services contract to Intuitive Machines (IM). IM is responsible for the ground station support for their relays without use of the DSN. The NSN will be responsible for the full end-to-end delivery of user DTN data, so will have DTN “points of presence” or “edge nodes” to connect to the IM ground and user terrestrial system demarcation points.

  1.  “… they’ll have to put DTN in the NSN. What DTN version? Probably ION for a couple of reasons: first off, HDTN…doesn’t have all the features and capabilities of ION…, and secondly is that we’ve heard from several commercial lunar program participants that they do NOT want to have a different DTN version on the ground because that doubles the risk, testing cost, CM and maintenance costs, and they want to go ION from end to end to be able to be low risk and cost competitive.”
The choice of NSN DTN implementations has not been decided and will be based on whatever meets all requirements. Use of a particular implementation will not be required. Any commercial providers under contract with the NSN will be free to use any implementation they wish, as long as requirements are met. There should not be any assumptions that the same implementation of DTN would be used in all nodes end-to-end. flight and ground systems. Systems will be built and maintained by different organizations at different times. The purpose of standards is to prevent the need for requiring specific implementations.

  1.  “They put an HDTN computer on one end of a couple of optical links, tunneled bundles through the bent pipe optical links to Table Mountain, where the other HDTN laptop lived, and said ’DTN works with optical comm!!’”
This is false. An HDTN implementation on ISS sent and received bundles using LTP between a node onboard the ISS and four different ground nodes over optical forward and return links through a frame layer relay onboard the LCRD flight payload. For BPv6 experiments, a TReK node on the ISS relayed bundles through the HDTN node and the ground network to communicate with a TReK node in the HOSC. LCRD has also performed DTN demonstrations over optical links from ground stations. Testing indicated that the ION implementations would not be able to support the required rates for the ISS use. The maximum rate supported over ISS optical links was 980 Mbps.

  1.  “well, I’ll believe DTN for Optical comm when the originator of the data in space has DTN with LTP on board, and not just a bent pipe experiment.”
Believe it. That’s what was done at a maximum rate of 980 Mbps.

  1.  “ION can do up to 400 Mbps which will satisfy both the Ka-Band and optical rates required for LunaNet, so we don’t think we need HDTN in space.”
Choice of DTN implementations will be up to users and provider systems – whatever meets requirements. Future LunaNet rates are expected to exceed 400 Mbps.

  1.  “However, for operational end-to-end testing, we’ll use ION everywhere in US, JAXA or commercial DTN nodes, and Felix-ware for ESA, as that will most closely represent the anticipated scenarios.”
There are no agreements or requirements to “Use ION everywhere in US, JAXA or commercial DTN nodes” for operational end-to-end testing.

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Keith Scott via SIS-DTN
Sent: Wednesday, October 2, 2024 4:23 AM
To: sis-dtn at mailman.ccsds.org
Subject: [BULK] [Sis-dtn] Fwd: [EXTERNAL] Re: DTN Comm "Scenarios"

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.

Information from Leigh Torgerson at JPL.

---------- Forwarded message ---------
From: Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>
Date: Tue, Oct 1, 2024 at 6:03 PM
Subject: Re: [EXTERNAL] Re: DTN Comm "Scenarios"
To: Lux, Jim (US 3370) <james.p.lux at jpl.nasa.gov<mailto:james.p.lux at jpl.nasa.gov>>, Howard.Weiss at parsons.us<mailto:Howard.Weiss at parsons.us> <Howard.Weiss at parsons.us<mailto:Howard.Weiss at parsons.us>>, Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Keith Scott (keithlscott at gmail.com<mailto:keithlscott at gmail.com>) <keithlscott at gmail.com<mailto:keithlscott at gmail.com>>, Howie Weiss (Howard.Weiss at parsons.com<mailto:Howard.Weiss at parsons.com>) <Howard.Weiss at parsons.com<mailto:Howard.Weiss at parsons.com>>, Bob Durst (durst at mitre.org<mailto:durst at mitre.org>) <durst at mitre.org<mailto:durst at mitre.org>>, Radulescu, Costin (US 9300) <cradule at jpl.nasa.gov<mailto:cradule at jpl.nasa.gov>>, EXTERNAL-Birrane, Edward J (US 9300-Affiliate) <Edward.Birrane at jhuapl.edu<mailto:Edward.Birrane at jhuapl.edu>>
Cc: Asmar, Sami W (US 9100) <sami.w.asmar at jpl.nasa.gov<mailto:sami.w.asmar at jpl.nasa.gov>>, Pham, Timothy T (US 3300) <timothy.t.pham at jpl.nasa.gov<mailto:timothy.t.pham at jpl.nasa.gov>>

More info for the CCSDS team:

Lunar Delay:

We have commercial Apposite WAN emulators that can delay and create random loss according to several statistical distributions, and they are ok up to maybe 10 seconds OWLT depending on the data rate.  We have 1 Gbps models, whereas when GRC copied my lab, they bought 10 Gbps models ($30K each). For situations where it is inconvenient to route data through the Apposite N91 boxes (we have 4 of them with 4 channels each), we use traffic control from the iproute2 package to accomplish much the same (but the Apposite boxes have a nice GUI, with plots of the traffic, and lots of easy ways to adjust the noise/delay parameters.).   For things like Lunar comm emulations where the delay is more or less fixed (DTN has a 1 sec granularity so we don’t try to do emulations with OWLT changing for lunar distances..) TC/iproute2 requires iptables to be installed. (Haven’t had much luck so far trying to get all this working in Windoze with wsl2 though..)

Deep space delay:

We have a delay simulator that spools off on disk, and we can do OWLT delays to Pluto. The Europa Clipper folks have adapted it to do 40-min OWLT delays for mission ops training etc.  It does not to noise emulation, so if we want that on top of obnoxious OWLT delays, we run the data through the Apposite box, let it drop frames, and then go through the delaysim program to do the delay.

Note on these emulations – since we do not have RF in the lab, we normally do all our tests with bundles or LTP segments going out through UDP/TCP/IP (with frames sized to fit into TM/TC/AOS, etc.) and leave the link performance as an exercise for the reader. There is a feature in the LTP setup tool that allows you to calculate the effective expected bit error rate (an ltp parameter) as a function of CCSDS coding type / frame size, so the WAN emulator loss rate can be calculated for a given link budget.

That being said, we also have 3 commercial telemetry systems (Ingenicomm and Avtec) that do CCSDS TC/TM/AOS, so we can feed bundles or LTP segments into the link layer, but then we’re rather stopped not having coding/modulation/RF burns below.  We can (and have) checked out external telemetry framing by feeding the frames to the telem boxes over UDP/IP, but that’s better left to the DSN to check out now.

Future enhancement plans include adding the DSN Simulator (a DSN product) to the testbeds in the PTL, and then eventually adding end-to-end (well, spacecraft to DSN DTN node) traffic testing to DTF-21 testing for the full RF experience..  We welcome Jim Lux and 337’s RF expertise to the party!

Testing with GRC, since Howie brought it up:
Regarding GRC and their HDTN DTN implementation: They duplicated the PTL and have actually proposed to take over all of the PTL’s work in interoperability testing, and that goes hand-in-hand with their high-pressure sales of their HDTN C++ implementation of DTN. For reasons I’ll not get in to, HDTN is unsuitable for flight systems (ask Ed..), so FY 2024 started with a NASA mandate for the team to work toward merging ION and HDTN into a single NASA version. That turned out to be impossible, so that effort was abandoned, and NASA decided that HDTN would be suitable for use on the ISS and as a replacement for Marshall’s DTN-ME, which had to be abandoned because of a change in Marshall’s HOSC ground systems. So as of today, HDTN is for ISS, while ION DTN is for NASA/JAXA and many US commercial projects. We have no scenarios at present that include the ISS and HOSC.

At Goddard, the PACE project is flying cFS with BPLIB, a library based on the ION BP implementation, but the NSN has no DTN capability at present. The DSN supports the Artemis program now, as well as an LCRNS lunar relay satellite – eventually as the other LCRNS satellites come on line, the NSN will start using them to provide LunaNet services, providing they get the budget to build several new 18 or 20 M dishes, and when they do that, they’ll have to put DTN in the NSN. What DTN version? Probably ION for a couple of reasons: first off, HDTN (which has a strong advocate at GSFC because he came from GRC and helped build HDTN) doesn’t have all the features and capabilities of ION (which they could add if NASA wanted to continue to support 2 DTN versions), and secondly is that we’ve heard from several commercial lunar program participants that they do NOT want to have a different DTN version on the ground because that doubles the risk, testing cost, CM and maintenance costs, and they want to go ION from end to end to be able to be low risk and cost competitive.

HDTN is “high speed” they use the GPU and direct access to hardware on the motherboard to increase speed, which is swell if you have the right commodity server on the ground, but not that great in space unless you are flying a powerful laptop in your spacecraft.  They put an HDTN computer on one end of a couple of optical links, tunneled bundles through the bent pipe optical links to Table Mountain, where the other HDTN laptop lived, and said “DTN works with optical comm!!” – well, I’ll believe DTN for Optical comm when the originator of the data in space has DTN with LTP on board, and not just a bent pipe experiment.  ION can do up to 400 Mbps which will satisfy both the Ka-Band and optical rates required for LunaNet, so we don’t think we need HDTN in space. ESA is working on putting LTP (equivalent) into an FPGA for future near-earth high speed optical comm use, and that will be an excellent advancement, since generally speaking, the LTP portion of the DTN stack is where the bottlenecks occur.

So for interoperability testing for the purposes of CCSDS Bluebook tests, HDTN as a second implementation tested with ION or D3TN or ESA’s implementation makes sense for getting the Bluebook out.  However, for operational end-to-end testing, we’ll use ION everywhere in US, JAXA or commercial DTN nodes, and Felix-ware for ESA, as that will most closely represent the anticipated scenarios.  GRC is now leading the charge in developing new applications for DTN and some new APIs for BP to be standardized eventually, and they are also in charge of the DTN Engineering Network (an international VPN setup where people can log into a vlan essentially, and test DTN implementations), so we plan on having GRC use their lab and the DEN to emulate endpoint systems and parts of any given scenario for the purposes of prototyping and testing out scenarios. If they want to use HDTN that’s their call; but when we start doing performance and functional testing “for the record”, we must use the systems actually in the DSN, ESA, KDSA, JAXA etc., and not GRC’s HDTN, which we don’t expect to be used anywhere but in the ISS. When we get to testing a scenario that actually includes the Gateway spacecraft and the HLS, that’s when we may have a food fight – MSFC/HOSC wants to be responsible for the Gateway spacecraft when the ISS goes away, and they’ll probably want to put HDTN laptops on the Gateway spacecraft – but at least one vendor has told me that they will only use ION end-to-end (for reasons of software size and lower risk), so HOSC will have to plan for that. Fortunately, near-term we need to focus just on the scenarios Feliz has proposed (which look pretty good, save for some link rates that look pretty high – like maybe S- or X-band Prox-1?) I’m reviewing those with the Mars program now..

Leigh

From: "Lux, Jim (US 3370)" <james.p.lux at jpl.nasa.gov<mailto:james.p.lux at jpl.nasa.gov>>
Date: Tuesday, October 1, 2024 at 6:26 AM
To: "Howard.Weiss at parsons.us<mailto:Howard.Weiss at parsons.us>" <Howard.Weiss at parsons.us<mailto:Howard.Weiss at parsons.us>>, "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, "Keith Scott (keithlscott at gmail.com<mailto:keithlscott at gmail.com>)" <keithlscott at gmail.com<mailto:keithlscott at gmail.com>>, Howie Weiss <Howard.Weiss at parsons.com<mailto:Howard.Weiss at parsons.com>>, "Bob Durst (durst at mitre.org<mailto:durst at mitre.org>)" <durst at mitre.org<mailto:durst at mitre.org>>, "Radulescu, Costin (US 9300)" <cradule at jpl.nasa.gov<mailto:cradule at jpl.nasa.gov>>, "Torgerson, Jordan L (332M)" <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>, "EXTERNAL-Birrane, Edward J (US 9300-Affiliate)" <Edward.Birrane at jhuapl.edu<mailto:Edward.Birrane at jhuapl.edu>>
Cc: "Asmar, Sami W (US 9100)" <sami.w.asmar at jpl.nasa.gov<mailto:sami.w.asmar at jpl.nasa.gov>>, "Pham, Timothy T (US 3300)" <timothy.t.pham at jpl.nasa.gov<mailto:timothy.t.pham at jpl.nasa.gov>>
Subject: Re: [EXTERNAL] Re: DTN Comm "Scenarios"

Delays wise I’m pretty sure Leigh has that capability in the protocol test lab at JPL

Get Outlook for iOS<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Faka.ms*2Fo0ukef&data=05*7C02*7Cjordan.l.torgerson*40jpl.nasa.gov*7C7d7b3d4099b443ef89ec08dcf2c7f4f4*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C638652187896603321*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C0*7C*7C*7C&sdata=8G2RTv*2B4N1zz4YmL3P5tulR*2BAtST9HOaJabwnJ8U*2FTE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!LG2BbHqRYXo1cEK0FTBkZ8l3Ngk3cucv4bGOhFgCL7c3vfVrCLK4B3ZwYIaRl-WLCjxnV1aMradegYiYrQEkQWG_UFuK$>
________________________________
From: Howard.Weiss at parsons.us<mailto:Howard.Weiss at parsons.us> <Howard.Weiss at parsons.us<mailto:Howard.Weiss at parsons.us>>
Sent: Tuesday, October 1, 2024 5:50:54 AM
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>; Keith Scott (keithlscott at gmail.com<mailto:keithlscott at gmail.com>) <keithlscott at gmail.com<mailto:keithlscott at gmail.com>>; Howie Weiss (Howard.Weiss at parsons.com<mailto:Howard.Weiss at parsons.com>) <Howard.Weiss at parsons.com<mailto:Howard.Weiss at parsons.com>>; Bob Durst (durst at mitre.org<mailto:durst at mitre.org>) <durst at mitre.org<mailto:durst at mitre.org>>; Radulescu, Costin (US 9300) <cradule at jpl.nasa.gov<mailto:cradule at jpl.nasa.gov>>; Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>; EXTERNAL-Birrane, Edward J (US 9300-Affiliate) <Edward.Birrane at jhuapl.edu<mailto:Edward.Birrane at jhuapl.edu>>
Cc: Asmar, Sami W (US 9100) <sami.w.asmar at jpl.nasa.gov<mailto:sami.w.asmar at jpl.nasa.gov>>; Lux, Jim (US 3370) <james.p.lux at jpl.nasa.gov<mailto:james.p.lux at jpl.nasa.gov>>; Pham, Timothy T (US 3300) <timothy.t.pham at jpl.nasa.gov<mailto:timothy.t.pham at jpl.nasa.gov>>
Subject: [EXTERNAL] Re: DTN Comm "Scenarios"

Peter

+1- makes a lot of sense.

BTW, at one of the DTN face-2-face meetings, I thought that I heard that GRC was already doing (or planning) interoperability testing between the various NASA flavors of DTN.  Very much akin to what we used to call 'bake-off' in the IETF during the hey-day of TCP/IP interoperability testing.

BTW, Bob or Keith can provide more in-depth info, but back in the SCPS days we also did 'realistic scenario' testing with (I believe) lunar distance delays.

regards

howie

________________________________
From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Sent: Monday, September 30, 2024 2:32 PM
To: Keith Scott (keithlscott at gmail.com<mailto:keithlscott at gmail.com>) <keithlscott at gmail.com<mailto:keithlscott at gmail.com>>; Howie Weiss (Howard.Weiss at parsons.com<mailto:Howard.Weiss at parsons.com>) <Howard.Weiss at parsons.com<mailto:Howard.Weiss at parsons.com>>; Bob Durst (durst at mitre.org<mailto:durst at mitre.org>) <durst at mitre.org<mailto:durst at mitre.org>>; Radulescu, Costin (US 9300) <cradule at jpl.nasa.gov<mailto:cradule at jpl.nasa.gov>>; Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>; EXTERNAL-Birrane, Edward J (US 9300-Affiliate) <Edward.Birrane at jhuapl.edu<mailto:Edward.Birrane at jhuapl.edu>>
Cc: Asmar, Sami W (US 9100) <sami.w.asmar at jpl.nasa.gov<mailto:sami.w.asmar at jpl.nasa.gov>>; Lux, Jim (US 3370) <james.p.lux at jpl.nasa.gov<mailto:james.p.lux at jpl.nasa.gov>>; Pham, Timothy T (US 3300) <timothy.t.pham at jpl.nasa.gov<mailto:timothy.t.pham at jpl.nasa.gov>>
Subject: [EXTERNAL] FW: DTN Comm "Scenarios"

Guys,

Last Friday we had one of our bi-weekly side discussions, with Keith, Howie, Costin, and I in attendance. This key discussion topic was prompted by a request made to Costin, in the IOAG MOSSG, that they take on the issue of DTN LunaNet testing.  We spent some time talking about the “territory” for this and all of the different players, including: CCSDS, IOAG, IETF, DTN Project, NASA LunaNet, ESA missions, etc.  It’s complicated.

I agreed to talk to Felix Flentge, who has been working with ESA colleagues to do something similar that Howie shared a copy of. I reached out to Felix asking if they were interested in collaborating on this.  Seemed to me that having a joint effort from NASA and ESA would be better than coming from just one of us.

He responded positively (see attached).   I wrote back suggesting that we try and create something and publish it as a Yellow Book, which would just be a Report, or even an Orange Book in an MB, Recommended Practice, style.  Something like a proposal for a joint CCSDS Recommended Practice for SSI Interoperability Testing.   Could be a SIS, or a SIS & SEA joint document.

Are you guys all willing to get behind this?  Or, to put it another way, do any of you have strong objections?  If not, are yoy willing to put some effort into this to support it going forward?

Cheers, Peter

From: Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>
Date: Monday, September 30, 2024 at 7:28 AM
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Camillo Malnati <Camillo.Malnati at ext.esa.int<mailto:Camillo.Malnati at ext.esa.int>>
Cc: Tomaso de Cola <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Subject: [EXTERNAL] RE: DTN Comm "Scenarios"

Hi Peter,

Yes, this absolutely makes sense and has been our intention from the beginning.

One additional use case we are targeting is also academic research and we would like the IETF Deep-Space people to actually use more realistic test cases ...

What is important from our point of view

  1.  Get something out quickly (within the next few months) and find a way to get a CCSDS stamp on it (yellow books? publication on the website, ... – Tomaso is looking into this).
  2.  Keep the scenarios as simple as possible but maintaining the main characteristics. We are aiming at only three scenarios which are based on some publicly available (or internally available) information. They will be set-up in a modular way that people can eg vary data rates, etc. What I definitely want to avoid is a huge discussion on the ‘right’ parameters for certain links, etc. – I fear that this will take forever.

I have attached the current status of our scenarios. I would hope that we have something almost complete by the fall meetings.

Regards,

Felix

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Sent: Saturday, September 28, 2024 2:27 AM
To: Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>; Camillo Malnati <Camillo.Malnati at ext.esa.int<mailto:Camillo.Malnati at ext.esa.int>>
Subject: DTN Comm "Scenarios"

Hi Felix and Camillo,

I’ve been talking to some of my NASA colleagues over the last several months about the need for what I have been calling a “DTN interoperability test jig”.  The concept was to have a set of realistic Lunar and Mars mission deployments (MOC, GT, orbiter, lander/rover), a realistic set of contact plans and orbits, and a realistic set of required data flows (DTE/DFE, relayed, uplink and downlink).  The idea was to have this “test jig” as an “operationally relevant environment, either real or simulated”, to use CCSDS interoperability language, but to test a whole “Stack” of DTN protocols and ancillary services, as opposed to just one layer of the stack, like BP or BPSec.  This could be used for just the “core protocols”, BP, BPSec, SABR, and also for the whole DTN suite, including routing, network management, key management and identities, etc.

There have been various notes about this discussed and sent around by email, see email at the end.  One of our guys, Leigh Torgerson, was working in the NASA DTN Project to come up with a related formalized approach for doing interoperability testing in that project, and leveraging various testbeds.  That was to accommodate what had been done in that project and also work he has been doing in the JPL Protocol Test Lab (PTL) that you may be familiar with.

I think that this whole concept of a “test jig”, or “comm scenarios”, or whatever it gets called, with all of these realistic, but clearly defined, operational parameters, is really important.  After looking at your materials from the Spring I am certain that you have been headed in the same general direction.

I’d like to suggest that we work together to come up with something that we can all use as a “standard test set” of sorts for interoperability testing in CCSDS, the Lunar missions, the IOAG, and the DTN WG and Project work.

Does this make sense to you?

We can setup a Teams session to discuss it if you wish.

Thanks, Peter

Peter Shames

Consultative Committee for Space Data Systems (CCSDS)

Systems Engineering Area Director

Jet Propulsion Laboratory / Interplanetary Network Directorate

4800 Oak Grove Drive

MS 301-490

Pasadena, CA 91109

peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>

C: 818-687-7901

https://cwe.ccsds.org/sea/default.aspx [urldefense.us]<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Furldefense.com*2Fv3*2F__https*3A*2F*urldefense.us*2Fv3*2F__https*3A*2Fcwe.ccsds.org*2Fsea*2Fdefault.aspx__*3B!!PvBDto6Hs4WbVuu7!fgncIVD-iu0I_1xWlmq78lUqf1aK_WZzB2gUhx7cfOlLefMQluIGVhXTKIrzYkYoUsYraXcV*24__*3B!!NFAdMAnI0yk!H8i3lhzIm5T2_vAWUlD9aZ4jdFJkiLKEo6TY5rhmYqGJMlSXeQU5MkPFGhdA0ooyyiDNcLqtLkger5y5J0x2nxMG3rb5euhfsA*24__*3BLw!!PvBDto6Hs4WbVuu7!M3hx-gQKadtip7PtmfxlL8z58LfACI9zMAJXIEhq5WmUyUD2hsvo62WZAtcstqRDytgqz7anlfKTl6b0LDC27tGdHuzZhGHe*24&data=05*7C02*7Cjordan.l.torgerson*40jpl.nasa.gov*7C7d7b3d4099b443ef89ec08dcf2c7f4f4*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C638652187896759567*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C0*7C*7C*7C&sdata=vhe*2FlDxGvrP6eAMjSNGsFtwL8C6xDLu7tl17rVqVB94*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!LG2BbHqRYXo1cEK0FTBkZ8l3Ngk3cucv4bGOhFgCL7c3vfVrCLK4B3ZwYIaRl-WLCjxnV1aMradegYiYrQEkQdN9bISe$>

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Date: Monday, May 20, 2024 at 2:55 PM
To: Jim Schier <james.schier-1 at nasa.gov<mailto:james.schier-1 at nasa.gov>>
Cc: Lichten, Stephen M (US 9000) <stephen.m.lichten at jpl.nasa.gov<mailto:stephen.m.lichten at jpl.nasa.gov>>, Wyatt, E Jay (US 9730) <e.jay.wyatt at jpl.nasa.gov<mailto:e.jay.wyatt at jpl.nasa.gov>>, Asmar, Sami W (US 9100) <sami.w.asmar at jpl.nasa.gov<mailto:sami.w.asmar at jpl.nasa.gov>>, Pham, Timothy T (US 3300) <timothy.t.pham at jpl.nasa.gov<mailto:timothy.t.pham at jpl.nasa.gov>>, Gladden, Roy E (US 4074) <roy.e.gladden at jpl.nasa.gov<mailto:roy.e.gladden at jpl.nasa.gov>>
Subject: Some notes about a "test jig" for testing / evaluating DTN implementations

Jim,

The following notes were a result of talking to: Roy Gladden, Steve Lichten, Erik Barkley, Marc Blanchet, Bob Durst, Jay Wyatt, Ed Birrane, Leigh Torgerson, and others during the last few weeks.  What occurred to me is that we need to do four things vis-à-vis DTN “testing”;

Define at least one “standard deployment” configuration as a configured “test jig”.  Could be two (or more), but one should be mandatory.

Define not just the deployed elements, but also a “realistic” set of mission orbits, distance/delay, connectivity, and timing parameters.  Use something “Mars-like”, rather than the Moon to make demonstrating end-to-end reliability more challenging.

Define a realistic set of data to be transmitted, during a realistic period of time, using a realistic set of orbit & contact parameters. Not just ‘tiny-grams” but a data set with some heft and duration, and a scenario that crosses orbital contact boundaries.

Specify that all implementations must demonstrate correct operations (including interoperability with an agreed set of S/W) using these configurations, and use this same test jig to evaluate end-to-end throughput, reliability, and complete delivery in a realistic scenario.

I initially proposed this to Marc Blanchet when he was proposing his QUIC protocol.  I wanted to make sure that he was testing under realistic conditions, with otherwise realistic mission parameters, not just easy to retransmit tiny-grams.  He suggested that everyone should use the same set of test parameters, hence …

What I really was proposing is that we, collectively, agree upon at least one “nominal” Mars Relay, end-to-end, configuration, that we all test against.  This would have to include some specific, agreed, set of deployment configuration(s) as well as ”realistic” mission and data set parameters.   I chose Mars because if we say we are doing something that is “Mars-forward, it really ought to be demonstrated with RTLT delays of minutes, not a second or two.  I’d allow use of 10 minutes, or even, maybe, just one minute, but not 1-2 seconds.  If there are issues we want them to be big enough to be seen.

Define a config that looks like a “real” Mars E2E relay deployment (could even have a “KPLO-like” deployment, but …):

Relay user MOC on Earth

Relay provider MOC on Earth

A ground station on Earth

A Mars relay provider S/C (RTT 10 minutes to Earth, really more, but …)

A Mars relay user S/C (RTT 1 sec, Mars to Relay)

Send a traffic stream that consists of a mix of the following:

Return data rate of 1 mbps

Forward data rate of 2 kbps (or more if you wish)

Return 1 KB “data blobs” (1,000,000 or so of them)

Use 5% error rate / frame loss, randomly, on the long space link

Then, repeat the same test for the following:

10 KB “data blob” (100,000 of them)

100 KB “data blob” (10,000 of them)

1 MB “data blob” (1000 of them)

10 MB “data blob” (100 of them)

Maybe even a mix of large & small, interspersed in some defined pattern

I think those are realistic data rates and frame sizes from Mars.  The (data rate * #frames) should provide an equivalent total E2E transport volume for each option if my math is right, so the total data volume should be the same.  I’ll be especially interested to see what happens to end-to-end throughput and total latency with these different “data blob” sizes.  BTW, I’m using the term “data blob”, but what I really mean is something like a user file or data object that has to be transmitted end-to-end reliably and completely,  as an entity.  Frame loss assumes that each frame, which are the segmented parts of the “blob”, are what is lost, but one frame loss effectively means that the whole blob needs to be retransmitted.

There are, of course, all sorts of possible variants on this base deployment config and “mission data set”.  First of all, these numbers may not even be right, so maybe someone else (like Gladden) has a better idea of what a “right” baseline config would be more realistic.  I think we would want to include aspects like length of contact between the relay user S/C and the relay provider S/C, like 10 minutes out of an hour (you tell me what is right)?  We could configure multiple relay S/C to see that effect, but I think we need to start with the basics of one relay S/C and see what works and what breaks.

I propose something like this as a canonical “test jig” that everyone has to use.   For both performance tests and for interoperability.

I propose that we make this “realistic enough”, and require that every proposed implementation use it as a “test jig”.  Setup the deployment, run the tests, and report the results.  Run it without link errors / loss, and with link errors / loss.  Run it for a defined period of time that includes orbital events and loss/regain of signal.  Run it for a “realistic” standard set of data products, ranging from small to large.  Record overall throughput, and require that they report timing for 100% end-to-end data delivery, including all retransmissions.

Of course the JPL PTL that Leigh runs could play a role in this.  It might even make sense to have it provide a “canonical test jig” of a MOC, ground station, and relay S/C that others could test against.  This would use ION, but it might be that other implementations than ION would also want to be tested, either as a space (relay or user) node, or as an Earth or ground station node.  So other implementations should be able to be deployed and tested using this test jig.

Now do you get what I have in mind?  A sort of agreed framework against which we could compare any and all implementations.  Do they reliably delivery data end-to-end?  What performance do they deliver?  How do they handle errors, retransmission, and outages?  And it could be used as a yardstick for interoperability tests too.

This could be stated as an IOAG “test jig”, or it could just be stated as a fixed set of interoperability and performance requirements that every implementation has to report upon.  I think there are a lot of potential uses.

Cheers, Peter

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<mailto:dpo at esa.int>).

'NOTICE: This email message and all attachments transmitted with it may contain privileged and confidential information, and information that is protected by, and proprietary to, Parsons Corporation, and is intended solely for the use of the addressee for the specific purpose set forth in this communication. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited, and you should delete this message and all copies and backups thereof. The recipient may not further distribute or use any of the information contained herein without the express written authorization of the sender. If you have received this message in error, or if you have any questions regarding the use of the proprietary information contained therein, please contact the sender of this message immediately, and the sender will provide you with further instructions.'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20241022/b4d5cbf0/attachment-0001.htm>