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.
