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. - Sally http://www.icir.org/floyd/
