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

From: "Andrei Gurtov" <[email-masked]>
Date: Sun, 6 Jan 2002 13:57:10 +0200

Sanjay-

A number of conerns were raised with such approach. First, it leads to
frequent repacketization of data segment as follows. Original segments sent
without the timestamp option each carry MSS bytes of data. After RTO,
segments have the timestamp option which occupies 12 bytes leaving less
space for data. Consequently, the sequence of retransmitted segments will be
different than of original segments. In principle, this type of behavior is
legal and used by BSD systems. However, there are probably some TCPs and
PEPs around that cannot handle it well. Thus,  'be conservative in what you
send' approach may apply here.
The other concern is that the detection  may be less robust in presense of
lost segments and ACKs.

The timestamp overhead is not that big for large MTU (0.8% for 1500 B) and
ROHC is expected to compress TCP options. Additionally, there is some
evidence that timing every segment with timestamps is good on
bandwidth-limited paths. Based on these considerations, the current
understanding is to include timestamps in every segment.

Andrei

----- Original Message -----
From: "sanjay kaniyar" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 01, 2002 12:53 AM
Subject: [Tsvwg] Eifel draft and usage of time-stamps.

> I have seen the spurious retransmission problem occur in my experiments
with
> GPRS networks. The frequency of occurrence seems to be quite small though,
> about once or twice during the transmission of a 500 K Bytes file with an
> MSS of 1500 bytes. Ofcourse, I agree that this frequency could vary with
> different networks. In this case, however, incurring 12 bytes of overhead
in
> every segment and acknowledgemnt seems quite a bit.
>
> Since it is not necessary to timestamp every segment and acknowledgement
> when timestamp option is enabled on a connection, we could do it only when
> it is necessary. It is the sender which determines when this is necessary,
> and the following approach is backwards compatible in the sense that a
> sender taking this approach would work properly with a receiver adhering
to
> the traditional time-stamping approach and vice-versa.
>
> Sender-TCP would put a timestamp in a segment if:
> (a) PAWS protection is necessary for the connection.
> (b) 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.
> (c) Retransmission of a segment upon timeout.
>
> Receiver-TCP would put a timestamp (or echo what it got) in an ack if:
> (a) no more than 3 acks have been sent after any segment with a timestamp
> was received.
>
> An Eifel-TCP-Sender would consider an acknowledgement received after a
> timeout to be for the original segment if (a) the acknowledgemet does not
> contain a timestamp or (b) the echoed timestamp is less than the timestamp
> sent in the retransmitted segment.
>
> Thanks,
> Sanjay
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
>

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

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 9 Jan 2002 14:36:43 -0800 (PST)

> sender taking this approach would work properly with a receiver adhering to 

I may have missed some of the discussions in this thread....  But
I believe it is specified in RFC 1323 that if timestamp option is
used, it has to be in every TCP segments sent.  As a matter of fact,
in Solaris, if one side suddenly stops sending timestamp option,
the Solaris side will also stop sending it and will ignore future
timestamp option as it thinks that the other must have some problems
and the timestamp option may not provide correct info.  So I'm afraid
your suggestion may not be backward compatibile with RFC 1323.

							K. Poon.
							[email-masked]