Subject: RE: 2.5g/3g comments

From: "Farid Khafizov" <[email-masked]>
Date: Wed, 20 Mar 2002 12:36:36 -0600

Mark,
	Thank you for your comments. 
	Here are answers to your questions related to Section 2.7.
	--Farid

--------------------------------------------------------

		>Section 2.7:
		>
		>  * Lots of stuff about the RTO I don't like in this
document.  You
		>    say that the RTO is to closely follow the RTT.  I am
not sure
		>    I agree that this was a specific design goal.  I think
the RTO's
		>    job is to determine when a segment should be
retransmitted (in
		>    the absence of an ACK).  Sure, we use the RTT as the
basis.
		>    But, we also figure in the jitter.  And, in most
networks the
		>    RTO is way conservative beyond this -- i.e., it does
not try to
		>    track the RTT all that closely.
		>
		I agree. I suggest the sentence you are referring to should
be changed from

		 It was designed to follow closely the round trip time
(RTT), but is known to work poorly when delay variance is high [11].

		to 

		 It is based on measurements of the round trip delay
experienced by previous packets, and is known to work poorly when delay
variance is high [11].

		>  * "increasing frequency" --> "increasing the frequency"
		>
		>  * You note that the RFC 2988 based RTO estimator
*reduces*
		>    spurious retransmits.  What are you comparing it to?
(I.e.,
		>    there is not another standard RTO.)
		>
		here we are discussing effects of some of the
recommendations of 2988. Specifically, section (2.4) says  
		"Whenever RTO is computed, if it is less than 1 second then
the RTO SHOULD be rounded up to 1 second".
		Some TCP implementations do not follow this recommendation
(e.g. Solaris2.8 has min_RTO=400ms).
		We did performance comparison of Solaris and various other
OSs with RTO_min = 1 sec and were reporting
		our observations.

		I also found some typos in the paragraph that Mark is
referring to. 
		Perhaps it should be re-written as follows

		  "Experiments have shown that RTO algorithm implementations
compliant
		   with RFC2988 [32] recommendations (e.g., minimum RTO=1
sec and initial RTO=3 sec)
		   reduce the number of spurious re-transmissions.  Although
RTO timer
		   management as specified in RFC2988 is not mandatory,
restarting the
		   retransmission timer when an ACK is received (section 5.3
of RFC2988)
		   will further reduce (or even eliminate) spurious
retransmissions.
		   However, it may not be possible to completely eliminate
spurious retransmissions if secondary
		   effects, such as TCP segment loss, are combined with
Bandwidth
		   Oscillation."

		>  * You note that increasing the RTT sampling can reduce
spurious
		>    timeouts in BO systems.  You should cite something here
or
		>    remove the statement.
		This observation is based on our studies described in [49].
		Because of the space constrain we couldn't elaborate on the
details and only mentioned the fact.
		More detailed analysis is available in another paper Mehmet
Yavuz and I submitted for publication.
		Without timestamp, after timer expiration larger RTT samples
from narrow-band channel may 
		not be used in RTO calculation (Karn's algorithm).
Especially if a new burst 
		is allocated after a relatively short time period. This can
force RTO to stay at a low value making it easier 
		for the timer to expire again when the new burst is
released.

		>  * You note that increasing cwnd is one way to avoid
spurious
		>   RTOs.  I don't understand this.  When do we increas
cwnd.  This
		>    needs described better (and, a reference given, if
possible).
		As above, the detailed description of this with simulation
results is in the paper Mehmet and I submitted for publication.
		Let RTT_high and RTT_low denote RTTs for conditions with
high and low bandwidth, respectively.
		Let RTO_high be the value of RTO at the time when bandwidth
suddenly changes from high to low.
		If the retransmission timer is restarted when ACKs are
received (section 5.3 of 
		RFC2988), then conditions for avoiding spurious timeout can
be approximated as
		RTO_high > RTT_low - RTT_high. Increasing CNWD beyond the
DBP increases RTO (via increased RTT),
		while the delta between RTT_low and RTT_high doesn't change
much.

--------------------------------------------------------