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

["Scheffenegger, Richard" <[e-mail]>]

Hi Tim,

I agree with your reasoning, and think that IF Tsopt was established, under the current semantics, subsequent segments without Tsopt MUST not be accepted.

Sending an ACK for the last in-sequence segment MAY be allowed (but a receiver should not keep sending such an ACK excessively - if it would, and the reason for the non-TSopt segments is a path change where TSopt is being stripped, it could result in a permanent exchange of data/ack, without any forward progress... Although the sender would continuously shrink the cwnd, and limit the wasted bandwidth.)

Olivier remarked, that sometimes a sender might push out the TSopt in favor of other options (MPTCP, SACK). While I believe that even then a segment should not be accepted, if it lacks TSopt, I was wondering if there is any benefit to be had, to allow a fully in-sequence packet to be accepted then (shinking the acceptance window basically to one particular sequence number).

OTOH, the point of SACK is that it being sent during reorder / loss events, so a rule like above wouldn't be all that helpful really...

Does anyone know why Linux does accept non TSopt segments at any time?


In any case, the only proper way for PAWS would be to not accept non-TSopt segments after TSopt has been negotiated.

Regards,


Richard Scheffenegger

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Tim Shepard
> Sent: Freitag, 31. Mai 2013 20:48
> To: Joe Touch
> Cc: Fernando Gont; [e-mail] Extensions
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
> 
> 
> 
> 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]
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm