[tcpm] draft-gont-tcpm-tcp-timestamps-00

Alfred Hönes <ah@tr-sys.de> Tue, 13 January 2009 23:18 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C062A3A6A71; Tue, 13 Jan 2009 15:18:34 -0800 (PST)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0C13A6A71 for <tcpm@core3.amsl.com>; Tue, 13 Jan 2009 15:18:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.651
X-Spam-Level: *
X-Spam-Status: No, score=1.651 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbkPBA11+8IE for <tcpm@core3.amsl.com>; Tue, 13 Jan 2009 15:18:32 -0800 (PST)
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 1D9A43A68F6 for <tcpm@ietf.org>; Tue, 13 Jan 2009 15:18:30 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA248588591; Wed, 14 Jan 2009 00:16:31 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA17717; Wed, 14 Jan 2009 00:16:30 +0100 (MEZ)
From: Alfred Hönes <ah@tr-sys.de>
Message-Id: <200901132316.AAA17717@TR-Sys.de>
To: tcpm@ietf.org
Date: Wed, 14 Jan 2009 00:16:29 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Subject: [tcpm] draft-gont-tcpm-tcp-timestamps-00
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Folks,

I have reviewed the I-D, draft-gont-tcpm-tcp-timestamps-00,
which has been submitted to the WG for consideration.

The basic idea in the draft seems to be so logical and such
an immediate step forward in the spirit of RFC 1122 that,
if the TCP timestamps option already had been defined during
the development of RFC 1122, I suspect that it readily would
have been incorporated and recommended therein!

Besides a small couple of textual flaws and improvement requests
I already have communicated off-list to the author, there seems
to be a double oversight in the second part of the algorithm in
section 3:

a)  There's no "Otherwise, ..." clause.

    Fix: Copy the sibling clause literally from the end of the
    first part of the algorithm to the end of the second part!

b)  The following (potentially rare) corner case, in which it
    would have been possible according to the rules in RFC 1122
    to establish a new connection notwithstanding a previous
    incarnation in the TIME-WAIT state, has not been considered:

    -  old connection didn't use TSO,
    -  new SYN segment with TSO,
    -  local policy / socket options would lead to SYN-ACK without TSO,
    -  new incoming Sequence Number > last corresponding old SN

    Including this case into the second alternative of the second
    part of the algorithm would therefore further improve the benefit
    of the algorithm.

    It might be preferable to make the answer to the question
        'would the new connection be using timestamps?'
    the primary criterion for distinguishing between the first
    and the second alternative in the second part of the algorithm.
    Doing so would allow to simplify the text otherwise necessary
    to describe the preconditions in the second alternative.

    I have submitted ot the author some possible text variants to
    accommodate these considerations and discussed their mutual
    benefit.  For the sake of brevity, I have omitted the details
    here, shortly ahead of a promised update to the draft.

Best regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm