Re: [dccp] Some comments on the draft of 3448/TFRC.bis (Feb 2007)

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

As per earlier email, I think it does not make RFC 3448 better to mix
implementation and specification issues.

I close this by quoting what you already have said in 
http://www1.ietf.org/mail-archive/web/dccp/current/msg02201.html:

 "This issue is really an implementation issue. RFC3448 4.6 is not exactly 
  normative; it discusses one way to achieve a send rate, not a required 
  implementation. So in some sense the implementer is free to choose anything 
  reasonable."


Quoting Eddie Kohler:
|  Hi Gerrit, all,
|  
|  We agree that max(t_gran, t_ipi) is too much for the "token bucket" size (the 
|  allowed burstiness threshold).  However, some burstiness is useful in 
|  practice, and TCP of course is happy to send up to an RTT's worth of packets 
|  in a single burst.  (One often sees significant clustering in TCP segments.) 
|  TFRC aims to be no worse than TCP.  We now think the correct "credits" are:
|  
|       Thus if the operating system has coarse timer granularity, or
|       otherwise cannot support short t_ipi intervals, and the transmit
|       rate is high, then TFRC may send short bursts of several packets
|       separated by OS-specific intervals.  However, a TFRC implementation
|       MUST prevent bursts of arbitrary size by limiting the accumulation
|       of sending "credits".  This limit MUST be less than or equal to one
|       round-trip time's worth of packets.  (TCP may send up to a round-
|       trip time's worth of packets in a single burst, but never more.)
|       While limits smaller than R, the round-trip time, may be desirable
|       to further constrain bursts, they also constrain TFRC's performance
|       beyond the case for TCP.
|  
|  Eddie & Sally
|  
|  
|  > Thanks for the update. I had actually hoped that the accumulation of send
|  > credits would be taken out of the specification as I don't agree with it. 
|  > 
|  > It may be that this works on a simulation platform, but in the implementation 
|  > there is the following problem: 
|  > 
|  >  As per earlier email, the send mechanism works ideally like a token bucket
|  >  filter with a bucket size of zero. 
|  > 
|  >  Above specification uses a non-zero bucket size floor(t_gran/t_ipi). 
|  > 
|  >  With off-the-shelf commodity hardware it is easy to get into regions of t_ipi 
|  >  of 1..2 microseconds (using standard Gigabit cards; 10-Gigabit cards are  also 
|  >  already available). With above mechanism the sender is allowed to let a flood
|  >  of  up to 10ms/0.001ms = 1E4 packets onto the network when e.g. t_gran = 10ms. 
|  > 
|  > One can of course argue about figures and maybe assume that t_gran is 1 millisecond
|  > and t_ipi is 100 microseconds. But this blurs the issue: since a 10ms schedule interval
|  > ends not precisely after 10ms, over time send credit will accrue with a non-zero token 
|  > bucket size; i.e. it is only safe if the sum of accumulated time (due to inaccuracy, slow
|  > application, or idle time) should be less than t_ipi, but not t_gran.
|  > 
|  
|