Re: [tcpm] RFC 1323: Timestamps option

Sally Floyd <sallyfloyd@mac.com> Fri, 26 January 2007 19:10 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWSn-0006Rq-4w; Fri, 26 Jan 2007 14:10:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWSl-0006Ri-H9 for tcpm@ietf.org; Fri, 26 Jan 2007 14:10:15 -0500
Received: from smtpout.mac.com ([17.250.248.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWSj-0005fF-48 for tcpm@ietf.org; Fri, 26 Jan 2007 14:10:15 -0500
Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id l0QJA4K1026813; Fri, 26 Jan 2007 11:10:08 -0800 (PST)
Received: from [192.168.1.64] (adsl-70-231-226-78.dsl.snfc21.sbcglobal.net [70.231.226.78]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id l0QJA0bm022398; Fri, 26 Jan 2007 11:10:01 -0800 (PST)
In-Reply-To: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com>
References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <c05cffe401e9ca52669260b778ba881a@mac.com>
Content-Transfer-Encoding: 7bit
From: Sally Floyd <sallyfloyd@mac.com>
Subject: Re: [tcpm] RFC 1323: Timestamps option
Date: Fri, 26 Jan 2007 11:09:59 -0800
To: David Borman <david.borman@windriver.com>
X-Mailer: Apple Mail (2.624)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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>
Errors-To: tcpm-bounces@ietf.org

David -

I don't have any feedback about *when* to negotiate timestamps, but I 
do have some feedback
about how the RTO should be estimated when timestamps are used.  Just 
as something
to include in a revision of RFC 1323...

Regards,
- Sally
http://www.icir.org/floyd/

Here is some old email of mine on this:

> To: mallman@icir.org
> cc: "Ethan Blanton" <eblanton@cs.purdue.edu>du>,
>     "Aaron Falk" <falk@isi.edu>du>, "Ted Faber" <faber@isi.edu>du>,
>     touch@isi.edu, "Scott Bradner" <sob@harvard.edu>
> Bcc:
> From: Sally Floyd <floyd@icir.org>
> Subject: Re: Mark Allman: would this fly?
> Date: Tue, 09 Aug 2005 13:45:18 -0700
> Sender: floyd@cougar.icir.org
>
> Mark -
>
> >> It is worth noting that if timestamps are being used, with the
> >> currently-specified time constant for estimating the average RTT and
> >> variance, then the first thing that needs to be done is to change 
> the
> >> time constant so that the average RTT and the variance aren't being
> >> estimated over a small fraction of a window of data (as is possible
> >> when timestamps are used with current parameters).  (Unless this has
> >> already been fixed in recent standards, and I just missed it...)
> >
> >I don't think this has been fixed.  And, I don't see this potential 
> i-d
> >as the place to fix it.  I wanted this to be an alternative response 
> to
> >spurious timeouts, not some general RTO change.  Does that make sense?
>
> It makes sense.  Except that if in fact the average and variance are
> being estimated over a small fraction of a window size, because
> the TCP connection is using timestamps and has a moderate-to-large
> congestion window, then the estimated variance might be very small
> (because it is measured over RTTs calculated essentially from the
> most recent N packets, for N < cwnd, and the burstiness for rtts for
> the most recent fraction of a cwnd might be quite small).
>
> So in that situation, increasing the multiple of the variance might
> have almost no effect on the RTO, because the variance might be
> unrealistically small when calculated only over this small time
> scale.  And changing the weight for estimating the rtt average and
> variance to make sure that the average RTT and variance are estimated
> from RTTs calculated over a period of several rtts, might make your
> technique much more powerful, by making the calculated variance
> much more interesting and useful.  Worth noting, at any rate.  IMHO.
>
> - Sally


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