Re: Some comments on the draft of 3448/TFRC.bis (Feb 2007)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--------------------------------------------------


After reading the draft 0.2 of TFRC faster restart I think that will
solve many of my issues and issues other people will face.

The question is whether the existing TFRC should be amended or whether
people should just go ahead and implement TFRC faster restart. Either
way I suspect TFRC faster restart would end up being the default.

Ian

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.

Gorry


[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux