initial thoughts on draft-ietf-dccp-tfrc-rtt-option-00.txt

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

 



S3.2.1 says:

   A value of 0 indicates the absence of a valid RTT sample.  The sender
   MUST set the value to 0 if it does not yet have an RTT estimate.

I would also say "A packet without an RTT Estimate option is considered to carry an RTT Estimate value of zero."

S3.3 says:

   When the Send RTT Estimate Feature is enabled, the sender MUST
   provide an RTT Estimate Option on all of its Data, DataAck, Sync, and
   SyncAck packets.  It MAY in addition provide the RTT Estimate Option
   on other packet types, such as DCCP-Ack.

I am concerned about interaction of this with:

   The sender is permitted to send up to MAX_INVALID_RTT=2 successive
   0-valued RTT estimate options.  If the receiver encounters more than
   MAX_INVALID_RTT RTT Estimate options in succession, it MUST behave as
   if the Send RTT Estimate Feature were off, and disregard all
   subsequent RTT Estimate options.

* You meant "more than MAX_INVALID_RTT ***zero-valued*** RTT Estimate options in succession".

* The interaction with e.g. streams of DCCP-Acks, which only MAY include RTT Estimate options, worries me. Perhaps you want to specify "data-carrying packets" or something similar.

* "it MUST behave as if the Send RTT Estimate Feature were off": This is problematic, since it could be interpreted as changing the Send RTT Estimate feature one-sidedly. Can you define this differently/more explicitly? The MUST/SHOULD balance is also iffy, since above tracking CCval is a "SHOULD" not a "MUST". Suggestion:

   If the receiver encounters more than MAX_INVALID_RTT successive
   data-carrying packets with RTT Estimate value zero, the receiver
   SHOULD fall back on CCval-based RTT estimation for future packets in
   the half-connection.

I think this points out the problem, is sufficient, and avoids unnecessary constraints.

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