| 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.
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
