Subject: [Tsvwg] TCP Question: Reuse of TCB's in time-wait state:

From: "sanjay kaniyar" <[email-masked]>
Date: Mon, 22 Oct 2001 22:13:20 -0700

In some operating systems (as well as in Richard Steven's TCP/IP 
illustrated), I have come across ways to reuse a TCB in time-wait state.

The scenario is, when a SYN is received for a time-wait TCB with an ISN 
greater than the last sequence number seen on that in the receive direction, 
the TCB is moved back into the SYN-RCVD state, and the three way handshake 
proceeds as usual (with the ISN on the SYN+ACK sent out being equal to the 
last sequence number used in the send direction + 128K).

However, I have not seen any description where an active open is allowed to 
use a TCB in the time-wait state (Quite possible that one exists, but I just 
have not come across one).

One such possible way to implement this would be, to move the TCB from 
time-wait to SYN-SENT state and send out a SYN with an ISN greater than the 
last send sequence number seen on the TCB. If the peer responds with an ISN 
greater than the one last seen by the TCB in the receive direction, the 
connection establishement proceeds normally; Otherwise, send a RST, abort 
the connection request and put the TCB back in the time-wait state.

My concern here is to understnad if there is any reason why this should not 
be done. I would very much appreciate suggestions/responses which (i) Do not 
question the validity of the first scenario, because I am looking at 
altering that and (ii) Do not debate the usefulness of the second (or first) 
scenario which I would say is subjective at best.

Thanks,
Sanjay.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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

---

From: Allison Mankin <[email-masked]>
Date: Tue, 23 Oct 2001 01:21:14 -0400

Sanjay,

This kind of question gets more attention asked
on the TCP-IMPL mailing list.  The  working group
concluded but the list still lived last time I
looked:

  [email-masked]

to subscribe

Allison

---

From: "Lars Eggert" <[email-masked]>
Date: Tue, 23 Oct 2001 09:20:04 -0700

Sanjay,

> illustrated), I have come across ways to reuse a TCB in

I assume this is to reuse that PCB's cwnd and ttl information?

Sharing PCB information between connections has been proposed earlier,
starting with T/TCP (RFCs 1379+1644), which also allows you to bypass the
3-way handshake for repeated connections. Joe Touch differentiates between
temporal sharing of PCB information (repeated connections) and spatial
sharing (multiple, parallel connections) in RFC 2140. Him and me had a
paper in CCR in which we investigate temporal and spatial sharing further,
and present some simulation results (available from the URL in my sig).
UCB's congestion manager is a similar idea, based on their earlier work on
TCP-INT (INFOCOM 98), but seems to focus mostly on spatial sharing
(parallel connections).

> My concern here is to understand if there is any reason why
> this should not

I think temporally sharing PCB state can be a good idea, if done right.
The key issue is that simply reusing old PCB information can lead to
bursts, either because of slow-start-restart-like conditions, or simply
because the network path has changed since you last updated the PCB. Some
sort of gradual mechanism to ramp up to the old cwnd is needed (we used
John Heidemann's "pacing" mechanism for the simulations in the CCR paper).

Lars

PS: Your conditions (i) and (ii) may prevent you from getting some useful
feedback...
--
Lars Eggert <[email-masked]>               Information Sciences Institute
http://www.isi.edu/larse/              University of Southern California

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Oct 2001 11:04:43 -0700

> illustrated), I have come across ways to reuse a TCB in time-wait state.

Lars already pointed out some of our earlier work on TCB reuse, and the 
issues therein. However, when reusing a TIME_WAIT, there are other 
issues, addressed in the following two papers"

"The TIME-WAIT state in TCP and Its Effect on Busy Servers,"
Theodore Faber, Joe Touch, and Wei Yue, Proc. Infocom '99, pp. 
1573-1583. http://www.isi.edu/touch/pubs/infocomm99/

Bob Braden's "TIME-WAIT Assassination Hazards in TCP," RFC-1337, May 1992.

> greater than the last sequence number seen on that in the receive 
> direction, the TCB is moved back into the SYN-RCVD state, and the three 
> way handshake proceeds as usual (with the ISN on the SYN+ACK sent out 
> being equal to the last sequence number used in the send direction + 128K).

The TIME_WAIT is intended to prevent data from an old connection from 
creeping into a new connection undetected. Using a new ISN doesn't 
prevent this; data from an old connection, prior to a wraparound, could 
still be in the network - e.g.,

	*old data seq 32000 - bubbles around in the net
	(the rest of the seq space is used and wraps)
	old connection closes with seq 31000

	(time wait with seq 31000)

	new connection opens with seq 31001
	old data (*) arrives and is accepted on the new connection

The reuse of TCBs is based on IP addresses and port numbers only, not 
sequence numbers. This is one reason why.

> time-wait to SYN-SENT state and send out a SYN with an ISN greater than 
> the last send sequence number seen on the TCB. If the peer responds with 
> an ISN greater than the one last seen by the TCB in the receive 
> direction, the connection establishement proceeds normally; Otherwise, 
> send a RST, abort the connection request and put the TCB back in the 
> time-wait state.

TIME_WAIT problems are usually unidirectional; using TW information to 
open a connection doesn't solve the problem that's most notable. That 
said, this can still have data from old connections creep into new ones.

Joe

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 24 Oct 2001 05:18:44 -0500

Sanjay,

One reason might be security: it should not be probable that a new
ISN is related to an old one, as it increases an attacker's ability
to guess ISNs.  Adding 128k is fairly determinate compared to the
entropy approaches normally used to generate ISNs for new connections.

--brian

On Mon, 22 Oct 2001, sanjay kaniyar wrote:

> be done.

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/