Re: revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt

Eddie Kohler <kohler@xxxxxxxxxxx> · Mon, 18 Oct 2010 17:38:40 -0700

Hi,

Will look over the new draft, but I have a response to your comments.  It 

would be good to hash it out.

On 10/18/2010 04:19 AM, Gerrit Renker wrote:

* S3.3 "When the Send RTT Estimate FEATURE [sic, note added word] is disabled,
   the sender MUST NOT send RTT Estimate options...."  Why not?  DCCP receivers will
   correctly ignore RTT Estimate options they do not understand.  And it would seem
   useful to take advantage of RTT Estimates whether or not they were required.

The document follows RFC 4340, 15. We much prefer to give one unambiguous
specification that agrees with the existing standards.

This choice isn't justified by RFC4340's "Forward Compatibility", and seems a 

mistake.

Extensions SHOULD default to off, and Send RTT Estimate does default to off. 

But the Send RTT Estimate feature controls the MANDATORY inclusion of RTT 

Estimates.  This is important to control via a feature since mandatory RTT 

Estimates change behavior -- as we discussed, the receiver may penalize 

senders that neglect to include mandatory RTT Estimates.

The "0" state for Send RTT Estimate thus means "Mandatory RTT Estimates not 

available".

As for non-mandatory RTT Estimates:  A nice quality of the RTT Estimate option 

is that the endpoint sending the option *has the same behavior as a "legacy" 

sender* (one that doesn't understand explicit RTT Estimates), except for the 

option itself.  If a middlebox stripped out every RTT Estimate option, leaving 

the packets otherwise valid, the result should be identical to what a legacy 

receiver would expect.

But already legacy receivers MUST ignore the option, per RFC4340 Forward 

Compatibility!

In summary, MUST NOT is not justified here.  I could see reasons to include an 

RTT Estimate on an initial packet, before feature negotiation can complete, if 

a relatively up-to-date RTT estimate was available.  Such uses shouldn't be 

specified now.  They also needn't be ruled out.  Since MUST NOT doesn't 

simplify implementation, I don't see any reason for the strict language.

Any comments?
Eddie

   The document should also perhaps define what happens if a sender agrees to Send
   RTT Estimate and then doesn't actually do so (or sends 0 for too long).

That is a good point, section 3.3 has been revised with regard to that (please see
changelog).

A first thought:
   - If Send RTT Estimate is 1, the sender MUST provide RTT Estimate options
     on the described packets.
   - If Send RTT Estimate is 1, the receiver MUST use the provided RTT
     Estimates in place of the CCVal window counter values.  (Note: The current doc
     says MUST NOT estimate the RTT using CCVal.  Of course, an implementation
     MIGHT estimate the RTT that way; it's just not supposed to USE that estimate.)

Revised that section: the CCVal value now serves as a fallback mechanism.

   - If Send RTT Estimate is 0, the sender MAY provide RTT Estimate options.
   - If Send RTT Estimate is 0, the receiver MAY use provided RTT Estimate
     options to augment RTTs estimated another way, but MUST use CCVal window
     counter values or other RTT estimation techniques when valid RTT Estimates are
     not available.

Not done due to decision above.

   - Invalid RTT Estimates: A packet without an RTT Estimate option is
     considered to have an RTT Estimate of 0.
   - Invalid RTT Estimates: [TOTAL GUESSWORK -- DO WE ACTUALLY NEED TO
     SPECIFY?]  If at least 64 consecutive packets are received with zero RTT
     Estimates, the receiver MUST treat the RTT Estimate as 64000000. ????????????????

The general idea is very good and as a consequence section 3.3 has been reworked in order
to specify what happens in this case.

Tracking 64 consecutive packets is a lot of state. Decided to use a maximum of 2 successive
0-valued RTT Estimate options since this allows to track the state e.g. in a single-bit
boolean flag.