[Sls-slp] “Maximum number of transfer frames given to the coding sublayer as a single data unit”

[Kazz, Greg (US 312B)]

Hi Marco and Andrea,
Thanks for the reply.
So far, agencies have only put one transfer frame into a CLTU. Also, no agency has changed the number of transfer frames per CLTU during a mission lifetime. So perhaps, CCSDS is providing too much flexibility in making the number of frames variable, when in fact, it’s always fixed and only one. Perhaps we should consider setting the Maximum number of frames to 1.
As far as security, NASA GSFC has decided to specify  the maximum number to be 1 transfer frame per CLTU. So my question changes somewhat. We can certainly discuss this in Hamburg or if you have more thoughts on this please let us know.
Thanks,
Greg

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of Marco Rovatti via SLS-SLP <sls-slp at mailman.ccsds.org>
Sent: Friday, August 15, 2025 8:55 AM
To: Kazz, Greg (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>
Subject: [EXTERNAL] Re: [Sls-slp] “Maximum number of transfer frames given to the coding sublayer as a single data unit”

Dear Greg,

Thank you for bringing this topic forward for discussion.
Andrea and I have a couple of considerations:
If the word maximum is removed from the definition, the notion regarding the existence of an upper bound is lost.
What will prevent the user to submit a number of TFs per single data unit higher than the one specified by this parameter?
In addition, since the number of TFs per CLTU remains variable, what will be the point in still keeping this parameter as a managed one? Said it differently, what will be the purpose of this modified MP?
Moreover, currently, the Max number of frame per CLTU MP, the max frame length MP and the 231.0 Maximum CLTU Length MP provide a set of constraints to the user to prevent inconsistent implementations.
We must be careful not to open the standard to let compliant but inconsistent implementations to sneak in.

I conclude with a question: how the modified MP will help in distinguishing one CLTU with some number of TFs with another CLTU with a different number of TFs in security applications?
We assume that the MP will be unique and fixed for each mission phase isn’t it?

Open for discussion
Cheers
Marco and Andrea



From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> On Behalf Of Kazz, Greg (US 312B) via SLS-SLP
Sent: 14 August 2025 22:52
To: Kazz, Greg (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] “Maximum number of transfer frames given to the coding sublayer as a single data unit”

Dear SLP WG,


Both the Telecommand SDLP  (232.0 Blue Book) and the USLP  (732.1 Blue Book) contain the same Managed Parameter (MP) under the MPs for a Physical Channel called, the

“Maximum number of transfer frames (TFs) given to the coding sublayer as a single data unit”.

In discussions at NASA, we find the word, Maximum to be problematic. This MP does not specify that the maximum is always used.  Just that there is a maximum.  Furthermore, at least in our security applications (Encyrption/Authenticated links), we have to be able to distinguish one CLTU with some number of TFs with another CLTU with a different number of TFs.

Ergo, NASA proposes we drop the word, “Maximum” from the MP name, and rename it to be: “The number of transfer frames given to the coding sublayer as a single data unit ."

Please let me know if you have any thoughts on this matter before the Fall meeting in Hamburg-Harburg.

In any case, let’s plan on discussing this topic as an agenda item at that upcoming SLP WG meeting, planned for Tuesday, Sept. 16, 2025.
N.B. The interoperability plenary is all day Monday, Sept. 15.

best regards,
Greg
Chair SLP WG

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20250815/d92014d2/attachment-0001.htm>