On 3/7/07, Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote:
Ian McDonald wrote: > On 2/28/07, Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote: > >> 2) Ian - In section 4.3 of RFC3448 we have the equation for X as: >> If (p > 0) >> Calculate X_calc using the TCP throughput equation. >> X = max(min(X_calc, 2*X_recv), s/t_mbi); >> >> I have been doing experiments where I deliberately drop real-time >> packets when I don't believe they will get to the other end before an >> expiry time. What happens though is that I can't then transmit packets >> later on due to the above equation as in practice it becomes >> X=2*X_recv and X_recv quickly goes close to 0 as it is the receive >> rate since last feedback. Feedback gets sent once per RTT I think and >> so if you don't send anything for one RTT you get X=s/t_mbi in effect >> which is 530/64 for my size packets - i.e. a sending rate of 10 bytes >> per second. In practice I don't get quite this bad as I don't drop off >> transmitting that long usually but I still definitely get penalised.
Just to clarify this a bit more as I re-read the relevant RFCs: RFC3448 says if p> 0 then X = max(min(X_calc, 2*X_recv), s/t_mbi); According to RFC3448 feedback rate is at least one per RTT or if interval is slower then one packet per RTT feedback is given for every packet received. So if we don't send anything for 2 RTT and then send one packet then X_recv = s/2 and X becomes s. If you were transmitting at a rate of Mbits/sec previously this becomes quite drastic. I should do some modelling on very low RTT links like LANs because the RTT would be less than the scheduling granularity and it would appear to present a potential problem.... TFRC faster restart will definitely help here but should we think some more about idle periods? Rate based mechanisms such as TFRC are obviously more affected by this than window based mechanisms.
Ian, We have a set of Specs that are current proposed standards. This could therefore be answered this from the existing Standards perspective. However, There are now a growing number of I-Ds that intend to modify (or update) various aspects of the DCCP family. Your email has starting me wanting to see if we can form a common vision for the next generation of DCCP WG Specs. One thing that would be good would be for the implementors to help the the WG see what they have used (CCID-3, plus 3448? 3448.bis?) and what they now need to complete their work - We have allocated some working group time for this at the next IETF meeting and it would be great to see some slides that would contribute to us finding the way forward.
Gerrit has put together some slides for this, with which I have assisted. Basically we are using RFC3448, 4340-2 and bits of proposed 3448 bis along with feedback from the mailing list. As others have discussed in other replies any implementation is going to draw from multiple RFCs and I do agree with this. Nobody uses the original TCP Reno these days for example (think SACK, ECN etc) I do think that the issue of resetting nominal send times should be added to 3448bis though. This was missed in the summary of issues - probably because it was a fairly recent issue. Basically the issues is that t_nom for packet n+1 = t_nom for packet n + t_ipi If idle periods or not sending at rate allowed then t_nom will be way behind current time which allows unlimited sending for a period. There were proposals discussed on the list by Eddie and Gerrit which sound entirely reasonable. I do think this needs to be added to 3448bis Regards, Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
