Re: Fwd: [dccp] CCID2/RFC 2988 RTT computation

[Sally Floyd <floyd at icir.org>]

I will do my best at answering this, but the best reference is
probably Steven's TCP/IP Illustrated for the gory details on TCP's
estimation of the round-trip time.  I don't have it here in Paris, 
however...

>> I'm reading through CCID 2 (TCP-Like), and it defers to RFC 2988  
>> for round-trip time (RTT) computation.  Both mention that the  
>> sender measures RTT once per 'cwnd'.  Can you shed light on  
>> precisely how this happens?  The best I can tell is:
>>
>> The sender maintains some variables like this:
>> - rto        (transmit timeout,             default 1s)
>> - srtt       (smoothed RTT measure,         default 0)
>> - rttvar     (RTT variance measure,         default 0)
>> - rttpending (are we measuring RTT?,        default false)
>> - rttsegnum  (segnum of RTT measure,        default 0)
>> - rttstamp   (start time of RTT measure,    default 0)
>>
>> When sending a packet, it tests 'rttpending'.  If it's cleared, it  
>> knows it's not yet measuring RTT and should do so now.  It does so  
>> by setting:
>>     rttpending = true      (note we're taking an RTT sample)
>>     rttsegnum  = segnum    (note which packet is being sampled)
>>     rttstamp   = CLOCK     (note the start time of the sample)
>>
>> The receiver side doesn't do anything; it just send DCCP-Ack as  
>> normal.
>>
>> When the sender receives the Ack, it compares the Ack's segnum to  
>> 'rttsegnum'.  If they match, the sender sets:
>>     rtt        = CLOCK - rttstamp
>>     rttvar     = (1-beta)*rttvar + beta*abs(srtt-rtt)
>>     srtt       = (1-alpha)*srtt + alpha*rtt
>>     rto        = srtt + max( g, k*rttvar )
>>     rttpending = false
>>         Where:
>>             k = 4
>>             g = clock resolution
>>             alpha = 1/8
>>             beta  = 1/4

All of that sounds reasonable to me.  I would note that TCP does it
somewhat differently when timestamps are used.   CCID2 says that
"The sender estimates round-trip times, either through keeping
track of acknowledgement round-trip times as TCP does or through
explicit Timestamp options."  

>> Now RFC 2988 suggests the use of Karn's algorithm to measure RTT.  
>> However, Karn's algorithm only deals with accounting for  
>> retransmission ambiguity -- which obviously doesn't apply to DCCP  
>> given there is no retransmission.  Should I just ignore Karn and do  
>> a direct RTT measurement as I outline above?  (If so, I'd suggest  
>> mentioning this somewhere in the DCCP CCID2 draft.)

That sounds good to me.  I think it is too late to add this to draft,
however.

>> Furthermore, what's the deal with 'g', the clock resolution?  If  
>> this is referring to the system clock, isn't 'g' so small  
>> (microseconds) in comparision to rttvar (miliseconds) so as to be  
>> negligable?  Is this just a holdover from when system clocks were  
>> quite slow, and thus can be safely ignored now?

The concern in RFC 2988 is not with the system clock, but the clock 
for dealing with TCP interrupts.  My memory is that current
clock granularities for computing TCP RTT measurements are often 
on the order of tens of ms, but I would be wrong.

>> And finally, if the sender determines that 'rttsegnum' was dropped,  
>> it presumably just abandons the RTT computation by setting:
>>     rttpending = false (no longer measuring RTT)

That sounds reasonable to me, but I don't know, without Stevens or the
equivalent at hand.

- Sally