[Sls-mhdc] Fw: Comments on CCSDS 124, draft of October

Mon Oct 26 13:27:44 UTC 2020

Oops. I see Miguel already did it. I apologise for the noise.

From:   David Evans/esoc/ESA
To:     sls-mhdc at mailman.ccsds.org
Date:   26/10/2020 14:18
Subject:        Fw: Comments on CCSDS 124, draft of October

Dear working group,

In preparation for 124 slot in the Autumn "meeting", Miguel has loaded a 
pending topics document to the CWE. I have also loaded the latest draft 
proposal on which the comments are based.

Hopefully we can resolve these last few issues together in the meeting. 

Best regards,
Dave

----- Forwarded by David Evans/esoc/ESA on 26/10/2020 14:14 -----

From:   "Miguel Hernández" <Miguel.Hernandez at uab.cat>
To:     "David Evans" <David.Evans at esa.int>
Cc:     "Bruno Mickael" <Mickael.Bruno at cnes.fr>
Date:   26/10/2020 09:58
Subject:        Re: Comments on CCSDS 124, draft of October

Hi Dave,

Apologies for the late reply. 

We have managed to study the new changes, and to propose a few minor 
considerations. We are still unsure about the assumptions we can make 
about the transport layer - we propose to discuss it in next Monday's 
meeting, along with the impact in the standardized algorithm. We also 
prepared a summary of pending topics that, from our perspective, ought to 
be discussed. We uploaded it to the CWE in case it is of any help 
regarding that meeting:

124x0w4-20201017_pending_topics

Thank you very much for your time, see you soon.
--
Miguel Hernández-Cabronero
http://deic.uab.es/~mhernandez/
Group on Interactive Coding of Images (GICI)
Department of Information and Communications Engineering (dEIC)
Universitat Autònoma de Barcelona (UAB)

On Wed, Oct 21, 2020 at 7:40 PM <David.Evans at esa.int> wrote:
Hi Miguel, 

It has been pointed out that the reference I used for the CCSDS CRCs only 
has 32 bits CRC specified (mainly for CFDP). 

We could use the CRC that CCSDS specifies for TM frames. It is specified 
in the "TM Space Data Link Protocol" 
https://public.ccsds.org/Pubs/132x0b2.pdf CCSDS 132.0-B-2 section 4.1.6.2 
"Frame Error Control Field Encoding Procedure". I do not feel qualified to 
specify one so was looking for something that the CCSDS already uses. 

Best regards, 
Dave 

From:        "Miguel Hernández" <Miguel.Hernandez at uab.cat> 
To:        "David Evans" <David.Evans at esa.int> 
Cc:        "Bruno Mickael" <Mickael.Bruno at cnes.fr> 
Date:        19/10/2020 18:26 
Subject:        Re: Comments on CCSDS 124, draft of October 

Perfect, Dave, 

Thanks a lot for your prompt response. 

Best, 
--
Miguel Hernández-Cabronero
http://deic.uab.es/~mhernandez/
Group on Interactive Coding of Images (GICI)
Department of Information and Communications Engineering (dEIC)
Universitat Autònoma de Barcelona (UAB) 

On Mon, Oct 19, 2020 at 6:19 PM <David.Evans at esa.int> wrote: 
Hi Miguel, 

HKTM is made up of different types of packets carrying different 
information. I have seen that different HKTM packets can share the same 
counter. Hence the decompressor can see that a packet went missing but it 
does not know which type of HKTM packet it was. 

Payload packets would have a different counter but again there could be 
different types and we cannot say if the counter would be unique to one 
type.   

Best regards, 
Dave     

From:        "Miguel Hernández" <Miguel.Hernandez at uab.cat> 
To:        "David Evans" <David.Evans at esa.int> 
Cc:        "Bruno Mickael" <Mickael.Bruno at cnes.fr> 
Date:        19/10/2020 18:10 
Subject:        Re: Comments on CCSDS 124, draft of October 

Hi again Dave,

Just a quick question to help me understand your proposal. When you say

"""The source sequence counter in the packet headers is not always 
specific for a packet type i.e. not every housekeeping packet type will 
have a unique counter. So what does this mean? Basically even if you know 
R_t it does help you."""

Do you mean that 
both HK/TM and payload packets are sent sharing the same counter sequence, 

that the number of payload packets between HK/TM packets is not known, 
and therefore any lost packet can be either HK/TM or payload, without a 
way of telling those apart?
Thanks a lot, 
--
Miguel Hernández-Cabronero
http://deic.uab.es/~mhernandez/
Group on Interactive Coding of Images (GICI)
Department of Information and Communications Engineering (dEIC)
Universitat Autònoma de Barcelona (UAB) 

On Mon, Oct 19, 2020 at 12:46 PM <David.Evans at esa.int> wrote: 
Hi Miguel, thanks, but when is the next meeting? I have not heard 
anything.... best regards, Dave 

