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





<div lang="EN-US" link="#467886" vlink="purple" style="word-wrap:break-word">
<div class="m_53527983692018366WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">More info for the CCSDS team:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Lunar Delay:<u></u><u></u></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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..)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Deep space delay:<u></u><u></u></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Testing with GRC, since Howie brought it up:<u></u><u></u></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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..<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Leigh<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif;color:black">From:
</span></b><span style="font-family:"Calibri",sans-serif;color:black">"Lux, Jim (US 3370)" <<a href="mailto:james.p.lux@jpl.nasa.gov" target="_blank">james.p.lux@jpl.nasa.gov</a>><br>
<b>Date: </b>Tuesday, October 1, 2024 at 6:26 AM<br>
<b>To: </b>"<a href="mailto:Howard.Weiss@parsons.us" target="_blank">Howard.Weiss@parsons.us</a>" <<a href="mailto:Howard.Weiss@parsons.us" target="_blank">Howard.Weiss@parsons.us</a>>, "Shames, Peter M (US 312B)" <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>, "Keith Scott (<a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a>)" <<a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a>>, Howie Weiss <<a href="mailto:Howard.Weiss@parsons.com" target="_blank">Howard.Weiss@parsons.com</a>>, "Bob Durst (<a href="mailto:durst@mitre.org" target="_blank">durst@mitre.org</a>)" <<a href="mailto:durst@mitre.org" target="_blank">durst@mitre.org</a>>,
 "Radulescu, Costin (US 9300)" <<a href="mailto:cradule@jpl.nasa.gov" target="_blank">cradule@jpl.nasa.gov</a>>, "Torgerson, Jordan L (332M)" <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">jordan.l.torgerson@jpl.nasa.gov</a>>, "EXTERNAL-Birrane, Edward J (US 9300-Affiliate)" <<a href="mailto:Edward.Birrane@jhuapl.edu" target="_blank">Edward.Birrane@jhuapl.edu</a>><br>
<b>Cc: </b>"Asmar, Sami W (US 9100)" <<a href="mailto:sami.w.asmar@jpl.nasa.gov" target="_blank">sami.w.asmar@jpl.nasa.gov</a>>, "Pham, Timothy T (US 3300)" <<a href="mailto:timothy.t.pham@jpl.nasa.gov" target="_blank">timothy.t.pham@jpl.nasa.gov</a>><br>
<b>Subject: </b>Re: [EXTERNAL] Re: DTN Comm "Scenarios"<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">Delays wise I’m pretty sure Leigh has that capability in the protocol test lab at JPL<u></u><u></u></p>
</div>
</div>
<div id="m_53527983692018366ms-outlook-mobile-signature">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">Get <a href="https://aka.ms/o0ukef" target="_blank">Outlook for iOS</a><u></u><u></u></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" align="center">
</div>
<div id="m_53527983692018366divRplyFwdMsg">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> <a href="mailto:Howard.Weiss@parsons.us" target="_blank">Howard.Weiss@parsons.us</a> <<a href="mailto:Howard.Weiss@parsons.us" target="_blank">Howard.Weiss@parsons.us</a>><br>
<b>Sent:</b> Tuesday, October 1, 2024 5:50:54 AM<br>
<b>To:</b> Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>; Keith Scott (<a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a>) <<a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a>>; Howie Weiss (<a href="mailto:Howard.Weiss@parsons.com" target="_blank">Howard.Weiss@parsons.com</a>) <<a href="mailto:Howard.Weiss@parsons.com" target="_blank">Howard.Weiss@parsons.com</a>>; Bob Durst (<a href="mailto:durst@mitre.org" target="_blank">durst@mitre.org</a>) <<a href="mailto:durst@mitre.org" target="_blank">durst@mitre.org</a>>; Radulescu, Costin
 (US 9300) <<a href="mailto:cradule@jpl.nasa.gov" target="_blank">cradule@jpl.nasa.gov</a>>; Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">jordan.l.torgerson@jpl.nasa.gov</a>>; EXTERNAL-Birrane, Edward J (US 9300-Affiliate) <<a href="mailto:Edward.Birrane@jhuapl.edu" target="_blank">Edward.Birrane@jhuapl.edu</a>><br>
