[dtn] TCPCLv4 -07 updates and simplification

[Brian Sipos <[e-mail]>]

All,

After looking into simplifying TCPCLv4 as discussed at the IETF, I see that if a transfer is always simplified into a single XFER_INIT message followed by a single "segment" of data this effectively turns the TCPCL session unidirectional by preventing any other XFER_ACK messages from acknowledging transfers in the other direction within the session. One side effect of segmented transfer data is to allow other messages from the transmitting node between segments by avoiding monopolizing the TCP connection with a single huge message.


I feel like segmentation, as an optional behavior as currently specified, gives the network / node management a way to avoid this kind of message queue blocking behavior and allows more deterministic timing of when an ACK can be expected based on path delays.


For a simple-as-possible workflow, an implementation could choose to disallow a Segment MRU any smaller than the Transfer MRU and could choose to always transfer within a single segment which would minimize the message framing overhead. If interoperability was not necessary then it could also refuse any transfer that includes a segment smaller than the transfer size, so that there would be no need for receive segment concatenation.


Any thoughs on keeping segmentation as a negotiated behavior in order to allow for better administrative control over worst-case session timing?