Hi all,
Thanks for your very helpful feedback on faster restart. I've submitted a new
version of the draft, it should appear eventually, but is already on the wiki:
http://www.read.cs.ucla.edu/dccp/draft-ietf-dccp-tfrc-faster-restart-01.txt
A section containing a proposed mechanism (VERY PRELIMINARY) to address the
Receive Rate problems recently pointed out by Vlad and Arjuna (at least) is
cut & pasted below.
However, we should continue to discuss alternate ways to fix the Receive Rate
problem; this solution proposal is only to crystallize discussion and may not
even be necessary in the end.
For example, an alternate fix might use zero-length DCCP-Data packets to
implement the mandatory "ping" packets sent during idle periods. Ref:
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.
If the sender used zero-length DCCP-Data packets to "ping", then the Receive
Rate would never include long periods where *NO* packets were sent. It might
drop to 1 packet per 2-4 RTTs (the "ping" frequency), but never to 5 packets
over 100 RTTs.
We should specify what the "ping" packets are anyway.
Eddie
4. Receive Rate Adjustment
DRAFT DRAFT DRAFT
To allow the sender to properly detect and account for Receive Rates
artificially depressed by idle periods, we extend the Receive Rate
option and change the way it is processed. The extended Receive
Rate option appears as follows:
+--------+--------+--------+--------+--------+--------+
|11000010|00001001| Receive Rate |
+--------+--------+--------+--------+--------+--------+
Type=194 Len=9
+--------+--------+--------+
| Receive Rate Length |
+--------+--------+--------+
Receive Rate Length (24 bits)
The Receive Rate Length specifies exactly how many packets were
used to calculate the Receive Rate. It is specified relative to
the feedback packet's Acknowledgement Number. If a feedback
packet's Receive Rate was calculated using data packet sequence
numbers S1...S2, inclusive, where S2 is the feedback packet's
Acknowledgement Number, then Receive Rate Length will be set to
S2 - S1.
In addition to this new form of Receive Rate option, we allow
senders to adjust feedback packets' Receive Rates before using them
in TFRC calculations. The first adjustment applies to any Receive
Rate options, with or without Receive Rate Lengths.
o Assume that the sender receives two feedback packets with
Acknowledgement Numbers A1 and A2, respectively. Further assume
that the sender sent no data packets in between Sequence Numbers
A1+1 and A2. (All those packets must have been pure
acknowledgements, Sync and SyncAck packets, and so forth.) Then
the sender MAY, at its discretion, ignore the second feedback
packet's Receive Rate option. Note that when the sender decides
to ignore such an option, it MUST NOT reset the nofeedback timer
as it normally would; the nofeedback timer will go off as if the
second feedback packet had never been received.
The second adjustment applies only to packets containing a Receive
Rate Length as well as a Receive Rate. If a Receive Rate option
does not contain a Receive Rate Length, the sender MUST use that
Receive Rate as is. We refer to the original Receive Rate, as
encoded in the option, as X_recv_in.
o Assume that the sender receives a feedback packet with
Acknowledgement Number S2 and Receive Rate Length RRL. Let
S1 = S2 - RRL; then the feedback packet's Receive Rate was
calculated using sequence numbers S1...S2, inclusive. Assume
that the sender sent packet S1 at time T1, and packet S2 at time
T2. Further assume that in that interval, the sender was idle
for a total of I seconds. Here, "idle" means that the sender had
nothing to send for a contiguous period of at least one-half
round trip time. (Note that this definition of idleness is less
conservative than that applied to the Faster Restart algorithm.
[XXX?]) Then the sender MAY act as if the feedback packet
specified a Receive Rate of
X_recv_in*(T2 - T1 + I)/(T2 - T1),
rather than the nominal Receive Rate of X_recv_in. The inflation
factor, (T2 - T1 + I)/(T2 - T1), compensates for the idle periods
by removing their effect.