<b>Cc:</b> Asmar, Sami W (US 9100) <<a href="mailto:sami.w.asmar@jpl.nasa.gov" target="_blank">sami.w.asmar@jpl.nasa.gov</a>>; Lux, Jim (US 3370) <<a href="mailto:james.p.lux@jpl.nasa.gov" target="_blank">james.p.lux@jpl.nasa.gov</a>>; Pham, Timothy T (US 3300) <<a href="mailto:timothy.t.pham@jpl.nasa.gov" target="_blank">timothy.t.pham@jpl.nasa.gov</a>><br>
<b>Subject:</b> [EXTERNAL] Re: DTN Comm "Scenarios"</span> <u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">Peter<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">+1- </span><span style="font-family:"Arial",sans-serif;color:black"></span><span style="color:black">makes a lot of sense. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">regards<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">howie<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" align="center">
</div>
<div id="m_53527983692018366x_divRplyFwdMsg">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>><br>
<b>Sent:</b> Monday, September 30, 2024 2:32 PM<br>
<b>To:</b> Keith Scott (<a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a>) <<a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a>>; Howie Weiss (<a href="mailto:Howard.Weiss@parsons.com" target="_blank">Howard.Weiss@parsons.com</a>) <<a href="mailto:Howard.Weiss@parsons.com" target="_blank">Howard.Weiss@parsons.com</a>>; Bob Durst (<a href="mailto:durst@mitre.org" target="_blank">durst@mitre.org</a>) <<a href="mailto:durst@mitre.org" target="_blank">durst@mitre.org</a>>; Radulescu, Costin (US 9300) <<a href="mailto:cradule@jpl.nasa.gov" target="_blank">cradule@jpl.nasa.gov</a>>; Torgerson, J. Leigh
 (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">jordan.l.torgerson@jpl.nasa.gov</a>>; EXTERNAL-Birrane, Edward J (US 9300-Affiliate) <<a href="mailto:Edward.Birrane@jhuapl.edu" target="_blank">Edward.Birrane@jhuapl.edu</a>><br>
<b>Cc:</b> Asmar, Sami W (US 9100) <<a href="mailto:sami.w.asmar@jpl.nasa.gov" target="_blank">sami.w.asmar@jpl.nasa.gov</a>>; Lux, Jim (US 3370) <<a href="mailto:james.p.lux@jpl.nasa.gov" target="_blank">james.p.lux@jpl.nasa.gov</a>>; Pham, Timothy T (US 3300) <<a href="mailto:timothy.t.pham@jpl.nasa.gov" target="_blank">timothy.t.pham@jpl.nasa.gov</a>><br>
<b>Subject:</b> [EXTERNAL] FW: DTN Comm "Scenarios"</span> <u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt">Guys,</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt">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. 
</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt">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?</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt">Cheers, Peter</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<div id="m_53527983692018366x_x_mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="m_53527983692018366xxmsonormal" style="margin-bottom:12.0pt"><b><span lang="EN-GB" style="font-size:12.0pt;color:black">From:
</span></b><span lang="EN-GB" style="font-size:12.0pt;color:black">Felix Flentge <<a href="mailto:Felix.Flentge@esa.int" target="_blank">Felix.Flentge@esa.int</a>><br>
<b>Date: </b>Monday, September 30, 2024 at 7:28</span><span lang="EN-GB" style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"> </span><span lang="EN-GB" style="font-size:12.0pt;color:black">AM<br>
<b>To: </b>Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>, Camillo Malnati <<a href="mailto:Camillo.Malnati@ext.esa.int" target="_blank">Camillo.Malnati@ext.esa.int</a>><br>
<b>Cc: </b>Tomaso de Cola <<a href="mailto:Tomaso.deCola@dlr.de" target="_blank">Tomaso.deCola@dlr.de</a>><br>
<b>Subject: </b>[EXTERNAL] RE: DTN Comm "Scenarios"</span><u></u><u></u></p>
</div>
<div>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt">Hi Peter,</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt">Yes, this absolutely makes sense and has been our intention from the beginning.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt">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 ...</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt">What is important from our point of view</span><u></u><u></u></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="m_53527983692018366xxmsolistparagraph" style="margin-left:0in"><span lang="EN-GB" style="font-size:11.0pt">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).</span><u></u><u></u></li><li class="m_53527983692018366xxmsolistparagraph" style="margin-left:0in"><span lang="EN-GB" style="font-size:11.0pt">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.</span><u></u><u></u></li></ol>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt">I have attached the current status of our scenarios. I would hope that we have something almost complete by the fall meetings.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt"> </span><u></u><u></u></p>
<div>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt">Regards,</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt">Felix</span><u></u><u></u></p>
</div>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:11.0pt"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>
<br>
<b>Sent:</b> Saturday, September 28, 2024 2:27 AM<br>
<b>To:</b> Felix Flentge <<a href="mailto:Felix.Flentge@esa.int" target="_blank">Felix.Flentge@esa.int</a>>; Camillo Malnati <<a href="mailto:Camillo.Malnati@ext.esa.int" target="_blank">Camillo.Malnati@ext.esa.int</a>><br>
<b>Subject:</b> DTN Comm "Scenarios"</span><u></u><u></u></p>
</div>
</div>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span lang="EN-GB" style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">Hi Felix and Camillo,</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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. 
</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">Does this make sense to you?</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">We can setup a Teams session to discuss it if you wish.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">Thanks, Peter</span><u></u><u></u></p>
<div>
<div style="border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in">
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> </span><u></u><u></u></p>
</div>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;color:#212121"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Peter Shames</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Consultative Committee for Space Data Systems (CCSDS)</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Systems Engineering Area Director</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Jet Propulsion Laboratory / Interplanetary Network Directorate</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">4800 Oak Grove Drive</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">MS 301-490</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Pasadena, CA 91109</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"><a href="mailto:peter.m.shames@jpl.nasa.gov" title="mailto:peter.m.shames@jpl.nasa.gov" target="_blank"><span style="color:#0563c1">peter.m.shames@jpl.nasa.gov</span></a></span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">C: 818-687-7901</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"><a href="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$" title="https://urldefense.us/v3/__https:/cwe.ccsds.org/sea/default.aspx__;!!PvBDto6Hs4WbVuu7!fgncIVD-iu0I_1xWlmq78lUqf1aK_WZzB2gUhx7cfOlLefMQluIGVhXTKIrzYkYoUsYraXcV$" target="_blank"><span style="color:#0563c1">https://cwe.ccsds.org/sea/default.aspx</span>
 [urldefense.us]</a></span><u></u><u></u></p>
