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