[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

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


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?

   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

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

[Kernel List]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]     [Linux Resources]

Powered by Linux