>Reading the draft and the simulation results I had one question which >the draft wasn't answering at all. What happens when TCP starts using >packet size larger than 1460 bytes in an environment where the packet >loss rate is independent of packet size. It seems that it will result in >similar unfairness as normal TFRC with small packets has with TCP for >1460 bytes. Is this correct and could it be stated in the document?
Yep, that is correct, and I will add that to the document. (This would be similar to the current unfairness between TCP connections with 500-byte packets, and TCP connections with 1500-byte packets, in an environment where the drop rate is independent of packet size.) ... >I was also somewhat concerned with the table 14 behavior of TFRC-SP. I >think this is one of the few really problematic cases I have seen. In >all other graphs the TFRC-SP loss rates continue to raise and the >unfairness seems to stay within non-critical (less than factor of 10) >for packet loss rates that are usable for a VoIP client (less than >5-10%). But the fact that the packet loss rates drops to lower results >than the least congested case in that graph makes me worried for the >stability. Yep. I believe that the answer is that this drop rate (55% for the TCP traffic) has exceeded the adaptive range of Adaptive RED. In NS, Adaptive RED is configured not to "adapt" to packet drop rates over 50%. When the packet drop rate is at most 50%, Adaptive RED is moderately successful in keeping the packet drop rate proportional to the packet size - TCP packets are six times larger than the TFRC-SP packets (including headers), so the TCP packets should see a packet drop rate roughly six times larger. But for packet drop rates over 50%, Adaptive RED is no longer in this regime, so it is no longer successful in keeping the drop rate for TCP packets at most six times the drop rate of the TFRC-SP packets. So this behavior is about the details of the Adaptive RED implementation in NS, and not about TFRC-SP. I will add a note about this to the draft. >Also my believe is that the behavior beyond 25% packet loss >is of less importance as long as it doesn't lead to congestion collapse. >TCP may still get some data through in that range, but most real-time >DCCP applications would stop being useful in that regime. > >The possibility to run VoIP when having packet loss is much dependent on >the codec and used robustness methods. However most encoded content >without any redundancy will start to provide significantly reduced >quality at 1-5% frame loss rate. Redundancy methods are effective but >also increases bit-rate significantly. The delay will also increase with >at least one packetization interval, thus more than 10ms for TFRC-SP. >Also codecs are vulnerable to burst losses and would still have issues >with significantly elevated packet loss rates. Yep. Though I don't trust all small-packet TFRC applications to have is a user who hangs up when the packet drop rate gets to be too high... >What is the plans for defining a DCCP CCID for TFRC-SP? It would seem >that only defining the algorithm does allow only for where limited >tests. Assigning a experimental CCID for TFRC-SP would allow more wide >scale experiments. Yep, that comes next. Hopefully it will be a one-page document. In terms of implementation, the small-packet variant of TFRC would be implemented as a small modification to CCID3, with the modifications as described in Section 3 of the draft. This involves: (1) using 1460 bytes at the nominal packet size; (2) reducing the allowed transmit rate by X := X * s_true / (s_true + H), for s_true the true packet size and H the estimated header size; (3) maintaining a minimum interval of 10 ms between packets; and (4) using a modified method for measuring the loss event rate for loss intervals at most two RTTs long. So this could be either a new CCID, or a negotiated variant of CCID3. In terms of implementation, I think it makes more sense to think of it as a negotiated variant of CCID3, but in terms of API interfaces, it is probably more straightforward to present it as a new CCID. Yes? No? >Nits: > >1. In the changes section there is a claim that the abstract maximum >length is 25 lines. According to RFC 2223bis the abstract is not >acceptable if beyond 20 lines, with a recommend length of 5-10 lines. That was from January 2006 email from "[EMAIL PROTECTED]": "The abstract should not be more than 25 lines. Please correct and resubmit." >2. Section 2, fourth paragraph. In the first sentence RFC 3714 is >references. Please insert title for easier understanding on what is >referenced. Thanks, will do. Many thanks for the feedback. - Sally http://www.icir.org/floyd/
