Subject: Re: [Tsvwg] SCTP RTO / RTTVAR calcuation - difference with RFC2988

From: Mark Butler <[email-masked]>
Date: Tue, 27 Dec 2005 00:21:18 -0700

Vern Paxson wrote:

>>>   RTO <- SRTT + max (G, K*RTTVAR)
>>>   where K = 4
>>>
>>>RFC2960 on the other hand specifies:
>>>
>>>   Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <- G.
>>>    RTO <- SRTT + 4 * RTTVAR
>>>      
>>>
>
>I don't recall why we dropped the line for RFC 2988, and don't see any
>indication in my email archives about this either.  In general, it seems
>sound to me to not presume you can accurately measure anything smaller than
>your clock granularity, and since it's better for RTTVAR to be conservative,
>the rule in RFC 2960 strikes me as correct.  Trying to push on it further
>for things like optimizing ECNE tests strikes me as imprudent; at best,
>it'll gain just a bit, but at worst, you'll make significant errors.
>  
>
Thanks for checking.   Of course, how RTTVAR is used an independent 
issue.  My main point is that to the precision of the best available 
arithmetic, RTTVAR may be zero, and collapsing it with the RTTVAR = 1 
case loses information.  If the SRTT is 1, it is unlikely that the RTT 
variation is properly 1 as well, on most paths anyways.  The difference 
for a stable 10 ms path (with a 10 ms clock) is 20 ms for TCP and 50 ms 
for SCTP.   Or 10 ms vs 40 ms for paths too fast to measure.   I think 
the only reason this is not noticed is that RTO Min is normally one 
second or more, with 10 ms clocks.

One other anomaly with the specification is the if RTTVAR = 0 line 
appears to written only for clock granularity arithmetic, where the use 
of "G" implies rather that G may be something other than 1.  If one is 
using fixed point arithmetic to get more accurate results for whatever 
reason, the RFC2960 rule is potentially unstable as written. (i.e. if 
that is what is wanted it should be written if RTTVAR is less than G 
adjust RTTVAR <- G). 

Suppose I measure my RTTs as 0, 0, 0, G, 0, 0, 0, G, 0, 0, 0, G,....  If 
I use arithmetic with G=256, alpha=1/4 and beta=1/8 I should get an SRTT 
sequence of  0, 0, 0, 32, 28, 24, 21, 50, 43, 37, 32, 60,... and RTTVAR 
sequence of 0, 0, 0, 64, 48, 36, 27, 84, 63, 47, 35, 90, 67, 50, 37, 91, 
...  Note that the SRTT and the RTTVAR are both significantly less than 
G/2 and would round to zero for conversions.  After the last sample I 
should get a safe RTT of 424 or about 1.65 G, which would round up to 2 
clock ticks.

But if I used the RFC2960 equivalent rule of rounding RTTVAR up to G  
when less than G, I would the same SRTT sequance and an RTTVAR sequence 
of 256, 256, 256, 256, 256, 256, 256, 256, 256, 256, 256, .... leading 
to a safe RTT of 1084 or about 4.23 G, which would round up to 5 clock 
ticks.

In a G = 1 environment I would get SRTT of all zeroes, an RTTVAR of all 
zeroes with RFC2988 and a safe RTT of 1. With RFC2960, I would get 
RTTVARs all one and a safe RTT of 5. 

If one is doing something like not reducing the congestion window based 
on ECN echo information more than once every RTT or window of data (as 
specified by RFC3168 and 2481) you must  use some kind of formula - it 
is not an optimization issue, but necessary behavior - preferably one 
that avoids common double congestion window reductions from a single ECN 
marked packet.   I suppose the best solution is to self clock with data 
from the SACK return path instead of trying to use low precision timers.

 - Mark

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