Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt

[Tim Shepard <[e-mail]>]

If a TCP connection has succesfully negotiated timestamp option on,
and a segment shows up with no timestamp option, I can think of only
two reasons for this:

	1.   The other TCP is buggy in some way.  (Or maybe *this*
             TCP implementation is buggy in some way and corrupted
	     the TCB block variable that remembers whether we've got
	     timestamp options on or off.  In any case, there is a
	     bug.)
	
	2.   The segment that arrived is from some old TCP connection,
	     probably to or from some previous user of a reused IP
	     address.  

	     (The MSL is a pure myth.  There's no way to guarantee any
	     upper bound for how long some packet may be delayed in
	     transit.  15+ years ago I did a trivially easy
	     demonstration that delayed several ping packets for over
	     an hour (over lunch), with no Internet routers involved,
	     on a LAN using hardware that was in widespread use at the
	     time.  E.g. Someone trips over a cable which slightly
	     dislodges it, then hours or days later, someone later
	     notices and pushes it back in.)


So, you can either accept the packet (A) or drop the packet (B).

    1. (A)     hmm... other end is buggy, *maybe* accepting the packet
	       would be the right thing.

    1. (B)     other end is buggy, dropping the packet *might* cause a
	       TCP connection to get stuck that otherwise would not
	       have gotten stuck.  (Hard to say... the other end is buggy!)


    2. (A)     data corruption (if the packet is otherwise acceptable)

    2. (B)     clearly the right thing to do.


With no reliable way to distinguish case 1 from case 2 at the
receiver, my gut is to prefer option B and live with the possible
downside of  the  1. (B)  situation.

	     
I also think letting the connection get stuck in the 1. (B) situation
has an upside... it might draw attention to the bug and cause the bug
to get fixed.  

... as long as there is no ambiguity on which of the two TCP
implementations is buggy.  (If we have this problem, then we have a
much bigger problem.)


			-Tim Shepard
			 [e-mail]