IETF Logo Mail Archive

Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03

Joe Touch <touch@ISI.EDU> Fri, 26 March 2010 23:51 UTC

Return-Path: <touch@ISI.EDU>
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 8BE6E3A6B69 for <tcpm@core3.amsl.com>; Fri, 26 Mar 2010 16:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13]
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 xqRuFCEpPg76 for <tcpm@core3.amsl.com>; Fri, 26 Mar 2010 16:51:04 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 96FDD3A6B5E for <tcpm@ietf.org>; Fri, 26 Mar 2010 16:51:04 -0700 (PDT)
Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o2QNo0G3005281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Mar 2010 16:50:01 -0700 (PDT)
Message-ID: <4BAD4827.7030202@isi.edu>
Date: Fri, 26 Mar 2010 16:49:59 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar>
In-Reply-To: <4BAD02BD.6070907@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigFFE2273E31DEB83D66F1AD10"
X-MailScanner-ID: o2QNo0G3005281
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, mallman@icir.org
Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03
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: <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, 26 Mar 2010 23:51:05 -0000

Presuming this is the path forward, one issue that needs to be addressed:

	- what happens when one side assumes the timestamps are
	monotonically increasing, but they're not

As recent exchanges suggest, there are possible reasons why either side
might want to implement timestamps differently. In that case, it's might
not be realistic to assume monotonicity.

It's not appropriate to consider client/server roles here; the issue is
who shuts down the connection and thus holds the TIME_WAIT - that is
often the server, but need not be.

Overall, if this suggestion requires the TIME_WAIT side assume
properties of the other end, it may *require* a flag to ensure.

Given we're not talking about such a flag, the entire mechanism may be
moot as a result.

Joe

v2.23.0 | Report a Bug | By Email