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

Fernando Gont <> Sat, 27 March 2010 04:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9ACB53A67AD for <>; Fri, 26 Mar 2010 21:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.708
X-Spam-Status: No, score=0.708 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 88PHnPyVYuPP for <>; Fri, 26 Mar 2010 21:14:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ED2453A67B4 for <>; Fri, 26 Mar 2010 21:14:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 049146B6E42; Sat, 27 Mar 2010 01:14:29 -0300 (ART)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o2R4EKud005623; Sat, 27 Mar 2010 01:14:20 -0300
Message-ID: <>
Date: Sat, 27 Mar 2010 01:14:20 -0300
From: Fernando Gont <>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 ( []); Sat, 27 Mar 2010 01:14:28 -0300 (ART)
Cc: "" <>,
Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 27 Mar 2010 04:14:03 -0000

Hi, Joe,

These are interesting points to be addressed/clarified. Thanks!

I will try to address these in the next rev of the document. --
Meanwhile, comments inline....

Joe Touch wrote:
> 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

Worst case scenario: the TIME_WAIT state cannot be recycled, and hence
the situation is no worse and no better than the current state of
affairs, namely:
a) The TIME_WAIT state is assasinated [RFC793], with the connection
request being rejected
b) The SYN segment is ignored, and thus the connection request times
out, or is accepted after future retransmissions of the SYN [RFC1337]

> 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 really about assuming that timestamps are intentionally
monotonically-increasing. *If* they are, no matter whether that was by
choice or by chance, you can recycle the TCB.

*If* timestamps are monotonically-increasing, then you're sort of
assured that the aforementioned "heuristics" will work.

This parallels the processing of ISNs in the BSD hack (allowed by the
very RFC793). There are stacks that completely randomize the ISNs (e.g.,
OpenBSD). If the ISN of an incoming SYN is larger than the last SEQ seen
for a connection in the TIME_WAIT state, you recycle the TCB. If ISNs
are randomized, these heuristics may or may not kick in.

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

What I meant is that the side more concerned with recycling TCBs in the
TIME_WAIT state is the server-side. And that the side that should
generate monotonically-increasing timestamps is the client-side.

You're right that which side remains in the TIME_WAIT state depends on
which side performs the "active close" (rather than on client vs.
server). But if it's the client TCB that remains in the TIME_WAIT state,
 the collision would not even occur, as it would be detected and avoided
by the client itself.

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

I believe this is unnecessary. The beauty of this "TIME_WAIT tossing"
things is that this is a local policy, that can be applied even without
agreement with the other side.

Clearly, for the sake of this policy, it's better if clients generate
timestamps such that they are monotonically-increasing across
connections. If the chances of TIME_WAIT tossing are reduced.

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

THe "TIME_WAIT tossing" thing is a local policy, rather than a
mechanism. If clients generate timestamps such that they are
monotonically-increasing they clearly contribute to the success of this
policy. That's it.

Again, the heuristics performed by BSD-derived kernels with the ISN of
incoming SYNs when there's a previous incarnation of the same connection
in the TIME_WAIT state.


Kind regards,
Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1