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

From: "sanjay kaniyar" <[email-masked]>
Date: Wed, 09 Jan 2002 19:59:54 -0800

1. Data transfer could be unidirectional, in which case timestamps would 
only be necessary for the direction of data flow. Somewhere in the 1323, 
they mention that they chose to 'always' use it bidirectionally for the 
purpose of simplicity etc.

2. I did not misinterpret your comment, I understood that Solaris does not 
reject segments without timestamps. My point is that, the behavior of 
'considering the peer to be not able to generate timestamps accurately just 
because some segments did not have timestamps' is what is Solaris speicific.

3. It may not be necessary to time every segment in cases like, for example, 
where it does not change much at all? or maybe timing every 3rd segment is 
just as good? or maybe it is too small and the sender TCP is going to stick 
to its attainable minimum?

4. It is possible to say a connection does not need PAWS check based on the 
perceived RTT and the advertised receive window size, for example. Or if 
there is a limit set on the maximum bandwidth a connection can use etc.

5. Whether 12 bytes in each segment and ack is an overhead or not (with ROHC 
or without) is quite subjective, I think. To me, a single byte that goes on 
the wire that does not have any purpose to it is an overhead and should be 
avoided if it is not too much of an engineering overhead (and I believe with 
timestamps it is not).

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 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?"
>
> > 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.
>
>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.
>
> > 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.
>
>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?
>
> > 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!).
>
>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]
>
>

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

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

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 10 Jan 2002 17:01:51 -0800 (PST)

> purpose of simplicity etc.

Hmm, are you saying that one side sets the timestamp option and the
other side does not echo it back?  Can you be more specific on exactly
the format you are talking about?  Have you thought about the mechanism 
you are proposing?  Are you trying to come up with a new timestamp option
for unidirectional transfer?  Please tell us more how it should work.

> because some segments did not have timestamps' is what is Solaris speicific.

Point taken.

> there is a limit set on the maximum bandwidth a connection can use etc.

I guess you didn't answer my questions at all.  How do you know at
the connection setup time that timestamp should be used ?  TCP
knows nothing about RTT (well, maybe temporal sharing of some info from
a previous connection can help), the other side's advertised window
(active opening), ...  And I believe you missed the reason for PAWS, it 
has to do with the maximum transfer bandwidth, not really RTT related, and
is not easy to measure at the end host...  And I believe you agreed that 
for PAWS to work, every segments need to have the timestamp option.  So
how should your proposed change to use timestamp option for retransmission
indication work?

You should think more about what you are proposing before you can say 
that it is easy to do (there are too many maybes in your statements...). 
Please remove those maybes and state exactly when RTTM is an overkill and 
show us how this can be determined at connection setup time.  Also note that
whether a TCP stack makes use of all RTT samples to calculate RTO and which
samples to use can be an implementation choice.

> avoided if it is not too much of an engineering overhead (and I believe with 

In what way does this "engineering decision" support your comment about
the main reason of limited use of timestamp option?  Honestly, I don't
know if it is really of limited use or not.  Maybe you can show us the
data.  And please show us what you meant by "not much of an engineering 
overhead."  That is the exact way of how your proposal works.

							K. Poon.
							[email-masked]