Subject: [Tsvwg] Is a TFRC sender allowed to increase the send rate more than twice?

From: "Andrei Gurtov" <[email-masked]>
Date: Fri, 10 Jan 2003 11:47:46 +0200

Hi,

In draft-ietf-tsvwg-tfrc-05.txt on p. 11 a TFRC sender computes its send
rate as

If (p > 0)
                   Calculate X_calc using the TCP throughput equation.
                   X = max(min(X_calc, 2*X_recv), s/t_mbi);

when there are some losses detected. A question is, when X_recv and X_calc
suddenly increase, is the sender allowed to increase its transmission rate X
more than twice? Such situation could appear when a number of delayed or
reordered packets show up at the receiver causing the loss rate become low
and the receive rate higher than the current transmit rate. Alternatively,
the receiver or PEP having good knowledge of the bottleneck link could
adjust the loss rate and X_recv in feedback packets to make the sender adapt
faster to significant changes in available bandwidth. Yet another
possibility is a spoofing attack doing the same.

According to the equation above more than twofold increase of the send rate
is ok, but the NS implementation clamps the send rate increase at twice the
current in all cases.

Off topic:

Given the recent discussion on TFRC response to application-limited
connections, I would be cautious to say that TFRC is suitable for telephony
applications.

A typo in p. 21 pervious -> previous?

Andrei

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Mark Handley <[email-masked]>
Date: Sat, 11 Jan 2003 12:47:52 -0800

>is ok, but the NS implementation clamps the send rate increase at twice the

In practice, I believe the difference has no effect on behaviour.

 - During slowstart, the send rate increase is capped to twice the
   send rate explicitly.

 - During normal operation, the normal increase rate due to the expiry
   of old higher-loss history is (from memory) about 0.12 packets per
   RTT.  Thus to double the sending rate would take about 6 RTTs.  It
   seems rate unlikely that any bunching would cause more than 6
   RTTs of packets to arrive at once without having previously causing
   the receiver to signal the sender to reduce rate because the
   receive rate was so low while the packets were being delayed.  

 - If history discounting has cut in, the 6 RTTs above would be 3
   RTTs, but delaying of 3 RTTs of traffic would still likely trigger
   the receiver to clamp the senders rate to twice the (very low) receive
   rate before the delayed traffic arrives.  

Limiting the send rate to twice the receive rate is a safety measure
that prevents serious overshoot on links with low levels of
statistical multiplexing.  In the case where you can delay several
RTTs worth of packets without losing any, and then deliver them all in
a high-rate burst, it seems rather likely that the level of
statistical multiplexing isn't all that low, so this additional safety
mechanism isn't required.  In the worst and very unlikely case, you
take some losses in the next RTT and slow down again pretty quickly.

So, to summarise, restricting the increase to twice the send rate (as
ns does) is a reasonable thing to do, but not doing it is very
unlikely to have any significant effect, and even less likely to have
any significant adverse effect.

Does this answer your question?

Cheers,
	Mark

---

From: "Andrei Gurtov" <[email-masked]>
Date: Mon, 13 Jan 2003 10:54:42 +0200

> Does this answer your question?

Thank you, this answers the first part of the question.

I do think that links with delays and with low level of statistical
multiplexing exist. For example GPRS has a dedicated buffer per user and has
delay spikes of x10 RTT due to handovers.

My own interest in asking this question is a possibility to explicitly
control the rate of the TFRC sender from the receiver or from the network.
Currently it takes more than 1 min for TFRC to reach the full rate after a
handover from GPRS to UMTS. It seems that some push to the TFRC sender is
needed to make it transmit at the full rate faster. My guess is that one
leap change in transmission rate is preferrable by applications than many
small incremental changes.

After a handover the receiver can set X_rcv to the new link's rate and p to
some small none-zero value which will cause the TFRC sender to send at the
higher rate immediately.
Of couse this shouldn't be used to the sender over the shared Internet, but
for servers connected by LAN it seems quite appropriate.

Now that I'm certain that this is supported by specs, I can go on with
experiments.

Andrei