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

From: "sanjay kaniyar" <[email-masked]>
Date: Sun, 06 Jan 2002 13:35:04 -0800

Thanks Andrei.

1. I would be suprised if there are TCPs/PEPs which can't handle 
repacketization. They should probably be fixed (PMTU discovery/change, SACK 
etc. comes to mind).
2. Can you elaborate why you think this scheme would be less robust?
3. The overhead would be small in (full sized) data segments but not in 
acknowledgements.
4. If the sender-TCP considers timing every segment useful, it should go 
ahead and do so.

My argument is that, there should be allowance (and specification) for using 
timestamps only when it is necessary/useful to do so (just like SACK). The 
Eifel draft seems to me like a good place to address this (as well as the 
suggestion about restarting the retransmit timer after fast-retransmit)?

Sanjay

>From: "Andrei Gurtov" <[email-masked]>
>To: "sanjay kaniyar" <[email-masked]>, <[email-masked]>
>CC: <[email-masked]>
>Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps.
>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

_________________________________________________________________
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: "Andrei Gurtov" <[email-masked]>
Date: Wed, 9 Jan 2002 14:52:52 +0200

Sanjay,

Thanks for your points. As you see, I don't have a strong opinion about this
issue.

> repacketization. They should probably be fixed (PMTU discovery/change,
SACK

Right, but repacketization due to PMTU and SACK seems to be a rare event...

> 2. Can you elaborate why you think this scheme would be less robust?

Well, if a timestamp is put only in retransmitted segments, then lack of
timestamp is an indication of a spurious timeout. What if the receiver
implements some own bandwidth-saving policy and echos every 3rd timestamps
or so? Arguably, deliberately lying with a timestamp value is less likely.

> 3. The overhead would be small in (full sized) data segments but not in

Good point, but ACK are themself small, sent for every-second data segment
and are ROHC compressable.

> 4. If the sender-TCP considers timing every segment useful, it should go

Without timestamps it is  more complex to implement...

Andrei

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