Re: [PATCH 28/43]: Make computation of X_recv conform to TFRC

[Gerrit Renker <gerrit@erg.abdn.ac.uk>]

|  I think this is one of those (rare) instances where RFC4342 overrides
|  RFC3448. Have a look in particular at section 10.3 of 4342 and 8.1/8.3
|  
|  As such this patch is not correct I think.
|  
|  Thoughts?
There are two points here: 

(1) The title is a bit unfortunate, as 90% of the patch are concerned with
    improving the interface from rx_packet_recv() to send_feedback().

(2) With regards to the 3448/4342 relationship, you are correct. 
    I had overlooked the following passage in section 8.3 of RFC 4342:

     "To calculate this receive rate, the receiver sets t to the larger of 
      the estimated round-trip time and the time since the last Receive Rate
      option was sent."

    However, though I wish I had read that earlier, this additional rule causes
    no contradiction - in fact, it simplifies the issue.


What follows shows that the patch conforms to above rule from [RFC 4342, 8.3]. The 
documentation of how the patch works is on 
  http://www.erg.abdn.ac.uk/users/gerrit/dccp/docs/ccid3_packet_reception/#8._Computing_X_recv_
The time `t' here corresponds to delta = t_now - ccid3hcrx_last_feedback


 1. Periodic feedback (FBACK_PERIODIC) triggered by the window counter.

    This is using the rule specified by [RFC 4340,  10.3]. 

      (a) Time between window counter changes larger than or equal to RTT
          This corresponds to a window counter difference of 4 or larger 
          and is in agreement with above rule from 8.3 with regard to "the
          larger of the estimated round-trip time".

      (b) Time between window counter changes less than RTT.
          No periodic feedback  is sent due to 10.3.


 2. Feedback due to parameter change (FBACK_PARAM_CHANGE).

    There are thw possible cases, both need to be handled correctly.

      (i) Parameter change directly after sending periodic feedback.
          In this case few (worst case: none) packets have been received since the last
          feedback was sent. The code does not (as was done previously) use the number
          of bytes received since the last feedback was received: the time interval 
          since sending the last feedback is less than the estimated RTT used in sending
          periodic feedback. 
          RFC 4342, 8.3 requires to compute X_recv over an interval larger than the 
          estimated RTT and this time interval. The code therefore uses the longer interval 
          of the RTT estimate, by reusing X_recv computed previously. Note that both feedback
          packets are sent within the same RTT. In addition, last_counter is reset to correctly
          trigger the next periodic feedback.

     (ii) Parameter change when no periodic feedback has been sent yet.
 
          Here X_recv is 0. This case can happen due to early loss. We have no reasonable RTT 
          estimate, the only feedback that has been sent is the initial feedback from [RFC 3448, 6.3].
          Here X_recv is computed over the interval since last_counter was last set (at the same time
          when the initial feedback packet was sent). This again does not contradict the rule from
          RFC 4342, 8.3; rather it is a special case with the premise that there is no reliable RTT
          estimate yet. Furthermore, this case is an exception - it occurs only when there is loss
          immediately after the first data packet and before the first periodic feedback is due.