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