Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-ses!hpcuhb!hpindda!subbu
From: subbu@hpindda.HP.COM (MCV Subramaniam)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP Retries
Message-ID: <6200032@hpindda.HP.COM>
Date: 14 Feb 90 22:12:23 GMT
References: <2755@lll-lcc.UUCP>
Organization: HP Information Networks, Cupertino, CA
Lines: 41

>
>I'm testing my port of a version of 4.3BSD TCP/IP code.  In
>doing so, I discard in the loopback driver every Nth packet
>(say, N=10).  This results in the MBUF pool being quickly
>depleted.  I discovered that the TCP input routine will
>save all out of order TCP packets waiting for the TCP retry
>to fill in the gaps.  Hence most of the MBUF pool is
>enqueued on this TCP fragment/reassembly list for this
>TCPCB.  Also, the sender continues to get ACKs advertising
>the largest window since the receive socket buffer is
>empty.
>
>Nothing particularly evil happens and since this is
>a very degenerate case, perhaps I should just shrug
>my shoulders and go on with life.  But it does bother
>me a bit - rightfully so?  (Couldn't the window advertised
>by the receiver close, or a limit made on the number
>of out-of-order TCP packets on a TCPCB?)
>
	Remember, the ACK number in all those ACK packets is the
	last sequence number recevied *in order*. So, decreasing
	the available window will mean shrinking the window, which
	is not acceptable as good behavior.

	It is the sender's responsibility to realize (on seeing old ACKs,
	and timing out for not receiving new ACKs) that old segments
	have to be retransmitted. 

	Btw, are you using 4.3 BSD for the sender too?

>Thanks for any help.

	Hope this helps.

>  Dave (wiltzius@lll-lcc.llnl.gov)
PS: You could also tune your implementation to set a limit on the number
or segments (or mbufs, or memory, whatever) on the reassembly queue.
This way, you won't run out of mbufs for other protocols/applications.

-Subbu
email: subbu@hpindaw.hp.com