Re: [tcpm] Re: RFC 1323: Timestamps option
Joe Touch <touch@isi.edu> Wed, 30 May 2007 10:41 UTC
Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtLcK-00057m-Ms; Wed, 30 May 2007 06:41:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtLcI-00057D-3P for tcpm@ietf.org; Wed, 30 May 2007 06:41:22 -0400
Received: from s-utl02-dcpop.stsn.net ([72.255.0.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtLcG-0008Pc-Jt for tcpm@ietf.org; Wed, 30 May 2007 06:41:22 -0400
Received: from s-utl02-dcpop.stsn.net ([127.0.0.1]) by s-utl02-dcpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007053006411608571 ; Wed, 30 May 2007 06:41:16 -0400
X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.099,BAYES_00: -1.665
X-Spam-Level:
Received: from [127.0.0.1] ([10.24.135.59]) by s-utl02-dcpop.stsn.net; Wed, 30 May 2007 06:41:13 -0400
Message-ID: <465D54A8.9000100@isi.edu>
Date: Wed, 30 May 2007 03:40:40 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: David Borman <david.borman@windriver.com>
Subject: Re: [tcpm] Re: RFC 1323: Timestamps option
References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> <F8F82A2D-A73F-49C1-A1AA-B385214D60DF@windriver.com>
In-Reply-To: <F8F82A2D-A73F-49C1-A1AA-B385214D60DF@windriver.com>
X-Enigmail-Version: 0.95.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964
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>
Content-Type: multipart/mixed; boundary="===============1265392090=="
Errors-To: tcpm-bounces@ietf.org
Hi, David, I had some questions below... David Borman wrote: > Hi, > > I've been having some off-line discussion about how to turn on > Timestamps mid-stream, and I'm coming to a clearer picture. I'm now now > leaning towards changing to allow this to happen in a standard way. I > think I can now more clearly enumerate the specific issues about > enumerating them mid-stream. > > First, do you or do you not include Timestamps in the SYN exchange, and > how much do you care about interoperability with existing 1323 > implementations? If you do not include Timestamps negotiation, then I > would expect that mid-stream enabling of Timestamps would only work on > modified hosts that understand the new rules. > > I've come up with a variation on Option #2 > > Option 2a: > ---------- > The Timestamps option is sent only in the SYN and SYN,ACK packet. If > both sides understand deferred enabling of Timestamps, then the > connection will continue without Timestamps until one of them initiates > Timestamps by including it in a packet. Once Timestamps have been sent > or received after the initial SYN,ACK, they are then sent in all packets > for the duration of the connection. > > This has the advantage of knowing up front that the other side > understands the Timestamps option, so when you later decide to enable > them, you just turn them on and start sending them, you don't have to > try to figure out midstream whether or not the other side understands > Timestamps. When talking to an RFC-1323 implementation, since the other > side will include Timestamps in all packets, the option will be enabled > right away How is reordering handled? I.e., all new packets may be stamped, but reordering could affect how that's seen at the receiver. (see below...) ... > However, I do have an idea for a deterministic way to know when > Timestamps have been fully enabled. When you first start sending > Timestamps (either initiating, or in response to receiving a > Timestamps), you fill in the exact same value for TSval in every packet > that you send, until you receive a packet with a TSecr equal to that > value. At that point you know that Timestamps are now enabled on both > sides, and you start sending new TSval values. You don't do any RTT > calculations until you get a packet that acknowledges new data, and has > a TSecr value that is beyond the initial TSval used. This should > address all three scenarios: the data receiver initiating enabling > Timestamps, the data sender initiating enabling Timestamps, and both the > sender and receiver enabling Timestamps at the same time. PAWS will > work just fine, because it doesn't require the clock to tick for each > packet, just at least once for each sequence space. The problem with enabling options mid-stream is that you haven't cleared the packets from the system; this is not the case during SYN exchange. I'm wondering whether there's a case where you could have started sending new TSvals, and you get a new data ACK (and start calculating RTTs), and then a packet comes in out of order (e.g., duplicated or SACK). Could this corrupt the RTT? Could this ever happen? > So, when a deferred Timestamps implementation connects to an RFC-1323 > implementation, what should be the desired behavior? > a) Timestamps are enabled for the entire connection > b) Timestamps are disabled for the entire connection > I think it should be "a". This is asking whether deferred timestamps disables legacy 1323 use, IMO, and I agree that the only conclusion is (a). Joe > On Jan 26, 2007, at 12:33 PM, Borman, David wrote: > >> One of the topics that has been discussed in the past for the >> revision of RFC 1323 is to relax the requirement on when to send the >> Timestamps option. I'd like to come to some resolution on this issue. >> >> Current: >> The Timestamps option is negotiated during the initial SYN exchange. >> If both sides support it, then every packet in the connection has to >> have the Timestamps option. >> >> Option #1 >> --------- >> The proposed change is to relax the requirement that Timestamps have >> to be negotiated in the initial SYN, and instead allow them to be >> enabled later on in the connection. At the time 1323 was originally >> written, there was a big concern for legacy TCP stacks that didn't >> handle unknown options in the middle of the connection, but were able >> to properly ignore unknown options during the SYN exchange. But that >> was a long time ago, and unknown options in the middle of a TCP >> connection *shouldn't* be as big of an issue anymore. >> >> The rules for enabling Timestamps mid-stream would be: >> 1) If you receive a Timestamps option mid-stream, you can enable >> Timestamps. From then on, every packet sent will need to contain a >> Timestamps option. >> 2) If you want to enable Timestamps mid-stream, you can only do so on >> a data packet. You record the sequence number of that data packet, >> and include the Timestamps option on every packet from then on, until >> you receive an ACK for that sequence number. If at any time you >> receive a packet with the Timestamps option, then they are enabled >> for the rest of the connection. If you do not receive a packet with >> a Timestamps option by the time you get the ACK for that initial >> sequence number, then the other side has not enabled Timestamps and >> you must stop sending Timestamps for the duration of the connection. >> >> The restriction on only being able to initiate Timestamps on a data >> packet is that they are the only packets that are delivered reliably, >> so determining whether or not the other side supports them is >> deterministic by getting the ACK for that data. >> >> >> Option #2 >> --------- >> This is similar to Option #1, but not quite the same. In this case, >> the Timestamps would be negotiated in the initial SYN as before, but >> then no additional packets would have Timestamps options. At any >> point during the connection, either side can enable the use of >> Timestamps just by starting to send them. Since we already know that >> both sides support them, once you start sending them you never stop. >> And if you every receive one, you are then required to also send them >> for the duration of the connection. >> >> The question then is, how do you negotiate Timestamps without turning >> them on? My suggestion would be to send a Timestamps option with the >> special format TSval=0,TSecr=0. If you receive this in a SYN, then >> the request is to negotiate knowledge of the Timestamps option. The >> returning SYN,ACK would also need to contain TSval=0,TSecr=0 to >> complete the negotiation. If you are connecting to a site that >> doesn't support this feature but does support Timestamps, it would >> respond with TSval=xxx,TSecr=0. At that point, Timestamps are now >> enabled. The downside of this is that now the originator has started >> their Timestamps values at 0, and must continue from there with their >> timestamps; they can't just suddenly jump to some arbitrary value >> because that could break PAWs. >> >> >> Option #3 >> --------- >> Do nothing, and leave Timestamps alone as they are currently >> defined. You negotiate them in the SYN, and then include them in >> every packet from then on. >> >> One of the issues with Timestamps is that the TSecr value is defined >> to be valid anytime the ACK bit is set. This works well with the >> initial SYN negotiation, but when you enable Timestamps midstream, >> the initiator has to send a Timestamps option with an invalid TSecr >> value, but the ACK bit will be set. That's the case for both of the >> previous options. >> >> So why should we change things? My recollection was that the primary >> motivation was to conserve option space, to avoid having to put in >> the extra 12 bytes of TCP options on every packet until we get to the >> point where the sequence space might wrap, and then turn them on so >> that we can get PAWS to protect the rest of the connection. But I'm >> not sure I buy that argument. One of the things that you lose by >> deferring enabling Timestamps is that you don't get the RTT >> measurements that Timestamps provide. Without Timestamps, using the >> typical BSD algorithm of timing one segment and waiting for an ACK, >> and adding in the Karn algorithm that you have to invalidate any >> measurements if you had to retransmit in that window, means that at >> best, you'll get one measurement per RTT. At worst, you can get in a >> state where you never get a valid RTT measurement. When you use the >> Timestamps option, the worst case is that you'll only get one >> measurement per RTT, and the best case is that you'll get multiple >> valid samples, >> >> My viewpoint >> ------------ >> Right now, I'm inclined to leave the Timestamps option alone; you >> negotiate it during the SYN exchange, and then include it on every >> packet. I'm willing to be convinced otherwise, but now I've placed a >> stake in the ground, and the mailing list will have to decide if >> there is sufficient reason to change the behavior. >> >> -David Borman >> >> > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment
_______________________________________________ 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