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

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

Quoting Sally Floyd:
|  Gerrit -
|  
|  > If this is the perspective then it may be better to take the section
|  > regarding accumulation of send credits out of the specification, and
|  > concentrate on the purposes of congestion control instead.
|  > Otherwise it mixes specification with implementation issues, which
|  > will only confuse people.
|  
|  I will try to add some text to Section 4.7 on "Scheduling of Packet
|  Transmissions" making it clear what is a specification (whether
|  MUST, SHOULD, MAY, or no capital letters at all) with pseudocode,
|  and what parts are more implementation-specific.
|  
|  
|  This I would consider specification:
|  
|   From RFC 3448:
|  "It is necessary to be opportunistic about
|  sending data packets so that the correct average rate is maintained
|  despite the course-grain or irregular scheduling of the operating
|  system."
|  
|  This I would consider specification also, with some modification
|  of the language to take out the variables:
|  
|  Additional clarifying text in RFC3448bis:
|  "If the operating system has coarse timer granularity and the
|  transmit rate is high, then TFRC may send short bursts of several
|  packets separated by intervals of the OS timer granularity of t_gran
|  seconds.  However, the TFRC sender is not allowed to accumulate
|  `credits' of more than max(t_ipi, t_gran) time units in packet
|  scheduling, so the sender is not allowed to send arbitrary bursts of
|  packets after idle periods.
|  
|  Most of the rest of that section I will try to clearly label as
|  an implementation-specific discussion.
|  
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.