Gap-identification vulnerability for file transfers

[rrieber]

Feature Description

Modify the "Sequence ID" field in the "File Packet Header" to be "Transaction ID" rather than a monotonically increasing counter. This would bring the protocol closer to the CFDP inspiration upon which it was written. The "Transaction ID" would enable the receiver to group packets of the same file together and permit the receiver to hold on to multiple file transactions that might be waiting for completion.

Rationale

Currently, file packets are stamped with a "Sequence ID", which starts at 0 for the Start packet, increments to 1 for the first file data packet, then continues to count. This permits the receiver to order packets properly and identify gaps. However it is not robust.

Gap Identification Failure

Let's explore an example where two files are telemetered that have the same size (which is a common activity) back to back. Each file has 4 packets (1 start, 2 data, 1 end). Assume packets 3 and 4 of file-1 and packets 1 and 2 of file-2 are dropped. This would create the following packet assembly:

• File-1, packet-1 (START)
• File-1, packet-2 (DATA)
• File-2, packet-3 (DATA)
• File-2, packet-4 (END)

This would be happily reassembled, then fail checksum at file validation.

Dropped START Packet

Continuing the above example, the receiver would have zero clue that File-2 was sent in that it never received it's destination file name. This would be a silent failure and the receiver would not be able to inform the sender of any evidence of this file.

Redundant with Byte Offset/Data Length

The ordering of file data packets is achieved with the byte offset and data length field and a sequence ID counter is not required.

Conclusion

I have enumerated two issues why a unique transaction ID would be superior than a monotonic counter. I'm sure there are additional benefits to such a feature that I have missed. I do not think this would be an outlandish change in the protocol or the code. Hopefully this helps.

P.S. Maybe just deploy Type-2 CFDP and solve all the problems :-D

[timcanham]

@rrieber I think the answer is both. We need a transaction ID along with a sequence ID so we can detect dropouts in the file transmission. The design of the FileDownlink/FileUplink has always been serial anyway - it doesn't simultaneously transmit more than one file.

As for CFDP, I think it would be a great idea to do it all around - we just need the resources to do it.

[rrieber]

@timcanham You are correct in that files do not TRANSMIT more than one file at a time, but due to reception kerfuffles or auto-retransmits from different protocol layers (think PROX-1 or TCP/IP), files could be RECEIVED out of order.

Can you explain how sequence ID provides additional information beyond that of the byte offset/data length fields? It is my opinion that only the byte offset/data length is required to reassemble the file and identify gaps. (This is how CFDP does it.)

[timcanham]

@rrieber Belt and suspenders, which I'm a fan of. It makes the receiver a little simpler to just detect a break in the sequence. We could also add offset and size checking to do full belt and suspenders.