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.
