Right now, the TCP reassembly timeout gives up on (i.e., force expires/terminates) a connection if (1) it is trying to reassemble it and can't fill a gap and (2) it has not seen new packets for that connection within N seconds.
Some kind of timeout on reassembly is necessary to avoid running out of memory, but these semantics aren't ideal; the current reassembly timeout impacts subscriptions that analyze non-reassembled TCP packets, and it prevents us from discarding buffered packets from long-lived connections even if a gap won't be filled.
One thought on a better implementation of a TCP reassembly timeout (open to other ideas):
- Give up on filling a gap after observing an acknowledgement for the gap (this means that the segment got lost in between the original sender and the monitoring point, but did make it to the receiver)
- Give up on filling a gap after a timeout, even if additional packets have been observed, but don't drop the connection
- Either discontinue reassembly (maintaining all other Actions) OR continue reassembling future packets despite the gap (i.e., update sequence numbers as if the gap has been filled). Maybe this behavior could be a configurable option.
Right now, the TCP reassembly timeout gives up on (i.e., force expires/terminates) a connection if (1) it is trying to reassemble it and can't fill a gap and (2) it has not seen new packets for that connection within N seconds.
Some kind of timeout on reassembly is necessary to avoid running out of memory, but these semantics aren't ideal; the current reassembly timeout impacts subscriptions that analyze non-reassembled TCP packets, and it prevents us from discarding buffered packets from long-lived connections even if a gap won't be filled.
One thought on a better implementation of a TCP reassembly timeout (open to other ideas):