<div style="border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in">
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt;color:#212121"> </span><u></u><u></u></p>
</div>
</div>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><b><span style="font-size:11.0pt">From: </span></b><span style="font-size:11.0pt">Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>><br>
<b>Date: </b>Monday, May 20, 2024 at 2:55</span><span style="font-size:11.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:11.0pt">PM<br>
<b>To: </b>Jim Schier <<a href="mailto:james.schier-1@nasa.gov" target="_blank">james.schier-1@nasa.gov</a>><br>
<b>Cc: </b>Lichten, Stephen M (US 9000) <<a href="mailto:stephen.m.lichten@jpl.nasa.gov" target="_blank">stephen.m.lichten@jpl.nasa.gov</a>>, Wyatt, E Jay (US 9730) <<a href="mailto:e.jay.wyatt@jpl.nasa.gov" target="_blank">e.jay.wyatt@jpl.nasa.gov</a>>, Asmar, Sami W (US 9100) <<a href="mailto:sami.w.asmar@jpl.nasa.gov" target="_blank">sami.w.asmar@jpl.nasa.gov</a>>,
 Pham, Timothy T (US 3300) <<a href="mailto:timothy.t.pham@jpl.nasa.gov" target="_blank">timothy.t.pham@jpl.nasa.gov</a>>, Gladden, Roy E (US 4074) <<a href="mailto:roy.e.gladden@jpl.nasa.gov" target="_blank">roy.e.gladden@jpl.nasa.gov</a>><br>
<b>Subject: </b>Some notes about a "test jig" for testing / evaluating DTN implementations</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">Jim,</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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”;</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">Define at least one “standard deployment” configuration as a configured “test jig”.  Could be two (or more), but one should be mandatory.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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 …</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">Define a config that looks like a “real” Mars E2E relay deployment (could even have a “KPLO-like” deployment, but …):</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">Relay user MOC on Earth</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">Relay provider MOC on Earth</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">A ground station on Earth</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">A Mars relay provider S/C (RTT 10 minutes to Earth, really more, but …)</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">A Mars relay user S/C (RTT 1 sec, Mars to Relay)</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">Send a traffic stream that consists of a mix of the following:</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">Return data rate of 1 mbps</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">Forward data rate of 2 kbps (or more if you wish)</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">Return 1 KB “data blobs” (1,000,000 or so of them)</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">Use 5% error rate / frame loss, randomly, on the long space link</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">Then, repeat the same test for the following:</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">10 KB “data blob” (100,000 of them)</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">100 KB “data blob” (10,000 of them)</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">1 MB “data blob” (1000 of them)</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">10 MB “data blob” (100 of them)</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:1.0in"><span style="font-size:11.0pt">Maybe even a mix of large & small, interspersed in some defined pattern</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.   </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">I propose something like this as a canonical “test jig” that <b><i>everyone</i></b> has to use.   For both performance tests and for interoperability.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt">Cheers, Peter</span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
<p class="m_53527983692018366xxmsonormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><u></u><u></u></p>
</div>
<p class="m_53527983692018366xxmsonormal"><span lang="EN-GB" style="font-size:12.0pt">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 (<a href="mailto:dpo@esa.int" target="_blank">dpo@esa.int</a>).
</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Franklin Gothic Book",sans-serif">'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.'<u></u><u></u></span></p>
</div>
</div>
</div>
</div>

</div></div></div></div>