[Sls-slp] [EXTERNAL] USLP: Question from yesterday

Tue Nov 7 16:31:36 UTC 2023

Hello Greg and all,

thank you for your well-thought-out and detailed answer!

The all-ones-solution for the described edge case is logical and makes sense.

The only remaining issue (from my side) is, that another implementer told me yesterday that he couldn’t find the solution for this edge case in the book. Would it be devastating to add a sentence describing this case within the normative section behind 4.1.4.2.4.4, e.g. “When a packet started in a previous frame and ends at the last octet of the current TFDZ, completely filling the TFDZ, then the FHP shall be set to binary ‘all ones’.”?
Thank you and Best Regards
Stefan

PS: Of course, there is the large possibility that this case is covered implicitly somewhere in the book and my collegue and I just did not find it!

Von: Kazz, Greg (US 312B) <greg.j.kazz at jpl.nasa.gov>
Gesendet: Dienstag, 7. November 2023 13:30
An: Veit, Stefan <Stefan.Veit at dlr.de>; sls-slp at mailman.ccsds.org
Betreff: Re: [EXTERNAL] USLP: Question from yesterday

Hallo Stefan,

Thanks for your questions. They are always welcome. I always encourage everyone to think about “edge cases”.

4.4.1.2.3.4  When the value in the TFDZ construction rule is ‘000’ binary, and when no packet starts nor ends within the TFDZ, then the FHP shall be set to binary ‘all ones’.

We created USLP 4.1.4.2.3.4 to deal with the following issues:

  1.  When a packet spans multiple transfer frames, we need a way to identify to the user, that the FHP value can’t be used to find the start of the packet in that given frame, because the packet doesn’t start nor end in that given frame i.e., the frame contains the data portion of a packet.
  2.  No problem with saying, “when no packet starts within the Transfer Frame Data Zone (TFDZ)”, that is similar in logic to AOS SDLP.
  3.  Now, let’s examine the rest of the statement, “nor ends within the TFDZ”. This is where USLP goes beyond the logic specified by AOS SDLP. Because, AOS does not deal with the following: This part of the statement was written with the intent of eliminating the cases, in which a packet would end in the TFDZ, but there would be no mechanism available to the user to fill the remainder of the TFDZ, if the amount of fill is less than 7 octets in the case of SPP, or less than 1 octet in the case on EPP.  If one uses SPP (Space Packets), then the smallest Space Packet that could be used to fill out the remainder of the TFDZ would be 7 octets (6 octets of Primary Header plus 1 octet of data). This minimum size is the mandatory minimum per the Space Packet Protocol. As far as I know, all CCSDS agencies still exclusively use the Space Packet and do not implement encapsulation packets. Now, if one chooses to use Encapsulation Packets as the fill packet mechanism, then the minimum size is 1 byte per the Encap Packet Protocol (1 byte header only). Also one can use multiples of that 1 byte Encap packet to fill out the remainder of the TFDZ.
  4.  Given all of points 1 through 3 for background, let’s tackle your specific case, “when a packet started in a previous frame and ends exactly at the end of the current TFDZ, filling it completely”. So in this frame no packet starts, so the FHP value does not have a legitimate value, so we use the ‘all ones’ convention to convey that meaning. That is the correct behaviour for setting the FHP. The fact that the packet ends in that TFDZ means that the user has nothing more to do with this frame, i.e., the user doesn’t need to fill the remainder of that TFDZ with anything. I think the confusion is when you state, “since there is no place for another packet”. But there is no problem with there being no more space in the TFDZ in this case. The bigger problem that USLP did address that AOS did NOT address, is when there is a small remainder left in the data field of a frame that the user cannot fill, so the transfer frame maker on-board the spacecraft, has to avoid the nasty edge cases of less than 7 octets remaining when space packets are used (encap packet is much more flexible, but as I mentioned, I don’t think any agency has implemented them yet !)

Are you good with this explanation ?

Best regards,
Greg

From: "Stefan.Veit at dlr.de<mailto:Stefan.Veit at dlr.de>" <Stefan.Veit at dlr.de<mailto:Stefan.Veit at dlr.de>>
Date: Tuesday, November 7, 2023 at 3:09 AM
To: "Kazz, Greg (US 312B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>, "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Subject: [EXTERNAL] USLP: Question from yesterday

Hello all,

sorry to bother you again with the question discussed yesterday at the end of the meeting (4.1.4.2.4.4: When the value in the TFDZ construction rule is ‘000’ binary, and when no packet starts nor ends within the TFDZ, then the FHP shall be set to binary ‘all ones’.) for fixed length frames.

Ignacio, you stated that a packet that ends within the current TFDZ (and no further packet is available) shall be followed by an Encapsulation Idle Packet (4.1.4.3.4).

What about the very special situation when a packet started in a previous frame and ends exactly at the end of the current TFDZ, filling it completely? Then, since there is no place for another packet, the FHP would be set to “all ones” and this contradicts the wording “NOR ENDS” in the statement above, doesn’t it? Or is there again an alternative to the all ones? However, this seems to be no exclusive statement, (other all-one-scenarios are allowed), so maybe we can cover this scenario with an additional sentence?

I hope this was the last special case -)

Thank you and Kind Regards
Stefan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20231107/9d092848/attachment-0001.htm>