Re: [tcpm] Re: RFC 1323: Timestamps option

I had assumed that you can "fake" paws as follows: once you receive a late
timestamp negotiation (in either role), you treat any later untimestamped
segments as though they bear the timstamp just before the earliest time stamp
seen.   I believe that this is optimal, given other assumptions.

I think it also works well enough to treat any later untimestamped
segments as though they bear the timestamp just before the the most recently
received timestamp.  This is actually the same if the timestamps do not
advance during the negotiation RTT.   (Well enough means that the failures
are neither frequent nor serious).

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Wed, 30 May 2007, David Borman wrote:

> Hi Joe,
>
> On May 30, 2007, at 5:40 AM, Joe Touch wrote:
>
> > 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...)
>
> The receiver won't have fully turned on timestamp support until it
> has sent a TSval and received a TSecr with the same value.  The only
> issue is if you turn on full PAWS support when you receive the first
> packet with a timestamp option, and then start dropping any packets
> that don't contain a timestamp option.  So, you don't turn on PAWS
> until you've gotten a TSecr with your initial TSval.  And even if you
> should happen to drop reordered packets without the timestamp option,
> TCP retransmissions should take care of any dropped data.
>
> >
> > ...
> >> 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.
>
> That why you keep sending the the same timestamp until you see it in
> at least one TSecr, and you don't use that timestamp for any RTT
> calculations.
> >
> > 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?
>
> Besides being an ACK for new data, it also has to have a TSecr beyond
> the initial timestamp you sent.  By the time both of those things are
> true, you should be into normal RFC-1323 processing.
>
> >
> >> 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 mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm