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

[Mark Handley <[e-mail]>]

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

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
_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg