| Summary: I agree with Ian that hrtimer support is not required, and that | bursts are OK. They are explicitly allowed by the RFC. I don't have much disagreement with your points. However, the `bursts' issue can really not be dismissed as unproblematic. Please see other reply. | | > When a sender first starts sending at time t_0, it calculates t_ipi, | > and calculates a nominal send time t_1 = t_0 + t_ipi for packet 1. | > When the application becomes idle, it checks the current time, t_now, | > and then requests re-scheduling after (t_ipi - (t_now - t_0)) | > seconds. When the application is re-scheduled, it checks the current | > time, t_now, again. If (t_now > t_1 - delta) then packet 1 is sent. | > | > Note that initially we set t_ipi to 1 second. This could be set to a | > better value based on connection setup as per Eddie and your | > discussion earlier but I haven't implemented this yet. In this way my | > code is a hack that I remove the 1 second and add the initial RTT once | > we obtain it. I see this ugliness can be removed when we make the code | > base conform to the RFC intent (it is not in RFC yet but Eddie said he | > would propose for revision) | | For what it's worth, it's as close to in the RFC as it can get without a | revision. The authors of the RFC agree that we meant the initial | Request-Response RTT to be usable as an initial RTT estimate; the | working group agreed; errata has been sent. So we are RFC-compliant for the moment. One point which remains unresolved is, the above is about RTTs, but what about the initial sending rate of 1 packet per second, which implies an initial t_ipi of 1 second? - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
