Any idea on how comfort noise packets could be used instead of ping packets to solve this problem? -Arjuna On 6/26/06, Eddie Kohler <kohler@xxxxxxxxxxx> wrote:
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.
-- Regards, Arjuna Postdoctoral Researcher Engineering Research Lab, Department of Engineering, University of Aberdeen
