[Sis-dtn] Some thoughts to the current HPRP draft (Section 1 - 4)

Tue Jul 30 04:52:35 UTC 2024

Hi,
You mean running the DA processing loop within the FPGA fabric?
When the FPGA side of HPRP was being developed, our largest issue was supporting multiple parallel sessions within the FPGA, which was massively simplified by putting all the complicated stuff (e.g DA) into the CPU :D

Thanks,
Jeremy

From: 구철회 <chkoo at kari.re.kr>
Sent: Dienstag, 30. Juli 2024 02:39
To: Mayer, Jeremy <Jeremy.Mayer at dlr.de>; Felix.Flentge at esa.int
Cc: sis-dtn at mailman.ccsds.org; sburleig.sb at gmail.com
Subject: RE: Some thoughts to the current HPRP draft (Section 1 - 4)

Hi, Jeremy.

Thanks for the feedback.

IMO, the hardware acceleration on the generation of data acknowledgment (DA) rather than by CPU can be useful.
In my experience of developing LTP, the hardest thing and time consuming parts were generating RS (Report Segment) and aligning out-of-order data in order.

Best,
Cheol

From: Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de> <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>
Sent: Monday, July 29, 2024 9:26 PM
To: 구철회 <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>; Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>
Subject: RE: Some thoughts to the current HPRP draft (Section 1 - 4)

Hi Cheol,
Comments inlined ☺

Thanks,
Jeremy

From: 구철회 <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>
Sent: Dienstag, 23. Juli 2024 04:38
To: Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; Mayer, Jeremy <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>
Subject: Some thoughts to the current HPRP draft (Section 1 - 4)

Hi, colleagues.

I just read the current HPRP draft and let me share some thoughts from me on the contents of Section 1 to 4.

1) 4.1 HPRP Segment
It could be informative if we add a ‘Data Segment Section (Optional, variable)’ after ‘Header Extensions’ field.
Refer the figure on page. 10 of RFC 5326 “LTP – Specification”.
JPM: Added “segment body”
2) 4.1 HPRP Segment
Segment Type ID (bit field of 4 – 5) could be extended to ‘bit field of 4 – 7’ to hold an indication of the ‘end of reliable data transmission in current session’ like EORP or EOB in LTP (RFC-5326). Why are the EORP and EOB field deprecated in HPRP? Unlikely CP (Checkpoint), these are useful for space saving and good match with FPGA, e.g., a fastest way of generating an interrupt for this event.
IMO, removing the descriptor of the ‘EORP’ or ‘EOB’ does not bring much benefit. Sending the DAR (Data Acknowledgement Request) at the edge of the data transmission may not be efficient although DAR is quite good message scheme for asynchronous state check of data reception. I think DAR is better way than ‘CP’ in LTP spec for this purpose.
JPM: Those fields are deprecated to simplify the interfaces required for hardware acceleration; We made a simplifying assumption that, in an FPGA-accelerated implementation, the user would implement all the complex state-keeping stuff within a CPU instead of an FPGA fabric. Therefore, we aimed to optimize the transfer of real-time signaling data between the CPU and FPGA. By simply copying the entire extension field (if it exists, and optionally only if it’s a system extension), you facilitate use of DMA for transfers and allow a single interrupt (DMA transfer completed) to signal any and all protocol signaling.
3) 4.1.8.3
The value session number length --> The value of the session number
(Q) The session number can be 0? I think it should be non-zero because 0 means, generally, the first index of an array or indicator that means no actions required.
JPM: It can be, or randomly generated. In the existing implementation, we basically just used whatever was available (e.g. a potentially uninitialized variable)
4) 4.2.8.2.2.1
  Data Acknowledgement extensions must be acknowledged by the receiving (--> sending) engine via a metadata acknowledgment message.
JPM: Updated text to clarify.
5) 4.3.2.2 Client Service ID
It could be informative if we add a description about how this field relate RFC-7116. Also, we may need to update this RFC-7116 document for adapting HPRP.
JPM: I think this needs to be discussed.
6) 5.2.3
 Upon the end of reception --> Upon the reception of un-successful data acknowledgement
JPM; Minor update bade
7) 5.2.4 Transmit Acknowledgement Request
 IMO, ‘Timeout’ could be more semantically appropriate word than ‘Interval’ in this context.
JPM: We’re using the same value as the transmission interval on the Tx side, so I think this can stay unless someone has strong opinions about it.
Best,
Cheol

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240730/c09ca658/attachment-0001.htm>