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

[Andre Oppermann <[e-mail]>]

On 01.06.2013 15:57, Scheffenegger, Richard wrote:
> 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.

The problem seems to be that timestamps are used for two separate
purposes: a) better RTT measurements; b) PAWS.

For a) a missing TSopt on a segment wouldn't be fatal, however which
timestamp shall the receiver reflect from now on?  The last one seen?
That would lead to a rapid inflation in apparent RTT seen on the sender.
For b) a missing TSopt is fatal since it makes it impossible to determine
if this segment is actually valid or not.

> 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.)

The more useful behavior is to ignore the segment missing TSopt.  Sending
an ACK doesn't magically fix the bug on the other side and leads to an
ACK war in the worst case.

> 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).

TSopt should never be pushed out by other options.  Doing so would be a bug.
One wouldn't expect other always present options (MPTCP for example) to be
pushed out either.

> 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?

FreeBSD behaves the same.  I once changed syncache to require TSopt in the
ACK completing the 3WHS when it was negotiated during SYN/SYN-ACK.  It was
reverted a short time later because someone reported a problem where some
buggy device on the path responded with an ACK in parallel to the original
host but missing TSopt.  Since the buggy device was slightly faster a RST
was sent and the connection attempt aborted.  I have no idea why the buggy
device responded in parallel with the real endpoint...  After the acceptance
test was relaxed again there was no further detailed analysis and it was
never found out what kind of device caused the trouble along the path.

The reverse check where TSopt must not be present when not negotiated is
still in place and hasn't caused any known problems.

Other errors with TSopt (not) present in established state are currently
not logged.  I should add in the next days.

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

Agreed.

-- 
Andre