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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Gerrit...

On 10/19/2010 10:42 PM, Gerrit Renker wrote:
It is justified by applying the suggestions made in that section. If you can
officially add what you have written in the preceding email as an erratum to
RFC 4340 we would be happy to use it. Otherwise we will not change it.

You and Gorry disagree. My previous email, being RTT Estimate specific, is not appropriate for an erratum. But see below.

RFC4340 compliant DCCP endpoints may send new options before negotiating a corresponding feature. Gorry and Arjuna's RFC 5634 does this already.

RFC4340 S15 uses the undefined term "extension":

   o  Each DCCP extension SHOULD be controlled by some feature.  The
      default value of this feature SHOULD correspond to "extension not
      available".  If an extended DCCP wants to use the extension, it
      SHOULD attempt to change the feature's value using a Change L or
      Change R option.  Any non-extended DCCP will ignore the option,
      thus leaving the feature value at its default, "extension not
      available".

An endpoint-shared behavior change is usually an extension; an option alone may not be. The 'Send RTT Estimate' feature controls the "extension" part of this proposal, namely the shared behavior change where the sender promises to send RTT Estimates, and the receiver prefers RTT Estimates to CCval (and radically slows down in the absence of RTT Estimates).

The analogy with RFC4340's Send NDP Count and Send Ack Vector features and RFC4342's Send Loss Event Rate feature is exact. These features all are defined as "MUST send if on, MAY send if off," AND ARE EXPLICITLY DESCRIBED AS EXTENSIONS.

RFC4340.

   Req'd          This column is "Y" if and only if every DCCP
                  implementation MUST understand the feature.  If it is
                  "N", then the feature behaves like an extension (see
                  Section 15), and it is safe to respond to Change
                  options for the feature with empty Confirm options.

   (Send NDP Count and Send Ack Vector are not Req'd.)

RFC4342.

   Send Loss Event Rate is
   optional, in that it behaves like an extension ([RFC4340], Section
   15).

-*-

Here's an attempt at clarifying RFC4340.

  o  Each DCCP extension SHOULD be controlled by some feature.
     ("Extension" refers to a behavior change on which both endpoints
     must agree.)

Does this help? It was and is difficult to completely define this concept, since it must cover future compatibility. I've tried, again, for some time now and not found a satisfactory way. Input solicited. But given the above I don't consider an erratum required.

Eddie


[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux