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

Fernando Gont <fgont@si6networks.com> Fri, 31 May 2013 10:52 UTC

Return-Path: <fgont@si6networks.com>
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 D707621F85F4 for <tcpm@ietfa.amsl.com>; Fri, 31 May 2013 03:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 x0CgI26YxZE8 for <tcpm@ietfa.amsl.com>; Fri, 31 May 2013 03:52:07 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id F413321F85E6 for <tcpm@ietf.org>; Fri, 31 May 2013 03:52:05 -0700 (PDT)
Received: from b00150.krakowskiinternet.pl ([91.231.45.150] helo=[192.168.1.160]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from <fgont@si6networks.com>) id 1UiMw2-0002Jz-UH; Fri, 31 May 2013 12:51:51 +0200
Message-ID: <51A880C5.4090707@si6networks.com>
Date: Fri, 31 May 2013 12:51:49 +0200
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <CAK6E8=d_LTZgnGAncdWDAi+7ebd3Lo5aevPeGG0=KSbBMeBhcg@mail.gmail.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <E220F4B0-EE27-431C-BCBE-0A0C01C8B0EF@iki.fi> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <B3F294F6-8866-4155-98F6-0927B90346E4@iki.fi> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> <DDB1E5C2-F806-45CF-80F8-AC3774523A5C@iki.fi> <012C3117EDDB3C4781FD802A8C27DD4F24BBA3B6@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24BBA3B6@SACEXCMBX02-PRD.hq.netapp.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>, 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: Fri, 31 May 2013 10:52:09 -0000

Hi, Richard,

For the most part I've not participated in this discussion at all, but
at times have lurked a bit... A small comment here:

On 05/30/2013 04:28 PM, Scheffenegger, Richard wrote:
> 
> My understanding is, that failing the PAWS test should be treated like receiving 
> a segment that is out-of-window. The reason for failing the PAWS test (missing TSopt, 
> or invalid TSval) is secondary, not?
> 
> Thus an ACK for the last in-sequence segment should be sent.
> 
>> 1) MAY/SHOULD/MUST send response for missing timestamp
> 
> This case is not currently covered. As consensus was reached that TSopt should not be allowed to be sent arbitratily for some segments and not for others, I would think a missing timestamp in a segment means, that segment needs to be treated like any other out-of-window segment.

Datapoint: Some OSes accept non-timestamped packets because they've fund
that some implementations (or maybe sites "protected" by some sort of
middlebox) at times stop sending timestamps, or include timstamp options
at their own discretion.

Not that I think that accepting such packets is nice (actually, it
doesn't look "clean") -- but at the end of the day, you need to
interoperate with others.

I suggest that the OpenBSD folks are asked about this one... since I
think they were the ones noting the aforementioned issue.

Cheers, and thank you guys for the hard work on rfc1323bis!
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492