Now the problem: when the application rate A is above s * HZ, there is
a range
of speed where the TFRC mechanism is effectively out of control, i.e.
requests
to reduce the sending rate in response to ECN-marked packets or
congestion events
(ECN-marked or lost packets) will not be followed.
This is true if the allowed sending rate X is much more than is
actually being sent. (But, as I explain towards the end, in TFRC
a packet drop is not a "request to reduce the sending rate"; it
is a request for the transport protocol to calculate the TCP-friendly
sending rate, and to stay within that rate.)
One thing that helps is that the TFRC sender can send more than HZ
packets per second, if the sender is allowed to send at most one packet
per discrete timeslice. If the sender can in fact send packets t_delta
seconds before their nominal send time, for t_delta = t_delta =
min(t_ipi, t_gran, rtt)/2, then the sender can send more than one
packet per timeslice.
That was the original reason for this section in RFC 3448:
"As TFRC is rate-based, and as operating systems typically cannot
schedule events precisely, 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."
If rfc3448bis also explicitly allows the sender to "save" up to an
RTT of unused send credits, roughly following the allowed behavior
of TCP, this would allow the sender to send up to RTT*HZ packets per
second. However, if the application rate is greater than RTT*HZ
packets per second, then the application is out-of-luck, unless the
OS allows the TFRC sender to send packets in response to incoming
TFRC feedback packets rather than waiting for its next discrete
timeslice.
In either case, the performance should be similar to that of TCP:
* either the OS allows the TCP sender to send at most cwnd packets
per timeslice, regardless of incoming ACK packets; or
* the OS allows TCP to send data packets in response to incoming
ACK packets, without being limited to discrete timeslices.
At least, that is how it seems to me. Not being an OS person.
If the TFRC sender is sending as much as allowed by the OS, and
loss occurs, and the equation from equation-based congestion
control still allows the sender to send as much as allowed by the OS,
then the TFRC sender doesn't have to reduce its sending rate.
That is how TFRC works. In the optimal case, there is a steady-state
packet drop rate, and TFRC maintains a steady-state sending rate,
never having to change it.
...
II. Accumulation of send credits
--------------------------------
There really are two separate things;
(1) the TFRC sender sending packets before their nominal send time; and
(2) the TFRC sender accumulating "unused" send credits up to a certain
limit.
(1) applies even when the TFRC sender does not have *any* unused send
credits;
it is about sending packets slightly before their allocated time.
(2) only applies when the TFRC sender has been data-limited in the
past, and
has had times when it *could* have sent a packet but didn't.
The new language in rfc3448bis (not yet posted on the web page) talks
about
these as two fairly separate issues, allowing up to an RTT of unused
send credits
to be accumulating. Generally following the allowed behavior of TCP.
- Sally
http://www.icir.org/floyd/
