Re: [tcpm] RFC 1323: Timestamps option

Mark Allman <mallman@icir.org> Sat, 27 January 2007 01:41 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAcZ6-0004xU-Sl; Fri, 26 Jan 2007 20:41:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAcZ5-0004xO-JH for tcpm@ietf.org; Fri, 26 Jan 2007 20:41:11 -0500
Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAcYy-0000eC-Rj for tcpm@ietf.org; Fri, 26 Jan 2007 20:41:11 -0500
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l0R1f326023918; Fri, 26 Jan 2007 17:41:03 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id CD5A972BCDC; Fri, 26 Jan 2007 20:40:51 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E88AF16E90F; Fri, 26 Jan 2007 20:40:54 -0500 (EST)
To: David Borman <david.borman@windriver.com>
From: Mark Allman <mallman@icir.org>
Subject: Re: [tcpm] RFC 1323: Timestamps option
In-Reply-To: <F2997536-93BF-4BA7-BB9C-2F1D211DDB1C@windriver.com>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Long May You Run
MIME-Version: 1.0
Date: Fri, 26 Jan 2007 20:40:54 -0500
Message-Id: <20070127014054.E88AF16E90F@lawyers.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1797200908=="
Errors-To: tcpm-bounces@ietf.org

> You've probably already seen my reply to Sally, but I'll clarify a
> few things:

Yes - I just read it (although, I am a bit behind on the thread, so
apologies if some of the stuff below has been said).  But, I think it
is orthogonal to my concern.  Likely, I am not stating things well.

Sally's observation (and, she is not the only one to make it over the
years) is that the current TCP RTO algorithm keeps history in terms of
the *number* of samples taken.  So, if you take two RTT samples per RTT
as opposed to one then you are keeping half as much history in *time
units*.  I think we all agree with this and that it should be addressed
**when a TCP connection is taking more than one RTT sample per RTT**.
Exactly how we address it is a discussion we can have (averaging samples
into one per RTT that is fed to the estimator, taking the max sample per
RTT, adjusting the EWMA gains based on the cwnd, etc.).  This problem
manifests itself *when* we take multiple samples per RTT.  What I am
asking about is *whether* we need multiple samples per RTT.

It seems to me that your notes assume somehow that more than one sample
per RTT is useful.  Why?  Or, 

> Being guaranteed at least one good RTT measurement per RTT is a good
> thing.

Why?

(I don't mean to be flip.  Surely one good RTT sample per RTT is a fine
goal.  The "why?" is in response to the "guaranteed" part of your
statement.) 

Clearly we want an evolution of the RTO to take into account changing
RTTs and the variance in the RTT.  So, we don't want to use a static
number and we do not want to take a single sample and then stop
(although, actually, this latter does not perform too bad).

Let me try to put this a different way... what is the problem with the
non-TS one sample / RTT sampling technique?  You have noted a couple of
things:

  + That we might not be able to get *any* RTT sample.

  + That Karn's algorithm means that during some RTTs we will not get a
    sample.

  + (Are there others?)

The first of these is a clear problem that using the TS option from the
beginning can solve (although, a small tweak to retransmit SYNs with
timestamps even if the original did not have a TS may well fix this).
I do wonder how much I should care about this case.  It seems like it
will be exceedingly rare to get into this situation and further even if
we do I am not sure I care about performance (if that means including a
12-byte blob on every packet sent for this express reason).

The second case above is for sure true.  But, the question is does it
matter at all?  In other words, what is the impact on the RTO of getting
a sample during these RTTs as opposed to not?  

I ask these questions to test the assumptions.  My own thinking goes
like this .... Timestamps are essentially a general disambiguation
mechanism.  There is a clear need for some form of disambiguation when
the sequence space wraps too quickly.  That mechanism does not have to
be timestamps, but they work fine.  However, such a disambiguation
scheme is not needed when the sequence space cannot wrap too quickly.

RFC 1323 also laid out a couple reasons for using a disambiguation
mechanism for RTT timing.  One of those is because the ambiguity leads
to no RTT samples in some situations (i.e., when we retransmit).  The
other item is the [what I would consider] conjecture that more RTT
samples help the RTO.  In the time since RFC 1323 was published I think
there is some evidence that says that the need for disambiguation for
RTT sampling is thin.  Maybe I am biased by my own work.  Our work is
one data point.  What I am really looking for is other work / evidence /
experience that makes the case that we need disambiguation for RTT
sampling in anything but corner cases and then what do we gain from this
disambiguation?

allman



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