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

From: Mark Butler <[email-masked]>
Date: Thu, 22 Dec 2005 07:08:11 -0700

There is a subtle difference between the way RFC2988 and RFC2960 
handle RTO and RTTVAR calculations. RFC2988 does not adjust RTTVAR 
upward to the clock granularity, but instead adjusts the "variance term" 
upward to the clock granularity:

    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

This can make a difference in some situations.  With RFC2988, the 
minimum possible RTO is G.  With RFC2960 the minimum possible RTO is 
4*G.  If you have a coarse grained clock, or low latency requirements it 
would be helpful to be able to specify an RTO.Min lower than that. 

It is also helpful to preserve RTTVAR == 0 information for use in other 
places, such as determining the proper round trip time for ECNE window 
reduction.  Adding RTTVAR to RTT in the once per RTT ECNE window 
reduction test reduces the risk of an improper double congestion window 
reduction.  If RTTVAR is raised upward to G, information is lost and 
ECNE congestion window reduction may occur twice as slowly as it would 
otherwise. 

Perhaps this is a candidate for an sctpimpguide erratum.

- Mark

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

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Dec 2005 10:30:45 -0500

Mark:

I only have few comments on this..

First and formost... this section's was Vern's to
write.. and so to me he needs to respond to this.. Vern?
----------------------------------------------------------
Second, I would think this only effects the initial RTT
setting.. since the fact that you are doing:

       RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
       SRTT <- (1 - alpha) * SRTT + alpha * R'

over time could possibly adjust RTTVAR towards zero.. assuming
a steady state RTT.

I know on my FreeBSD boxes I have seen the RTT calculated
drop below 10ms.. which is the clock granularity (have not
looked at the RTTVAR though).. Not that
the overpowering RTO.min does not override that :-D
----------------------------------------------------------
Third, I would think that most implementations use VJ's
interger algorithm (for both TCP and SCTP).. I know we
did this when we built the BSD implementation.. I am sure
others did as well.. since otherwise you end up doing
float in the kernel.. a real no-no :-0
-----------------------------------------------------------
Finally, the sctp implementors guide is now closed. Its
in the RFC editors queue.. or will be shortly.. thus it will
not be updated again. Shortly after the 1st of the year
I will start the 2960bis.. but the changes will be restricted
to the I-G....

R

Mark Butler wrote:
> 
>  There is a subtle difference between the way RFC2988 and RFC2960 handle 
> RTO and RTTVAR calculations. RFC2988 does not adjust RTTVAR upward to 
> the clock granularity, but instead adjusts the "variance term" upward to 
> the clock granularity:
> 

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)