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

Andre Oppermann <andre@freebsd.org> Sat, 01 June 2013 16:52 UTC

Return-Path: <andre@freebsd.org>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A0821F9E45 for <tcpm@ietfa.amsl.com>; Sat, 1 Jun 2013 09:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHwldqw4ERyc for <tcpm@ietfa.amsl.com>; Sat, 1 Jun 2013 09:52:20 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id E571421F9CEB for <tcpm@ietf.org>; Sat, 1 Jun 2013 09:52:19 -0700 (PDT)
Received: (qmail 75402 invoked from network); 1 Jun 2013 17:50:08 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <rs@netapp.com>; 1 Jun 2013 17:50:08 -0000
Message-ID: <51AA26B8.7080700@freebsd.org>
Date: Sat, 01 Jun 2013 18:52:08 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: Your message of Fri, 31 May 2013 10:24:59 -0700. <51A8DCEB.2090401@isi.edu> <E1UiUMS-00074F-00@www.xplot.org> <012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Fernando Gont <fgont@si6networks.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, Tim Shepard <shep@alum.mit.edu>, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Jun 2013 16:52:25 -0000

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