[SIS-CFDPV1] Multiple file delivery request in a single Metada PDU and compressed delivery....

[Tomaso.deCola at dlr.de]

About the specification of multiple file names this is certainly doable, although not presently supported (so that some modification of the blue book will be in any case necessary). My doubt is the overall effectiveness gain you achieve with this given the current CFDP protocol specification. If I understand correctly your idea, all files back to back will be accommodated in a single FDU, which will be turn into a number of CFDP PDUs and in turn transmitted over a convenient UT. Then I also expect that the FDU will be delivered only when you receive the EOF, i.e. the first file being transmitted will be available only when all the other files will be received. As such I’d see more effective to have instead separated FDUs for each file, i.e. dedicated transaction for each file transmission that is what CFDP does nowadays.

Am I missing something of your proposal?

Regards,

Tomaso

From: 구철회 <chkoo at kari.re.kr>
Sent: Donnerstag, 8. Dezember 2022 01:20
To: Cola, Tomaso de <Tomaso.deCola at dlr.de>
Cc: sis-cfdpv1 at mailman.ccsds.org
Subject: RE: Multiple file delivery request in a single Metada PDU and compressed delivery....

Hi Tomaso.

Thanks for sharing your thoughts.

Specifying multiple file name wouldn’t be so complicated, For example, I guess it could be done if
Source file name (LV) --> source file name (TLV), where type is for CSV (comma-separated values).
So multiple file name can be given like “xx(type code for CSV)” “30” “aaa.txt,bbb.tlm,ccc.img,ddd.dat”. This can give some potential flexibility on operating CFDP for ground operators and spacecraft itself.

If the compression happens in outside of CFDP app layer, someone must extract the compressed CFDP packet itself to see how the CFDP header is configured.
Or, actually the compression can be done to File Data PDU than the target file itself.

Best,

Cheol

From: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de> <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Sent: Wednesday, December 7, 2022 5:05 PM
To: 구철회 <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>
Cc: sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Subject: RE: Multiple file delivery request in a single Metada PDU and compressed delivery....

Hi Cheol,

My understanding of CFDP is that it’s transaction based, where a transaction is aimed at transferring a single file. As such, transmission of multiple files has to go over different transactions. Moreover, the metadata allow to specify a single file name (source and destination) so that the possibility of sending multiple files with the same put request does not seem to me possible.
As to the compression, in my opinion this is something that can happen outside the CFDP operations.

Regards,

Tomaso

From: SIS-CFDPV1 <sis-cfdpv1-bounces at mailman.ccsds.org<mailto:sis-cfdpv1-bounces at mailman.ccsds.org>> On Behalf Of ??? via SIS-CFDPV1
Sent: Mittwoch, 7. Dezember 2022 01:49
To: sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Subject: [SIS-CFDPV1] Multiple file delivery request in a single Metada PDU and compressed delivery....

Hi, CFDP fellow.

Recently, I am questioning to myself about how I am able to get multiple files from remote space storage through CFDP.
In the current CFDPv1 specification, we have to send multiple put.request commands to a sending entity as many as needed.

Is it possible to think putting multiple file source in a metadata pdu and also possibly compressed by tar, zlib and so on to make it possible?
For example, we can compile a metadata pdu as follows when a sending CFDP entity got requests for the aaa.txt bbb.tlm, ccc.img, ddd.dat separately:
File size : file size of compressed file, i.e., size of measurement_data.gz
Source file name : aaa.txt bbb.tlm, ccc.img, ddd.dat
Destination file name : measurement_data.gz

In my opinion, voluntary compression service by a sending CFDP entity would be good in terms of bandwidth reduction, lower retransmission rate and so on.

Cheol


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-cfdpv1/attachments/20221208/e8b067bc/attachment-0001.htm>