[dccp] CCID2/RFC 2988 RTT computation

[David Barrett <dbarrett at quinthar.com>]

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

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.)

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?

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)

Is any or all of this about on the right track?  Thanks!

-david