Hi,thanks for the feedback. Let me try to answer below. Vlad (CC'ed), if I get your experimental details wrong below, please correct me!
On Aug 8, 2006, at 19:00, Arjuna Sathiaseelan wrote:
1)Does the packet loss rate consider the loss of packets due to the improper synchronization of the application encoding rate and TFRC-SP's sending rate after silence periods or is it due to loss of packets due to congestion only?
The configured packet loss rate that is a parameter of the experiment causes only random drops at the router. Additional packets may be dropped at the sender - independent of that parameter - if the apps sends faster than the current window/rate. I believe Vlad used a send buffer of 5 packets. If that's not in the paper, we definitely need to add it. I also believe that send buffer overflow was extremely rare, but Vlad would know better.
If you hadnt used dummy packets during the initial slowstart, then I guess you would have got a large packet loss rate! :)..
Sorry, I don't understand - there were no dummy packets.
2)"This is surprising,because TFRC SP is allowed to inject as many small packetsin the network as desired," I am not sure if this statement is right? I guess it has some upper limit (100 packets)? Correct me if I am wrong..
I'm actually not sure :-) If you're right, than this is misleading and the wording should be changed. Anyway, I don't think we ever reached that packet rate, so it wasn't a factor for the experiments. (Vlad, is that right?)
Some points: * I guess some improvement would be there - since the receiver rate after idle period has been currently sorted out.
Yes, this paper unfortunately doesn't measure the mechanisms described in the very last versions of the drafts. I think the performance of the TFRC SP+FR+MD variant should be very close to what we'd get with the latest revision of the spec, because the solution that Vlad came up with and the changes to the draft should have a similar effect.
* With larger delays, the quality of voice is too bad and this is worrying!
This may be due to the E-model metric, which is based in telephony, where user-perceived delays over 150ms or so are considered very poor. In other words, with increasing delays, the quality impairment due to delay becomes the dominating factor, due to the way the formula works.
Thanks again for the feedback! Lars -- Lars Eggert NEC Network Laboratories
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
