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>, > "Aaron Falk" <falk@isi.edu>, "Ted Faber" <faber@isi.edu>, > 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
- [tcpm] RFC 1323: Timestamps option David Borman
- Re: [tcpm] RFC 1323: Timestamps option Sally Floyd
- Re: [tcpm] RFC 1323: Timestamps option Mark Allman
- Re: [tcpm] RFC 1323: Timestamps option David Borman
- Re: [tcpm] RFC 1323: Timestamps option Matt Mathis
- Re: [tcpm] RFC 1323: Timestamps option Fernando Gont
- Re: [tcpm] RFC 1323: Timestamps option David Borman
- Re: [tcpm] RFC 1323: Timestamps option David Malone
- Re: [tcpm] RFC 1323: Timestamps option Mark Allman
- Re: [tcpm] RFC 1323: Timestamps option Mark Allman
- Re: [tcpm] RFC 1323: Timestamps option Richard Wendland
- [tcpm] RE: RFC 1323: Timestamps option Mahdavi, Jamshid
- Re: [tcpm] RFC 1323: Timestamps option Kacheong Poon
- Re: [tcpm] RFC 1323: Timestamps option Gavin McCullagh
- [tcpm] Re: RFC 1323: Timestamps option David Borman
- Re: [tcpm] Re: RFC 1323: Timestamps option Joe Touch
- Re: [tcpm] Re: RFC 1323: Timestamps option David Borman
- Re: [tcpm] Re: RFC 1323: Timestamps option Matt Mathis
- Re: [tcpm] Re: RFC 1323: Timestamps option Joe Touch
- Re: [tcpm] Re: RFC 1323: Timestamps option David Borman
- Re: [tcpm] Re: RFC 1323: Timestamps option David Borman
- Re: [tcpm] Re: RFC 1323: Timestamps option Matt Mathis
- Re: [tcpm] Re: RFC 1323: Timestamps option Joe Touch