[CSS-CLOUD] [EXTERNAL] Offer different encodings?

[Barkley, Erik J (US 3970)]

Wes,

Thanks for the input.

For telemetry I tend to have the presumption that we are dealing with CCSDS telemetry frame formats and presumably processing for this is already well understood by missions in general.  Taking a look at the Roman draft ICD that Holger forwarded, as an example use case, it appears that what is being delivered  are AOS TLM frames with 32 bytes worth of annotation data added just prior to the start of each frame. This seems a lot like the SLE PDU just perhaps organized differently.  From the DLR example that Marcin sent, it looks like 38 bytes (if I interpret correctly) of "fixed" header and then an optional variable header and then the frame.  So perhaps it is just the ancillary annotation data that we are thinking about having in potentially different encoding schemes?

I think this tends to confirm that we should dedicate some time at the next telecon to discuss ASN.1 vs. other encoding schemes.  Of course, if anyone has any comments prior to the next teleconference that course would also be welcome.

Best regards,
-Erik

From: Eddy, Wesley M. (GSFC-580.0)[MTI SYSTEMS, INC.] <wesley.m.eddy at nasa.gov>
Sent: Saturday, November 26, 2022 9:02
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; css-cloud at mailman.ccsds.org
Subject: RE: [EXTERNAL] [CSS-CLOUD] Offer different encodings?

Since the bodies can essentially be binary data, this may make require some deal of gymnastics for certain encodings that are less suited for carrying binary data (e.g. JSON).


From: CSS-CLOUD <css-cloud-bounces at mailman.ccsds.org<mailto:css-cloud-bounces at mailman.ccsds.org>> On Behalf Of Barkley, Erik J (US 3970) via CSS-CLOUD
Sent: Tuesday, November 22, 2022 7:25 PM
To: css-cloud at mailman.ccsds.org<mailto:css-cloud at mailman.ccsds.org>
Subject: [EXTERNAL] [CSS-CLOUD] Offer different encodings?

Dear Cloud BOF Colleagues,

Part of the standards shaping we discussed at the Toulouse meetings was involved with not necessarily using ASN.1 encoding for producing files of SLE PDUs or streaming data or streaming the SLE PDUs. Part of our discussion about that was deliberating a little bit as to possible alternative encodings such as JSON, XML, or perhaps something else. It occurs to me, and this may be just a brain fart, that maybe we don't have to really indicate any one particular encoding.  Given that the telemetry frames are going into the cloud, it seems that whatever gymnastic/processing is needed can be applied in the cloud for producing whatever encoding is desired. So maybe it's not so much that we would have to choose one encoding but we could indicate some possible alternatives as part of the standardization effort. Taking telemetry as an example, I think this would mean that we would have standard CCSDS telemetry frames going into the cloud computing infrastructure and then it would perhaps be a matter of choice among some different precooked encoding schemes for delivery to the mission operations center. I do know, as an analogy, that for some of the APIs in the DSN there is an option of essentially throwing a switch in the  ReST API to have data returned as XML or have it returned as JSON -- it is something like this that I'm thinking about. I would like to ask for a sanity check - do you think something like this makes sense? I would be interested in hearing any comments you may have. I realize that on the one hand this might be seen as "diluting" a potential standard by setting it scope a little too broadly, but then at the same time it may help with increasing infusion albeit at the cost of a few options. Perhaps we can discuss this at our next teleconference.

Best regards,
-Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-cloud/attachments/20221128/b3264755/attachment.htm>