From:        "Miguel Hernández" <Miguel.Hernandez at uab.cat> 
To:        "David Evans" <David.Evans at esa.int> 
Cc:        "Bruno Mickael" <Mickael.Bruno at cnes.fr> 
Date:        19/10/2020 12:44 
Subject:        Re: Comments on CCSDS 124, draft of October 

Thank you Dave, 

I will look at this as soon as I possibly can. I can't promise we will be 
able to have another iteration by email before the next meeting, but I 
will do my best to have a response to all the points by then. I will now 
send the email we discussed to the WG, so they too have the opportunity to 
look at our iterations (including your last response and draft). 

Best regards,
--
Miguel Hernández-Cabronero
http://deic.uab.es/~mhernandez/
Group on Interactive Coding of Images (GICI)
Department of Information and Communications Engineering (dEIC)
Universitat Autònoma de Barcelona (UAB) 

On Sun, Oct 18, 2020 at 5:03 PM <David.Evans at esa.int> wrote: 
Hi Miguel, 

I had some time again today to have a look at this again.There is a 
problem even for the main case of CCSDS packets that I had not realised 
before. The source sequence counter in the packet headers is not always 
specific for a packet type i.e. not every housekeeping packet type will 
have a unique counter. So what does this mean? Basically even if you know 
R_t it does help you. So there are two choices I can think of 
1) Implement a special counter for each packet type so it can be checked 
against R_t.   
2) Send a checksum in the clear that ran on the corresponding uncompressed 
packet so we can say if it correct or not after decompression. 

Looking at this today there are many advantages for 2) compared to 1) 
- it covers more failure cases than packet loss e.g. bit flip during 
transport or storage. 
- it provides more confidence in the result which is used in the next 
decompression 
- it makes the ground processing easier (if the checksum fails then you 
simply have to move to getting a mask and/or reference packet in the 
future and work backwards, end of story). 
- it allows the compression to continue when there was no mask update in 
the missing packet.. This is a common case and a R_t check would fail it 
when there was no need to.   
- we can remove the sentence where we say we leave data integrity with the 
transport layer. 
- we no longer have to send R_t in a 3 bit field. The decoder only needs 
to know if R_t = 0 or not as this influences the decoding path. This also 
solves one of the issues we had below. 

Of course we also have to calculate and send an extra 16 bits field but 
there are very fast CRC algos available in CCSDS already and I think this 
use of the extra bits has more value than just sending counters.  Counters 
also have their problems - how big would they have to be to avoid wrap 
around for example. 

I updated the standard again with this solution and the remaining issues 
are mostly solved - will it is a proposal on how to solve them. Could you 
have a look please and tell me what you think. 

Best regards, 
Dave 

From:        David Evans/esoc/ESA 
To:        "Miguel Hernández" <Miguel.Hernandez at uab.cat> 
Cc:        "Bruno Mickael" <Mickael.Bruno at cnes.fr> 
Date:        17/10/2020 12:58 
Subject:        Re: Comments on CCSDS 124, draft of October 

Hi Miguel. 

Great comments. I have answered all - attached and made the obvious 
changes to the standard. 

There are a still a couple of things to discuss though 
1) Handling of nt=0 
2) what to write in the robustness field and initialisation 
3) how to handle the desired file storage idea (and I have proposed to 
expand it so we can do it on-board as well). 

We could try another iteration by email but maybe these ones need a 
discussion? Let's try another iteration by email and then we can see. 

Best regards, 
Dave 

[attachment "124x0w4-20201017_a.docx" deleted by David Evans/esoc/ESA] 
[attachment "comments_124draft_202010 DJE.pdf" deleted by David 
Evans/esoc/ESA] 

From:        "Miguel Hernández" <Miguel.Hernandez at uab.cat> 
To:        "David Evans" <David.Evans at esa.int> 
Cc:        "Bruno Mickael" <Mickael.Bruno at cnes.fr> 
Date:        16/10/2020 17:27 
Subject:        Re: Comments on CCSDS 124, draft of October 

Hi Dave, 

I hope everything is still fine over there. 

We have been working on the latest draft you shared, as well as on your 
response to our latest draft (very much appreciated!). 

We have prepared another shorter report with some additional comments and 
suggestions, you can find it attached. Since the next CCSDS meeting will 
be held soon, we think it is a good time to share our advances with the 
rest of the working group. To this effect, I have added a new subfolder 
called "advances124_spring_to_fall_2020" under the 124.0-B folder, in the 
private CWE. If you are OK with it, and unless you prefer to do it 
yourself, I will contact the working group next week so that they know 
about our discussion. Needless to say, feel free to add any contents to 
the subfolder (or send them to me) as you deem appropriate. 

Thanks again for your time and help, and see you soon. 
--
Miguel Hernández-Cabronero
http://deic.uab.es/~mhernandez/
Group on Interactive Coding of Images (GICI)
Department of Information and Communications Engineering (dEIC)
Universitat Autònoma de Barcelona (UAB) 

[attachment "comments_124draft_202010.pdf" deleted by David 
Evans/esoc/ESA] 

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).

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-mhdc/attachments/20201026/4d61fa92/attachment-0001.htm>