[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dccp] Questions regarding faster restart
Hi Sara,
Some belated responses:
Sara Landström wrote:
Hi,
I have been reading draft-ietf-dccp-tfrc-voip-01.txt and had problems
understanding the "Faster restart" mechanism and I also have some minor
details that I think should be added for clarity.
In section 6.1:
T_idle is set to the current time whenever the application enters an
idle period. When the application has something to send if makes the
following comparison:
if ((now-T_idle)>max(R, 1/max(X_calc, s/t_mbi)))
I think there has to be a check to see whether t_idle contains a valid
value and that is it should be set to for instance zero each time it is
leaving an application limited period to allow this check.
A fair point.
Why do we compare R (rtt in seconds) to 1/max(X_calc, s/t_mbi) which is
in seconds/byte?
I could have understod if the rtt was compared against the current
length of the interval between packets but not really seconds per byte.
Maybe I am missing something here?
TFRC reduces its send rate approximately once every 4*rtt when idle
(RFC3448). Hence, why are we interested in knowing if the application
has been idle shorter than that?
I know that TCP reduces its send rate on an rtt basis if congestion
window validation is applied, but the current TFRC version doesn't. Are
there plans to change this?
If no changes are made to the nofeedback timer interval, I don't quite
see the connection between the condition to enter faster restart and
reductions in the send rate due to idleness which I thought it was meant
to help with.
Initially I thought that checking whether the nofeedback timer had
expired while being idle would be the condition to enter faster restart.
There is definitely some confusion here in the draft! Here's what I believe we
were aiming for.
(1) Start the faster restart period after 1 RTT of idleness. This is in line
with RFC2861 on congestion window validation. But it also needs to be this
short. TFRC send rates are limited to 2*X_recv. Imagine an idle period of 2
RTT. The last feedback packet generated by the receiver will report a small
X_recv, since the sender didn't send for most of the feedback period!
(2) HOWEVER, it might be possible that the sender is not ALLOWED to send packets
as frequently as once per RTT. This is what "1/max(X_calc, s/t_mbi)" is
attempting to capture. The "1" has units of bytes, so the whole term actually
has units of seconds, not seconds/byte. The "max(X_calc, s/t_mbi)" term is
TFRC's calculation for the current allowed sending rate, absent any X_recv
considerations. Thus, "1 byte/max(X_calc, s/t_mbi)" is the minimum time TFRC
enforces in between bytes. This might be greater than the RTT; we should not
count a period as "idle" if it lasted less than this time.
But I actually think we can implement far something more sensible. See below.
What is meant by T_active_recv? It is stated in the draft that this is
the most recent time in an active sending period. I am assuming that it
is the last time I sent a packet in an active sending period, but it
could also be the last time I got feedback from the receiver connected
to an active sending period for instance.
See below.
How am I supposed to compute X_active_recv? TFRC sends feedback
approximately once per RTT. If I simply take the last recvrate after a
sending period it may be too low since the sender may only have sent a
few packets during the last RTT, thus the time interval may have been
large.
The intent is that the feedback covers an entirely-active period.
I guess it may be hard to notify the receiver that a packet is
the last one in a talkspurt though and get it to send feedback at the
right moment. Since data is being produced on the fly an empty
sendqueue may not be a reliable indication.
I thought that maybe the receiver can monitor the send stream and if the
normal interval is exceeded, send feedback. If the interval changes the
sender may keep the same interval for one packet and notify the receiver
of the new interval. Of course, the problem of packets being lost
remains but I don't think there is any way around that.
Again in section 6.1, last row:
"Alter the cached X_recv so we start out between 4 and 8 packets/RTT"
X_recv=max(2*s/rtt, X_recv).
2*s/rtt yields two packets per rtt and x_recv may have been modified so
that it is 2 packets per rtt,
(RFC3448 section 4.4 last paragraph:" If X_recv is less than 4 pkts per
rtt then x_recv should not be halved in response to the timer expiration.")
Hence, X_recv may be as low as 2 pkts per rtt after this statement so
how does that give us 4 to 8 pkts per RTT?
The only other modification to TFRC is the one suggested in section
6.2, but this update is not performed until feedback is received. I
think that you have to recompute the send rate when starting up again
prior to getting the first feedback packet to get an effect from the
changes during the first rtt.
I don't think so; see below.
Another issue I have is when to send feedback after being idle, which is
similar to the problem of how to get the receiver send feedback when the
last packet in a sending period arrives. According to RFC3448 (I know
DCCP has a slightly different implementation) section 6.1 feedback is to
be sent if the new loss rate is higher than it was when we last sent
feedback or if the feedback timer expires. The feedback timer expires
approximately once per rtt and feedback is sent only if data has been
received since the previous feedback was sent. This means that feedback
can be sent directly after the first packet has arrived and the recvrate
is then packetsize/rtt which may be low and may in fact give a rate
reduction when reported to the sender.
Shall we then wait until we have got data during an rtt to compute the
recvrate?
This may give a better estimate of both the loss event rate and the
receive rate, but we will have to wait longer to make a fresh rtt estimate.
The behavior may be even worse with the DCCP-TFRC behavior where we
compute the recvrate since the last time feedback was sent, which can
give a very large time interval and thus a very low receive rate. I used
the "Quiescence" definition to decide whether the sender was idle and
computed the recvrate over the last rtt in that case.
This is TFRC-general, so I'll leave it to the TFRC-heads.
Furthermore, in section 6.2:
"if (2*x_recv < x_fast_max) and the feedback packet indicates a loss or
mark" - Do you mean if p_new > p_old? (p=loss event rate)
...
"x_recv=x_recv/2"
Why divide by two? Before when exiting the ordinary slow start, no such
thing was done.
Because we were in faster restart when we encountered congestion, we may be up
to 4x higher than our "fair rate", rather than 2x.
In slow start (last else paragraph) we do not seem to be allowed to
quadraple our send rate? There is no modification here to the RFC3448
algorithm. Shouldn't we be allowed to do faster restart also in "slow
start", which means a similar modification as to the if p>0 step of the
algorithm?
No, because there is no information about the state of the network. Faster
restart is explicitly intended for those times where you know you achieved a
good transmit rate before.
I realize that it is only a draft and that some things remain to be
worked out, but I would appreciate some feedback on my thoughts.
Best regards,
Sara Landström
Thanks so much for your comments!! I'd love your comments on the following
revised Section of the draft.
Eddie
3. Faster Restart Congestion Control
DRAFT DRAFT DRAFT
A connection goes "idle" when the application has nothing to send
for at least a nofeedback interval (as least four round-trip times).
However, when Faster Restart is used, the transport layer MUST send
a "ping" packet every several round trip times, to continue getting
RTT samples and some idea of the loss event rate.
The Faster Restart mechanism refers to several existing TFRC state
variables, including:
R The RTT estimate; kept current during any idle periods as
described above.
X The current allowed sending rate in bytes per second.
p The recent loss event rate.
X_recv
The rate at which the receiver estimates that data was received
since the last feedback report was sent. Note that this
includes "ping" packets sent during idle periods (above) as well
as application packets.
Faster Restart also introduces two new state variables to TFRC, as
follows.
X_active_recv
The receiver's estimated receive reported during a recent active
sending period. An active sending period is a period in which
the sender was neither idle nor in faster restart. It is
initialized to 0 until there has been an active sending period.
T_active_recv
The time at which X_active_recv was measured. It is initialized
to the connection's start time.
Other variables have values as described in [RFC 3448].
Floyd/Kohler Section 3. [Page 5]
INTERNET-DRAFT Expires: January 2006 July 2005
3.1. Feedback Packets
The Faster Restart algorithm replaces for the 4th step of Section
4.3, "Sender behavior when a feedback packet is received", of [RFC
3448]. The replacement code has two goals:
1. It keeps track of the active receive rate, X_active_recv. This
parameter models the connection's most relevant loss- and mark-
free transmit rate, and represents an upper bound on the rate
achievable through faster restart. Thus, X_active_recv is
increased as the connection achieves higher congestion-free
transmit rates, and reduced on congestion feedback, to prevent
inappropriate faster restart until a new stable active rate is
achieved. Specifically, on congestion feedback at low rates,
the sender sets X_active_recv to X_recv/2; this allows limited
faster restart up to a likely-safe rate, and lowers the
likelihood that badly-timed transient congestion will wholly
cripple the faster restart mechanism.
2. It adjusts the receive rate, X_recv, more aggressively during
faster restart periods, up to the limit of X_active_recv.
The code works in three phases. The first phase determines
X_fast_max, the adjusted rate at which faster restart should stop.
Full faster restart up to X_active_recv should be allowed for short
idle periods, but more conservative behavior should prevail after
longer idle periods. Thus, if 10 minutes or less have elapsed since
the last active-period measurement (T_active_recv), the code sets
X_fast_max to the full value of X_active_recv. If 30 minutes or
more have elapsed, X_fast_max is set to 0. Linear interpolation is
used between these extremes.
The second phase adjusts X_active_recv based on the feedback
packet's contents and the value of X_fast_max.
Finally, the third phase sets X based on X_fast_max, X_recv, and
X_calc, the calculated send rate. Several temporary variables are
used, namely X_fast_max, delta_T, F, and X_recv_limit.
Floyd/Kohler Section 3.1. [Page 6]
INTERNET-DRAFT Expires: January 2006 July 2005
To update X when you receive a feedback packet
----------------------------------------------
/* First phase. Calculate X_fast_max */
/* If idle for <= 10 minutes, end faster restart at the
full last fair rate; if idle for >= 30 minutes,
don't do faster restart; in between, interpolate. */
delta_T := now - T_active_recv,
F := (30 min - min(max(delta_T, 10 min), 30 min)) / 20 min,
X_fast_max := F*X_active_recv.
/* Second phase. Update X_active_recv */
If the feedback packet corresponds to an active period
and does not indicate a loss or mark, then
If X_recv >= X_fast_max, then
X_active_recv := X_fast_max := X_recv,
T_active_recv := current time.
Else if X_recv < X_fast_max and the feedback packet
DOES indicate a loss or mark,
X_active_recv := X_fast_max := X_recv/2,
T_active_recv := current time.
/* Third phase. Calculate X */
If p > 0,
Calculate X_calc using the TCP throughput equation.
X_recv_limit := 2*X_recv.
If X_recv_limit < X_fast_max,
X_recv_limit := min(4*X_recv, X_fast_max).
X := max(min(X_calc, X_recv_limit), s/t_mbi).
Else
If (t_now - tld >= R)
X := max(min(2*X, 2*X_recv), s/R);
tld := now.