[Ccsds-omg-liaison] Initial AB Review: Ground Data Delivery Interface (GDDI) RFP

Fri Dec 2 20:40:49 UTC 2022

I posted this updated draftRFP as space/2022-12-01 at
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fcgi-bin%2Fdoc%3Fspace%2F2022-12-01&data=05%7C01%7Cspace%40omg.org%7Ca821f1de3a4546d28c8a08dad4a58215%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638056104553989813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5HtMZQUeviUcrUSi7p7w7omgoeHRmbgZ1piliMkO97c%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fcgi-bin%2Fdoc%3Fspace%2F2022-12-01&data=05%7C01%7Cspace%40omg.org%7Ca821f1de3a4546d28c8a08dad4a58215%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638056104553989813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5HtMZQUeviUcrUSi7p7w7omgoeHRmbgZ1piliMkO97c%3D&reserved=0>

Header and cover page have been updated accordingly

-Juergen

Jürgen Boldt
Boston, MA, USA UTC-05
From: J Boss <wkbrd.stds at gmail.com>
Sent: Friday, December 2, 2022 3:10 PM
To: Manfred Koethe <koethe at 88solutions.com>
Cc: Justin.Boss at kratosdefense.com; space at omg.org; ab at omg.org; eric.orgren at kratosdefense.com; Jason McC. Smith <jason at omg.org>; Jürgen Boldt <juergen at omg.org>
Subject: Re: Initial AB Review: Ground Data Delivery Interface (GDDI) RFP

Hi all,

An updated GDDI RFP is attached that addresses feedback received.  Please review this updated version with track changes enabled for easier review.

@Juergen, please upload this to the document store.

Thanks all,

Justin Boss

On Thu, Nov 24, 2022 at 6:31 PM Manfred Koethe <koethe at 88solutions.com<mailto:koethe at 88solutions.com>> wrote:
Hi Justin,

Here is my initial AB review of the Ground Data RFP

Reviewed document: space/2022-11-01

To say it up-front: I strongly believe this RFP is not yet ready for issuance,
and I'm not confident that all the problems could be fixed until the final
AB review on December 8, 2022.

There are two areas of problems with this RFP, which include even the
question if there is a need for this RFP, or if there are already OMG
technologies available that cover the described need. These are
the problem areas I see:

1. Formal appearance problems
2. Technical problems

1. Formal appearance problems

The Objective section is fine.
Section 6.1 is acceptable, it paints a reasonable picture of the needs,
except that the Figure 1 lists a lot of things, but does not give a clear
picture what you want to address with this RFP, and how.

Section 6.2 is the section where an RFP is supposed to describe the
solicited technology in plain words, but in this RFP Section 6.2 is very
vague. Also, if you are really looking forward to define a new low-level
TCP/IP protocol, then you are barking up the wrong tree. Defining
low-level networking protocols is the domain of the IETF, protocols
defined by OMG specifications are all Application-level Protocols.
More regarding this under "2. Technical problems" below.

Section 6.3 is very unclear and not in the propper format. You need to
make clear references to specification required as mandatory readings
by the prospective submitters. Each of these refferences shall have a
short paragraph explaining the relevance, but withiout any prejudice.
You are nowhere specifying what you really want. What technology
shall be used to specify the "interfaces" (IDL? UML Data Models?
MOF Metamodels? XML Schema? JSON Schema?...), therefore
Section 6.3 lacks crucial references to one or more of those defining
technologies.

Section 6.4 has more references, but all references are very vague,
except for the last four lines of Section 6.4.

Section 6.5 Mandatory Requirements.
It is very unclear what the RFP is really requiring here. All requirements
are either too vague or even out of scope (like requirement #11) . It is
unclear what technology is expected (IDL, UML, ....??) and if the RFP is
just soliciting data formats, or data-describing metamodels.

Section 6.6 Non-Mandatory Features.
The RFP requests TCP already in the Mandatory Requirements, why
including this again in the Non-Mandatory Features?

Section 6.7 Issues to be discussed
Only #3 makes sense here. This section is not for stating how requirements
are satisfied, this section provides a forum for the submitters to argue why
they choose a certain solution.

Section 6.8 Evaluation Criteria
Tere is only the default stuff listed here, but what are the technology-specifc
criteria to evaluate one submission against another, if there are many? How
will you judge if a submission is satifying the RFP at all?

Section 6.10 IPR Mode
Why RF-Limited? This ia an RFP for a new specification without history, wouldn't
Non-Assert be more appropriate?

Section 6.11 Time Table
Your time table is way too agressive. You need to provide more time for initial and
revised submission. You can always deliver earlier, nobody has been punished
by the OMG for that...

Now the more difficult part of my review:

2. Technical problems

Let me say upfront that I have past  expereince in distributed systems and
implementing high performance network stacks.

I think your RFP should not try to invent yet another networking protocol, or
even a new middleware technology. So forget about specifying a protocol
directly IP, or even TCP level. With the current aim to make the low levels of
networks as secure as possible, introducing a new protocol on that low level
creates an unnecessary up-hill battle. An application-level protocol, if done
right, can fulfill all your anticipated transfer rates, easily.

I have a concern that you asked in one requirment for connection-less trasmission.
This is the wrong approach, in my humble opinion. Connection-less streams are
not neccessarily faster than well-designed connection-oriented streams, but
take away all mechanisms of low-level (and therefore efficieint) error detection
and handling. Connection-less streams may be fine for video image streams,
where there is only little difference between one frame to the next (so you can
recover fairly easily). But the lossyniess of connection-less streams is fatal for
precious scientific data.

In summary, what you should ask for in this RFP is the specification of a
metamodel system describing the transferred data and embedded metadata,
and leave the actual transmission to proven middleware, lilke for example DDS.
In that respect you should read the "DDS Extension for Time-Sensitive Networking"
submission, up for adoption at the Austin meeting this December. I think this
technology provides you withe the searched-for rapid trasmisson capabilities.

Then regarding the descriptive metamode, what is so wrong with wht C2MS already
provides?

In summary, this RFP needs a lot more discussion. Sorry.

Kind regards,

Manfred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/ccsds-omg-liaison/attachments/20221202/dc7a690b/attachment-0001.htm>