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

[Joe Touch <[e-mail]>]

sanjay kaniyar wrote:

> 1. I went through the paper you pointed out, it does not seem to address 
> the question I have. It basically describes alternatives of how to move 
> a TW-TCB from the server to the client, which I don't see as related to 
> reusing a TW-TCB in active open. Can you elaborate on this? (In a 
> broader sense, yes, it also deals with the problems caused by Time-wait 
> TCBs. But, I don't see it addess the reuse of Time-wait TCB issue).


It deals with the same problem - accumulation of the TIME_WAIT states, 
and provides a set of alternate solutions.


> 2. RFC 1337 primarily talks about the problems that could occur when 'a 
> new incarnation of a connection is established' without any reference to 
> the 'previous incarnation' (which could result if a TW-TCB is 
> 'removed'). I am not proposing to do that.


It also addresses, as does the first reference, the purpose of the 
TIME_WAIT itself.

> 3. In the example you have given, the old duplicate could result in data 
> corruption even for the same connection, it makes no difference whether 
> the conenction was re-established or not. Basically, without using 
> options (timestamp), there is no way to guarantee that data corruption 
> does not occur for a fast TCP connection. Any connection that wraps 
> around within 2MSL could face data corruption;

 

If TCP avoids this using timestamps, how is this handled in your 
variant? First, TCP keeps only IP and port numbers in TIME_WAIT; second, 
while there is a requirement of monotonicity for timestamps within a 
connection, there is no requirement that timestamps be monotonic across 
multiple connections.

Further, the entire mechanism you propose was examined before - see
the following text from the appendix of RFC1185 (PAWS):

. A different approach was suggested by Garlick, Rom, and Postel
. [Garlick77].  Rather than using clock-driven ISN selection, they
. proposed to maintain connection records containing the last ISN used
. on every connection.  To immediately open a new incarnation of a
. connection, the ISN is taken to be greater than the last sequence
. number of the previous incarnation, so that the new incarnation will
. have unique sequence numbers.  

That appendix later explains why this introduces a hazard that even PAWS 
cannot protect:

. However, the connection is still vulnerable to old duplicates in the
. other direction.  Mechanism (A) prevents trouble in mode F1, but
. failures can arise in F2, F3, or F4; of these, F2, on short, fast
. connections, is the most dangerous.


> 4. In some commonly seen implementations, a TCB is moved from Time-Wait 
> to Syn-Rcvd upon receiving a SYN, if the Sequence number on the SYN is 
> greater than the one received last on the earlier incarnation of the 
> connection. This assumes that the ISN generator on the remote end does 
> not wrap around within 2MSL. If it does, then there is no way to protect 
> the conneciton from data corruption; If it does not, then there is no 
> way the connection could end up with corrupted data. (I am ignoring the 
> 128K addition to ISN for now).


Common implementation != correct implementation :-)
There were implementations that did this in 1990 when RFC1185 was 
written as well; they are addressed in the paragraph just before the 
above quote, which describes their failure mode.


Joe



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