Subject: Re: rfc1323 question
From: [email-masked] (Thomas Skibo)
To: [email-masked]
Date: Wed, 19 May 93 19:40:13 GMT

In article <[email-masked]>, [email-masked] writes:
|> 
|>            if (Segment contains TSopt) then {
|>                   if (SEG.TSval < TS.Recent
|> 			AND (Not idle too long)) then {
|>                          if (Send.TS.OK
|>                              AND (NOT RST) ) then {
|>                                   /* Timestamp too old =>
|>                                    *    segment is unacceptable.
|>                                    */
|>                                Send ACK segment;
|>                                Discard segment and return;
|>                          }
|>                   }
|>                   else {
|>                          if (SEG.SEQ =< Last.ACK.sent) then
|>                                 TS.Recent = SEG.TSval;
|>                   }
|>            }
|>  
|> -- Liming Wei

I think that's it.

-- 
---
Thomas Skibo     [email-masked]     Advanced Networking, Silicon Graphics, Inc.

Date: Wed, 19 May 1993 10:59:53 -0700
From: [email-masked]
Posted-Date: Wed, 19 May 1993 10:59:53 -0700
To: [email-masked]
Subject: Re: rfc1323 question
Cc: [email-masked]

> From: [email-masked] (Thomas Skibo)
> Subject: Re: rfc1323 question
>
> .... 
> > 
> > The algorithm in Braden's update to the RFC doesn't try to update
> > ts.recent if the connection has been idle too long.
> 
> Hmmmm.  I think Steve's onto something here...

Tom,

Interesting observation, so there is a need to make the connection still
as robust after idling for a month (or longer). How about this,

           if (Segment contains TSopt) then {
                  if (SEG.TSval < TS.Recent
			AND (Not idle too long)) then {
                         if (Send.TS.OK
                             AND (NOT RST) ) then {
                                  /* Timestamp too old =>
                                   *    segment is unacceptable.
                                   */
                               Send ACK segment;
                               Discard segment and return;
                         }
                  }
                  else {
                         if (SEG.SEQ =< Last.ACK.sent) then
                                TS.Recent = SEG.TSval;
                  }
           }

> It looks like if SEG.TSval is always less than TS.Recent due to wrap-around,
> TS.recent will never get updated until the senders clock wraps completely
> around to TS.Recent.  The else clause never gets executed so TS.Recent
> doesn't get updated.
> 
> Also, I think the wrap-around time was 24 *days*.
> 
> 
> ---
> Thomas Skibo     [email-masked]     Advanced Networking, Silicon Graphics, Inc.

 
-- Liming Wei

To: [email-masked]
Reply-To: [email-masked] (Thomas Skibo)
From: [email-masked] (Thomas Skibo)
Subject: Re: rfc1323 question
Date: Thu, 13 May 1993 21:38:41 GMT

> What should be done with ts.recent if TCP discovers it to be invalid
> via PAWS (idle >= 25 hours)?  I realize that it should not be used to
> drop incoming packets, but what about putting it in ts.ecr on an
> outgoing segment?

I don't think it matters if you put the stale TS.recent in TS.ecr
in the ACK.  If the segment was in-order, TS.recent should be
updated (see below).  If the segment was out-of-order, the ACK will
not acknowledge new data so TS.ecr won't be used for a SRTT anyway.
I put zero in just because I think the RFC said somehwere that zero meant
invalid TS.recent.

> 
> The algorithm in Braden's update to the RFC doesn't try to update
> ts.recent if the connection has been idle too long.

Hmmmm.  I think Steve's onto something here...

          if (Segment contains TSopt) then {
                 if (SEG.TSval < TS.Recent) then {
                        if (Send.TS.OK
                            AND (Idle less than 25 hours)
                            AND (NOT RST) ) then {
                                 /* Timestamp too old =>
                                  *    segment is unacceptable.
                                  */
                              Send ACK segment;
                              Discard segment and return;
                        }
                 }
                 else {
                        if (SEG.SEQ =< Last.ACK.sent) then
                               TS.Recent = SEG.TSval;
                 }
          }

It looks like if SEG.TSval is always less than TS.Recent due to wrap-around,
TS.recent will never get updated until the senders clock wraps completely
around to TS.Recent.  The else clause never gets executed so TS.Recent
doesn't get updated.

Also, I think the wrap-around time was 24 *days*.

> ********
> Steve Wise	IBM AWS - Austin, TX.
> Internet:	[email-masked]
> VNET:		AUSVMQ(SWISE)

---
Thomas Skibo     [email-masked]     Advanced Networking, Silicon Graphics, Inc.

Date: Thu, 13 May 93 14:36:47 -0700
From: [email-masked] (Thomas Skibo)
To: [email-masked]
Subject: Re: rfc1323 question

> What should be done with ts.recent if TCP discovers it to be invalid
> via PAWS (idle >= 25 hours)?  I realize that it should not be used to
> drop incoming packets, but what about putting it in ts.ecr on an
> outgoing segment?

I don't think it matters if you put the stale TS.recent in TS.ecr
in the ACK.  If the segment was in-order, TS.recent should be
updated (see below).  If the segment was out-of-order, the ACK will
not acknowledge new data so TS.ecr won't be used for a SRTT anyway.
I put zero in just because I think the RFC said somehwere that zero meant
invalid TS.recent.

> 
> The algorithm in Braden's update to the RFC doesn't try to update
> ts.recent if the connection has been idle too long.

Hmmmm.  I think Steve's onto something here...

          if (Segment contains TSopt) then {
                 if (SEG.TSval < TS.Recent) then {
                        if (Send.TS.OK
                            AND (Idle less than 25 hours)
                            AND (NOT RST) ) then {
                                 /* Timestamp too old =>
                                  *    segment is unacceptable.
                                  */
                              Send ACK segment;
                              Discard segment and return;
                        }
                 }
                 else {
                        if (SEG.SEQ =< Last.ACK.sent) then
                               TS.Recent = SEG.TSval;
                 }
          }

It looks like if SEG.TSval is always less than TS.Recent due to wrap-around,
TS.recent will never get updated until the senders clock wraps completely
around to TS.Recent.  The else clause never gets executed so TS.Recent
doesn't get updated.

Also, I think the wrap-around time was 24 *days*.

> ********
> Steve Wise	IBM AWS - Austin, TX.
> Internet:	[email-masked]
> VNET:		AUSVMQ(SWISE)

---
Thomas Skibo     [email-masked]     Advanced Networking, Silicon Graphics, Inc.

From: [email-masked] (Stevo Bevo-Devo Wise)
To: [email-masked]
Subject: rfc1323 question
Date: Thu, 13 May 93 14:07:42 -0600

What should be done with ts.recent if TCP discovers it to be invalid
via PAWS (idle >= 25 hours)?  I realize that it should not be used to
drop incoming packets, but what about putting it in ts.ecr on an
outgoing segment?

The algorithm in Braden's update to the RFC doesn't try to update
ts.recent if the connection has been idle too long.

Skibo's code set ts.recent=0, AND checks if ts.val can update
ts.recent.

I could be all bass-ackwards on this, so feel free to correct me...

Any thoughts?

********
Steve Wise	IBM AWS - Austin, TX.
Internet:	[email-masked]
VNET:		AUSVMQ(SWISE)