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

From: "sanjay kaniyar" <[email-masked]>
Date: Thu, 10 Jan 2002 18:57:10 -0800

1. Timestamps are bidirectional in the sense that in a segment going from 
A->B, there are 2 of them: 1:generated by A, 2:echoed value, sent by B 
originally. If the connection is doing unidirectional data transfer 
entirely, it is sufficient to have timestamps generated and sent by the 
sender in the data segments and acknowledgements echo them in the other 
direction. This is what RFC 1323 referred to as 'unidirectional use of 
timestamps'.

They chose to 'always use timestamps bidirectionally' instead because of 
reasons like simplicity etc. There is nothing new I am proposing here. I 
only quoted this to rebut your claim - 'always refers sending timestamps in 
each segment'.

3 & 4.
(a) I did answer your question. I never said it is always possible to figure 
out whether it is possible to figure out whether timestamps are necessary at 
the connection set up time (nor is it the problem I am trying to solve). All 
I am trying to do is to timestamp (and echo) segments on a connection which 
has timestamps negotiated on it only when it is necessary and useful, I said 
nothing about figuruing out whenther they should be negotiated or not.

(b) I know that to do PAWS check, every segment needs to be timstamped. 
However, to figure out whether PAWS check needs to be done or not, can be 
implementation specific because there can be many reasons within the perview 
of TCP or outside of it which could contribute to this. Note that, for a 
connection to require PAWS check it has to (i) have a transfer rate of 
greater than a threshold and (ii) have a life time greater than a threhold. 
If it is possible to determine one of these is not going to be met, there is 
no need to do PAWS on that connection. The maybe's were actually examples of 
such instances:

- A bandwidth limit is imposed on each connection {(i) fails}
- Connections are always secured with IPSEC, which has anti-replay 
protection.
- A timestamp negotiated connection starts with the assumption that PAWS is 
necessary at the peer and timestamps every segment to begin with. After it 
has an estimate of the RTT, it figures out (i) will fail because the maximum 
transfer rate is limited by the bandwidth-delay product.
- The sending application did a graceful close after submitting a buffer 
which is smaller than what is takes to cover the sequence space.
- A mail server admin knows each client has a mailbox size maximum of 1 
gigabytes and there is no danger of wrap around when a mail client tries to 
download it.

My point is that, this is really something that can't be put in a spec, but 
chosen by many factors.

(c) Again, determining whehter timestamping every segment for RTTM is an 
overkill or not should be an implemenation choice. Examples being:

- The timer on the sender TCP has a granularity of 100 ms and the first 10 
RTT measurements are all below 50 seconds.
- The last 10 RTT measurements did not vary by more than 5%.

5. My suggestion was, if a sender TCP is able to figure this out, it can 
selectively use timestamps. If the receiver also adheres to some well known 
rule, it would save sending some extra bytes in either direction. The rule 
is what I thought could be part of Eifel draft, as it was using timestamps 
in a way other than RTTM and PAWS, and could be achieved wihtout 
timestamping every segment. You might already have seen the following:
Sender-TCP would put a timestamp in a segment if:
* PAWS protection is necessary for the connection.
* An RTT measurement using timestamps is desired, and one such measurement 
is in progress. We consider a measurement to be in progress if sender has 
sent a timestamp after it started a measurement and it is not yet echoed 
back.
* Retransmission of a segment upon timeout.

Receiver-TCP would put a timestamp (or echo what it got) in an ack if:
* no more than 3 acks have been sent after any segment with a timestamp was 
received.

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: Thu, 10 Jan 2002 17:01:51 -0800 (PST)
>
> > 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.
>
>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.
>
> > 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.
>
>Point taken.
>
> > 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.
>
>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.
>
> > 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).
>
>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]
>
>
>
>
>_______________________________________________
>tsvwg mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/tsvwg

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

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

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 10 Jan 2002 20:08:44 -0800 (PST)

> only quoted this to rebut your claim - 'always refers sending timestamps in 

Correct me if I am wrong, your problem with the current timestamp
option is that it takes up 12 bytes.  Now in your "unidirectional"
timestamp scenario, isn't it true that the 12 bytes timestamp option
is still in every segments in both directions even if only the data
sender chooses to use it?  Note that I never mentioned that "unidirectional
timestamp option" is not possible.  I am trying to say that the current
timestamp option, with both time and echo value in it, works in a
specific way.  It is designed to be used for both sides.  You can come up
with your own "unidirectional timestamp option."  But it is just not the 
same as RFC 1323....  Afterall, you said that in a previous email,
"I interpret it as 'don't use timestmaps in a unidirectional way'."  So
are you now saying that RFC 1323 allows you to use timestamps in
"undirectional way?"

And think more about interoperability (you can ignore what I said about
Solaris for this purpose).  The fact is that all stacks nowadays send 
timestamp option is every segments once it is negotiated.  And the fact 
that a TCP stack will never know how an app is going to use it.  And ...
There are a lot of issues to think about.

> nothing about figuruing out whenther they should be negotiated or not.

So are you suggesting something that you don't even know how to make
it work?

> transfer rate is limited by the bandwidth-delay product. - The sending
> application did a graceful close after submitting a buffer  which is smaller
> than what is takes to cover the sequence space. - A mail server admin knows
> each client has a mailbox size maximum of 1  gigabytes and there is no
> danger of wrap around when a mail client tries to  download it.

I am not trying to discourage you.  But please think about how to
write the above code and make it works every time reliably.  Then
test it and give us some results first.  Write up a draft and we
can have more fruitful discussions.

> My point is that, this is really something that can't be put in a spec, but 

Oops, without a spec, how are you going to tell people to employ it?

							K. Poon.
							[email-masked]