Subject: Re: Doubt regarding the MANAGING THE RTO TIMER

From: [email-masked]
Date: Tue, 11 Dec 2001 10:58:39 -0600 (CST)

One comment on the RTO discussion w.r.t. Timestamps:

Without the Timestamps option, due to the Karn algorithm,
you do not get an RTT measurment when there is packet loss.
If you are losing 1 packet per RTT, you get into a state
where you don't get any packet timing information.

When using Timestamps, even in the face of packet loss,
you can guarantee to get at least one valid timing per RTT.
Or, more correctly, with Timestamps, anytime you get an
ack for new data, you can reliably use it's timestamp
to get a new RTT measurement.

		-David Borman, [email-masked]

---

From: Phil Karn <[email-masked]>
Date: Tue, 11 Dec 2001 11:21:40 -0800

>Without the Timestamps option, due to the Karn algorithm, you do not
>get an RTT measurment when there is packet loss.  If you are losing 1
>packet per RTT, you get into a state where you don't get any packet
>timing information.

Dave,

No question -- TCP timestamps are a *much* better solution to the
RTT measurement problem than my algorithm.

But what you say about my algorithm is not quite true. Its whole point
is to ensure that you'll eventually get an accurate RTT measurement
after a retransmission no matter what the original RTO setting
was. You won't "get into a state" where no further timing info
arrives.  Unless, of course, *none* of the retransmissions get through,
in which case timestamps wouldn't work much better.

Phil

---

From: Liaw Yong Shyang <[email-masked]>
Date: Wed, 12 Dec 2001 10:15:02 +0800

Hi,

I'm looking at using SACK option to update RTT during fast recovery.  What 
do you think of it?

RTT sample is taken using Karn's algorithm to avoid ambiguous 
acknowledgement from retransmitted packets, and must be taken at least once 
per RTT unless Karn's algorithm prevents it [RFC 2988].  During 
fast-recovery, no RTT sample is taken since duplicate acknowledgements are 
returned.  Duplicate acknowledgement does not indicate the triggering 
packet.  However, it is possible to infer the triggering packet from SACK 
option in the duplicate acknowledgement with SACK option, since the 
triggering packet is in the first SACK block of the SACK option.  Hence, by 
checking "rtt_seq" (the sequence number when RTT sample is taken) with the 
first SACK block in duplicate acknowledgements, RTT sample can be updated.

The algorithm:

If (right edge of the 1st SACK block > rtt_seq and rtt_active) {
                 rtt_active = 0;
                 update RTT sample;
}

---

From: Noritoshi Demizu <[email-masked]>
Date: Thu, 27 Dec 2001 17:58:59 +0900

> to get a new RTT measurement.

I think RFC1323 needs to be updated as described in [1] and [2] bellow.

If one implemented timestamps option just as described in RFC1323, and
when a data packet was retransmitted because the ACK packet was lost,
the measured RTT could be larger than the real value.  To fix this
problem, at least the condition of the rule (2) of section 3.4 in
RFC1323 needs to be updated.

  The condition of the rule (2) of Section 3.4 in RFC1323 is:
        SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN

  The condition of [1] and [2] is:
        SEG.TSval >= TSrecent && SEG.SEQ <= Last.ACK.sent

  The condition of FreeBSD 4.4R is: SEG.SEQ <= Last.ACK.sent
  The condition of NetBSD 1.5.2 is the same as RFC1323.
  The condition of OpenBSD 3.0 is the same as [1] and [2].
  (Sorry, I do not know of the Linux implementation.)

[1] R. Braden, "TCP Extensions for High Performance: An Update", Jun 1993
    http://www.kohala.com/start/tcplw-extensions.txt
[2] V. Jacobson, R. Braden and D. Borman, "TCP Extensions for High
    Performance", Feb 1997
    http://www.watersprings.org/pub/id/draft-ietf-tcplw-high-performance-00.txt

I hope RFC1323 will be updated.

Noritoshi Demizu

---

From: Craig Partridge <[email-masked]>
Date: Mon, 31 Dec 2001 15:00:27 -0500

>I hope RFC1323 will be updated.

The usual effective way to update an RFC is to do it yourself -- that is,
write the draft, detailing all the issues and the solution, send it around
for discussion, then send it to the IETF.

One advantage is that this process sometimes reveals either (a) that the
protocol is OK after all or (b) that the problems are worse than you
thought.

Craig