Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps.

From: "sanjay kaniyar" <[email-masked]>
Date: Wed, 09 Jan 2002 18:47:00 -0800

I interpret it as 'don't use timestmaps in a unidirectional way'.

Besides, I don't know of a TCP which would reject segments it receives on a 
timestamp negotiated connection just because it does not have timestamps. 
From what you said, Solaris also accepts such segments. The rest of the 
interpretation seems to be Solaris specific.

As I suggested earlier, if PAWS check is necessary (easy to figure out for 
the sender), every segment should be timestamped. For RTTM, timestamping and 
taking an RTT measurement on every segment is really an overkill in a lot of 
cases.

In my opinion, the primary reason why TCP-clients do not negotiate a 
timestamp option today is the constant overhead in terms of bandwidth it 
causes. If this were to be on a need only basis (like SACK), it would 
probably be more widely negotiated and it would enable wide spread 
deployment of Eifel-capable TCPs (probably, every mobile node would 
negotiate timestamps!).

Sanjay

>From: Kacheong Poon <[email-masked]>
>Reply-To: Kacheong Poon <[email-masked]>
>To: sanjay kaniyar <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps.
>Date: Wed, 9 Jan 2002 18:24:37 -0800 (PST)
>
> > I browsed through 1323 but could not find it speicify that timestamps 
>should
> > be sent in every segment, once negotiated. However, I did find the  >
>following: >
> > "For simplicity and symmetry, we specify that timestamps always be sent 
>and
> > echoed in both directions."
> >
> > Is this what you were referring to? Not sure it implies what you said.
>
>Yes.  Well, I intrepret always to be for every segments...  How do you
>interpret that?  And I believe all TCP implementations I have encountered
>always send a timestamp option in every segments.  As a matter of fact,
>I am not sure if the RTTM or PAWS as specified work correctly if timestamp
>option is not sent and echoed in every segments...
>
>							K. Poon.
>							[email-masked]
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 9 Jan 2002 19:12:49 -0800 (PST)

> I interpret it as 'don't use timestmaps in a unidirectional way'.

Hmmm, a TCP connection is always bidirectional.  And the option has
to be negotiated by both sides.  What do you really mean by  
"unidirectional?"

> interpretation seems to be Solaris specific.

It seems that you misinterpreted my comment.  My comment is about
ignoring the timestamp option, not rejecting segments.  This is
a major difference.  And the other comment is that I don't know of
any implementation which does not send timestamp option in every
segment (besides, for example, RST) once it is negotiated at the
beginning.  And for the sake of the RTTM and PAWS, I believe it
is safe to assume that if one side suddenly stops sending timestamp
option, there must be something wrong and RTTM and PAWS will not
be reliable.

> taking an RTT measurement on every segment is really an overkill in a lot of 

Hmmm, when you say it is easy to figure out whether PAWS is needed,
can you explain further?  Nowadays, I believe most computers have
100Mbps NIC (I believe soon all gadgets with network connection will
be like that).  RFC 1323 clearly states the problem here.  So are
you saying that all connections should use PAWS then?  I believe
you are not suggesting that.  Maybe you can explain your easy method.
And can you also explain how you can tell taking an RTT measurement on
every segment is an overkill at the beginning of a connection?

> deployment of Eifel-capable TCPs (probably, every mobile node would 

Well, assuming that timestamp option is really rarely used nowadays,
I believe there can be many other reasons...  Not all stacks support
timestamp option (there are still many old stacks out there...).  
The option is not turned on be default. ...  Honestly, given today's
network and ROHC for slow links, the 12 bytes overhead is really nothing
for most people...  This is my own conjecture without support.  If
you can substantiate your own overhead conjecture, I'll buy it (-:

							K. Poon.
							[email-masked]

---

From: Richard Wendland <[email-masked]>
Date: Fri, 11 Jan 2002 04:18:49 +0000 (GMT)

> I don't know of
> beginning.

I do see some such behaviour, but it's not that common: timestamp on
SYN-ACK but not subsequently.  It's probably caused by devices like HTTP
load-balancers (possibly old or mis-configured), I don't see enough of
such behaviour to suggest it's due to a major TCP implementation.

Try HTTP connections to: www.us.army.mil, www.fairchildsemi.com,
www.goretex.com, www.westin.com, www.lclark.edu.

I also see the opposite behaviour, no timestamp on SYN-ACK but timestamps
on subsequent segments.  To see this try HTTP to: www.arl.army.mil,
www.bns.rutgers.edu, www.coolbean.com, www4.whirlpool.com.

But I doubt it is worth specially accommodating this strange behaviour.

NB I see this from a FreeBSD system with net.inet.tcp.rfc1323=1.

> And for the sake of the RTTM and PAWS, I believe it

That seems a fair judgment to me at present.

	Richard
-- 
Richard Wendland				[email-masked]