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

From: "sanjay kaniyar" <[email-masked]>
Date: Fri, 11 Jan 2002 16:13:59 -0800

1. You seem to be responding to something that is not even remotely implied 
by anything I said. Going over the mail thread again would help.(I am not 
trying to use unidirectional timestamps, wonder what made you think so!!).

I agree with your point in the second pragraph, and there could very well be 
interop issues.

3 & 4.
(a) Same as 1 above. What made you think I suggested a way to figure out 
timestmaps are needed or not at connection setup time?

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 20:08:44 -0800 (PST)
>
> > 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'.
>
>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.
>
> > 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.
>
>So are you suggesting something that you don't even know how to make
>it work?
>
> > (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.
>
>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
> > chosen by many factors.
>
>Oops, without a spec, how are you going to tell people to employ it?
>
> > (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.
>
>							K. Poon.
>							[email-masked]
>
>
>
>_______________________________________________
>tsvwg mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/tsvwg

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

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

---

From: Mark Allman <[email-masked]>
Date: Mon, 14 Jan 2002 07:24:35 -0500

While I don't agree with much of your note I have said everything I
want to say more than once in this thread.  So, just this...

> It seems that rfc2988 with patches from the tech report is quite
> conservative and the sender is unlikely to go into chain of
> spurious timeouts. It may well be that letting Eifel to handle
> occasional delay spikes is a better solution than to invent some
> overly complicated timer to predict them.

Occasional spurious retransmits do not bother me at all.  In that
case, we should be able to revert the CC state (whatever we decide
that means) and continue on.  The case that concerns me more is that
of persistent conditions that cause spurious retransmits in the
network to occur regularly.  In that case, I think we need some sort
of throttle to make sure that we are not being over-aggressive in
piling unnecessay packets into the network.  That throttle could be
any number of things: adjusting what RTO algorithm we use, tweaking
the current algorithm on the fly a bit, adjusting the number of dup
ACKs needed to fast retransmit, turning the CC state undo-ing off if
a certain percentage of our transmissions are spurious, etc., etc.,
etc.  There are any number of a ton of things that one could
envision doing.  I am not advocating for any one particular scheme,
just argueing that there needs to be something that keeps us from
the case of agressively transmitting needless junk into the
network. 

allman

---
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/