[Sis-dtn] Fwd: [EXTERNAL] Re: DTN Comm "Scenarios"

Wed Oct 2 08:22:54 UTC 2024

Information from Leigh Torgerson at JPL.

---------- Forwarded message ---------
From: Torgerson, J. Leigh (US 332C) <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>, Howard.Weiss at parsons.us <
Howard.Weiss at parsons.us>, Shames, Peter M (US 312B) <
peter.m.shames at jpl.nasa.gov>, Keith Scott (keithlscott at gmail.com) <
keithlscott at gmail.com>, Howie Weiss (Howard.Weiss at parsons.com) <
Howard.Weiss at parsons.com>, Bob Durst (durst at mitre.org) <durst at mitre.org>,
Radulescu, Costin (US 9300) <cradule at jpl.nasa.gov>, EXTERNAL-Birrane,
Edward J (US 9300-Affiliate) <Edward.Birrane at jhuapl.edu>
Cc: Asmar, Sami W (US 9100) <sami.w.asmar at jpl.nasa.gov>, Pham, Timothy T
(US 3300) <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>
*Date: *Tuesday, October 1, 2024 at 6:26 AM
*To: *"Howard.Weiss at parsons.us" <Howard.Weiss at parsons.us>, "Shames, Peter M
(US 312B)" <peter.m.shames at jpl.nasa.gov>, "Keith Scott (
keithlscott at gmail.com)" <keithlscott at gmail.com>, Howie Weiss <
Howard.Weiss at parsons.com>, "Bob Durst (durst at mitre.org)" <durst at mitre.org>,
"Radulescu, Costin (US 9300)" <cradule at jpl.nasa.gov>, "Torgerson, Jordan L
(332M)" <jordan.l.torgerson at jpl.nasa.gov>, "EXTERNAL-Birrane, Edward J (US
9300-Affiliate)" <Edward.Birrane at jhuapl.edu>
*Cc: *"Asmar, Sami W (US 9100)" <sami.w.asmar at jpl.nasa.gov>, "Pham, Timothy
T (US 3300)" <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://aka.ms/o0ukef>
------------------------------

*From:* Howard.Weiss at parsons.us <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>; Keith Scott (
keithlscott at gmail.com) <keithlscott at gmail.com>; Howie Weiss (
Howard.Weiss at parsons.com) <Howard.Weiss at parsons.com>; Bob Durst (
durst at mitre.org) <durst at mitre.org>; Radulescu, Costin (US 9300) <
cradule at jpl.nasa.gov>; Torgerson, J. Leigh (US 332C) <
jordan.l.torgerson at jpl.nasa.gov>; EXTERNAL-Birrane, Edward J (US
9300-Affiliate) <Edward.Birrane at jhuapl.edu>
*Cc:* Asmar, Sami W (US 9100) <sami.w.asmar at jpl.nasa.gov>; Lux, Jim (US
3370) <james.p.lux at jpl.nasa.gov>; Pham, Timothy T (US 3300) <
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>
*Sent:* Monday, September 30, 2024 2:32 PM
*To:* Keith Scott (keithlscott at gmail.com) <keithlscott at gmail.com>; Howie
Weiss (Howard.Weiss at parsons.com) <Howard.Weiss at parsons.com>; Bob Durst (
durst at mitre.org) <durst at mitre.org>; Radulescu, Costin (US 9300) <
cradule at jpl.nasa.gov>; Torgerson, J. Leigh (US 332C) <
jordan.l.torgerson at jpl.nasa.gov>; EXTERNAL-Birrane, Edward J (US
9300-Affiliate) <Edward.Birrane at jhuapl.edu>
*Cc:* Asmar, Sami W (US 9100) <sami.w.asmar at jpl.nasa.gov>; Lux, Jim (US
3370) <james.p.lux at jpl.nasa.gov>; Pham, Timothy T (US 3300) <
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>
*Date: *Monday, September 30, 2024 at 7:28 AM
*To: *Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>, Camillo
Malnati <Camillo.Malnati at ext.esa.int>
*Cc: *Tomaso de Cola <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>
*Sent:* Saturday, September 28, 2024 2:27 AM
*To:* Felix Flentge <Felix.Flentge at esa.int>; Camillo Malnati <
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

C: 818-687-7901

https://cwe.ccsds.org/sea/default.aspx [urldefense.us]
<https://urldefense.us/v3/__https:/urldefense.com/v3/__https:/*urldefense.us/v3/__https:/cwe.ccsds.org/sea/default.aspx__;!!PvBDto6Hs4WbVuu7!fgncIVD-iu0I_1xWlmq78lUqf1aK_WZzB2gUhx7cfOlLefMQluIGVhXTKIrzYkYoUsYraXcV$__;!!NFAdMAnI0yk!H8i3lhzIm5T2_vAWUlD9aZ4jdFJkiLKEo6TY5rhmYqGJMlSXeQU5MkPFGhdA0ooyyiDNcLqtLkger5y5J0x2nxMG3rb5euhfsA$__;Lw!!PvBDto6Hs4WbVuu7!M3hx-gQKadtip7PtmfxlL8z58LfACI9zMAJXIEhq5WmUyUD2hsvo62WZAtcstqRDytgqz7anlfKTl6b0LDC27tGdHuzZhGHe$>

*From: *Shames, Peter M (US 312B) <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>
*Cc: *Lichten, Stephen M (US 9000) <stephen.m.lichten at jpl.nasa.gov>, Wyatt,
E Jay (US 9730) <e.jay.wyatt at jpl.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>, Gladden, Roy E (US 4074) <
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).

'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/20241002/1f74118d/attachment-0001.htm>