Subject: [tcpm] TCP Reassembly Timer

From: "Vishal Study" <[email-masked]>
Date: Wed, 25 Apr 2007 10:18:10 -0700

Hi:

Is there an RFC/draft that talks about TCP Reassembly timer?

Scenario:
Host begins to receive out of order pkts and enqueues them in its
RX_Q. If there are lot of sessions that are stuck in such state (with
out of order pkts), the system can go down on resources (memory).

Does any standard/RFC talk about what should be the expected behavior?

I know there are implementations that have a Reassembly timer and they
either drop the session or (atleast) drop out of order pkts when the
Reassembly timer kicks off.

Any pointers...

Thanks in advance,
Vishal.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: David Borman <[email-masked]>
Date: Wed, 25 Apr 2007 12:45:37 -0500

A TCP is free to throw away any out-of-order segments that it has  
received.  They have not yet been acknowledged, so the sender is  
responsible for keeping copies and resending them.  SACK is not a  
hard acknowledgment, so even packets that have been SACKed can be  
tossed.

Of course, the connection will slow down waiting for the dropped  
packets to be retransmitted, but I guess the connection is already  
running slow waiting for missing packets. :-)

Various BSD based implementations have implemented tcp_drain()  
functions that go through and flush all the TCP resequencing queues.

I see no reason to have a timer on the resequencing queue, the  
regular TCP timers should take care of dropping non-responsive  
connections.  Providing a tcp_drain() type function that gets called  
when resources are low should be sufficient.  (Though in practice,  
I've observed that when memory gets that low, something is hogging  
all the memory and anything that gets freed up is immediately sucked  
up by the errant process...)

			-David Borman