Ian, thanks for the comments! On Aug 25, 2006, at 2:34, Ian McDonald wrote:
In the first paragraph of the introduction you use "looses" where it should be "loses".
fixed.
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.
I think the problem that Vlad had was that the KAME stack would crash with very small delays. I'm not sure if we figured out the reason.
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.
I guess there's a PhD here for someone to extend Jitendra's model :-)
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.
We should be able to make that available. I'll post a pointer to the list shortly.
Thanks, Lars -- Lars Eggert NEC Network Laboratories
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
