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

["Andrei Gurtov" <[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?

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

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