Hi Ian, Lars replied so fast that I did not have time to send him also my answers. Here they are inline: > On 8/2/06, Lars Eggert <lars.eggert@xxxxxxxxxxxxx> wrote: >> Hi, >> >> we finally have the results of our voice quality experiments over >> DCCP written up: http://larseggert.de/tmp/2006-dccp-voip-quality.pdf >> >> We'd appreciate any feedback you may have on this! >> >> Thanks, >> Lars >> -- >> Lars Eggert NEC Network Laboratories >> > Lars, > > Finally read through this in detail and have some feedback. > > In the first paragraph of the introduction you use "looses" where it > should be "loses". > > I noticed in section IV.A you say no experimental results are > available where 0ms delay. I have had problems on Linux also with no > delay (well it was 0.26 ms) in that throughput fluctuates > significantly. Is this also what you were experiencing? I am wondering > whether CCID3 has real problems when delay is very low. In other tests > when I have 1.2 msec delay due to added hop the problem goes away. > We experienced that with very small delays the behavior of the connection became unpredictable in the way you mentioned, especially when using the small packets variant and allowing a higher send rate. We were not sure if this was a design problem or an implementation problem. > In section IV.B you note that the packet size is significantly smaller > than the maximum sized packet size. In section 5.3 of RFC4342 (CCID3) > it says that the packet size s can be set, or the MSS can be used > (which is what it appears yours does) or the implementation can work > out the average packet size. > In the case of voice traffic this choice becomes important, since the packet size is so much smaller than the typical maximum segment size. We chose to approximate s through the average packet size (thereby limiting the sending rate somehow) since the s factor later comes into the computation of the initial loss interval (and the associate loss rate). Having used an s value much higher than the actual packet size would have resulted in a huge loss rate coming out of the formula and a very limited send rate after the transition to congestion avoidance. > In Linux we allow socket options to set s for the TFRC calculation > which helps with packet sizes being substantially smaller than the > MSS. However it won't help solve the problem that occurs due to idle > periods as you describe later on - but only help for continuous > streams. > > I too agree strongly with the parts about TFRC being passed upon > TCP-Reno which is not used in modern stacks in it's original form. > When I use iperf on modern TCP variants I see significantly higher > throughput than the TCP throughput equation predicts. This does mean > that TFRC is using less than it's fair share as you say. > > Is the source code freely available for your modified ttcp and also > for your calculation of r? If it is I would like to be able to look at > the code to see if it can be of assistance in my research. > > This is a great paper overall. > > Regards, > > Ian > -- > Ian McDonald > Web: http://wand.net.nz/~iam4 > Blog: http://imcdnzl.blogspot.com > WAND Network Research Group > Department of Computer Science > University of Waikato > New Zealand > >
