Re: [PATCH 1/1] DCCP: Fix up t_nom - FOLLOW-UP

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

|  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?