problem with CCID3 loss events
Hi,
I did some CCID3 tests lately with 2.6.20final_dccp (2.6.20 with Ian's patches applied - not the latest patches BTW, the ones in http://wand.net.nz/~iam4/dccp/patches20/). From the tests, I realized that DCCP behaves OK when there is no loss. However, when packets are started to be lost, DCCP nearly shuts itself down and can barely send any packet for a time. I suspect there is something wrong with the loss rate calculation. Any comments on this?
A detailed report is available in http://home.ku.edu.tr/~bgorkemli/dccp/DCCP_Tests.htm
Burak
Hi there Burak,
I've got a few comments here as I'm certainly not seeing that sort of effect.
I think your main problem is in your queue length and possibly your netem setup (you don't give your scripts for that).
You've set your queue length for CCID3 at 100 and coupled with netem behaviour of having very low buffers by default you can end up with a send rate of virtually zero. I normally use a queue of no more than 32.
In your netem diagram I notice you have two links constrained. Normally an input constraint doesn't work unless you do some other magic (see OSDL Wiki). I just do the following.
/sbin/tc qdisc add dev lan0 root handle 1:0 netem delay $1ms /sbin/tc qdisc add dev lan1 root handle 1:0 netem delay $1ms /sbin/tc qdisc add dev lan0 parent 1:1 handle 10: tbf rate $2kbit buffer 10000 limit 30000
Notice also the buffer and limit settings being altered. This makes a BIG difference as otherwise you get large amounts of consecutive discard which sends momentary loss up to 100% which knocks send/receive rate close to zero.
I also hope you didn't apply patch 29 as that is my experimental patch. It won't actually work without the corresponding parameters to sendmsg so probably won't affect your results, but if you did reuse some of my client code there is a possibility you may have done this...
With your TCP fairness graphs - did you compare against Reno or BIC? Remember TFRC is based on Reno performance. Those graphs are interesting and back up my theory about buffer size as the performance gradually heads up to the right values when CCID3 slowly recovers which suggets it's getting clobbered way too hard at the beginning. Remember also if you've got too large buffers you're going to see way too long to correct - which is happening in your delay graph.
Lastly my code is not fully RFC compliant although I'm certainly seeing the right rates here in my research or roughly so anyway. Gerrit Renker has done a whole lot more good work on bringing closer to compliance. Also there probably will be bugs lying around but certainly try some of my suggestions and report back.
Regards,
Ian
PS I've updated my website with some of the content from this email.
Quoted 8 lines · Burak Gorkemli
Hi,
I did some CCID3 tests lately with 2.6.20final_dccp (2.6.20 with Ian's patches applied - not the latest patches BTW, the ones in http://wand.net.nz/~iam4/dccp/patches20/). From the tests, I realized that DCCP behaves OK when there is no loss. However, when packets are started to be lost, DCCP nearly shuts itself down and can barely send any packet for a time. I suspect there is something wrong with the loss rate calculation. Any comments on this?
A detailed report is available in http://home.ku.edu.tr/~bgorkemli/dccp/DCCP_Tests.htm
Burak
Signature · 3 lines
Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Quoted 1 line · Burak Gorkemli
Hi Ian,
Hi Burak,
Adding DCCP @ vger as I think you mistakenly added DCCP @ ietf to the mailing...
Quoted 1 line
Last but not the least, I have discovered that I am having some trouble with the sizes of the packets sent. When the packet sizes are equal to each other - which is not the actual case in my tests - everything goes fine. However, when they are not, DCCP behaves strangely, it halts for some period of time during the stream - I think due to the mismatch between the sizes of the packets sent and the average packet size used in the TCP equation. I must confess that I am not aggregating smaller packets into larger ones - which is the next thing that I will do - but I was not expecting such a big effect. I will post the test results later, as I implement packet aggregation.
CCID3 in Linux keeps a moving average of the packet size. If you look at the TFRC equation the rate = some numbers / packet size. In effect CCID3 therefore becomes rate limited by packets per second as it does not perform packet aggregation within the protocol (unlike TCP). This would explain your results in this regard.
Ian
Signature · 3 lines
Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Hi Burak,
I've got some issues doing tests on the same configuration you have. I'm using Dave Miller's tree instead of 2.6.20 patched with Ian's patches.
When I run iperf client (DCCP patched) with :
# iperf -c serverIP -Xdccp -l8 -t60 my client machine freezes completely after sending a few data. This issue appears only when I limit the rate on the netembox. (1024kbits/sec)
Did you ever have this problem ?
Patrick.
Quoted 22 lines · Ian McDonald
Quoted 1 line · Burak Gorkemli
Hi Ian,
Hi Burak,
Adding DCCP @ vger as I think you mistakenly added DCCP @ ietf to the mailing...
Quoted 1 line
Last but not the least, I have discovered that I am having some trouble with the sizes of the packets sent. When the packet sizes are equal to each other - which is not the actual case in my tests - everything goes fine. However, when they are not, DCCP behaves strangely, it halts for some period of time during the stream - I think due to the mismatch between the sizes of the packets sent and the average packet size used in the TCP equation. I must confess that I am not aggregating smaller packets into larger ones - which is the next thing that I will do - but I was not expecting such a big effect. I will post the test results later, as I implement packet aggregation.
CCID3 in Linux keeps a moving average of the packet size. If you look at the TFRC equation the rate = some numbers / packet size. In effect CCID3 therefore becomes rate limited by packets per second as it does not perform packet aggregation within the protocol (unlike TCP). This would explain your results in this regard.
Ian
--
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group
Hi again,
I find out what was the problem. I recompile the latest 2.6.20 kernel with Ian's patches, and my iperf client doesn't freeze anymore. So I guess there is something wrong in Dave Miller's tree (I didn't use Ian's patches).dccp_probe module doesn't work either with his tree, it seg fault trying to insert it.
Patrick.
Quoted 40 lines · Patrick Andrieux
Hi Burak,
I've got some issues doing tests on the same configuration you have. I'm using Dave Miller's tree instead of 2.6.20 patched with Ian's patches.
When I run iperf client (DCCP patched) with :
# iperf -c serverIP -Xdccp -l8 -t60 my client machine freezes completely after sending a few data. This issue appears only when I limit the rate on the netembox. (1024kbits/sec)Did you ever have this problem ?
Patrick.
Quoted 22 lines · Ian McDonald
Quoted 1 line · Burak Gorkemli
Hi Ian,
Hi Burak,
Adding DCCP @ vger as I think you mistakenly added DCCP @ ietf to the mailing...
Quoted 1 line
Last but not the least, I have discovered that I am having some trouble with the sizes of the packets sent. When the packet sizes are equal to each other - which is not the actual case in my tests - everything goes fine. However, when they are not, DCCP behaves strangely, it halts for some period of time during the stream - I think due to the mismatch between the sizes of the packets sent and the average packet size used in the TCP equation. I must confess that I am not aggregating smaller packets into larger ones - which is the next thing that I will do - but I was not expecting such a big effect. I will post the test results later, as I implement packet aggregation.
CCID3 in Linux keeps a moving average of the packet size. If you look at the TFRC equation the rate = some numbers / packet size. In effect CCID3 therefore becomes rate limited by packets per second as it does not perform packet aggregation within the protocol (unlike TCP). This would explain your results in this regard.
Ian
--
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group
Signature · 3 lines
------- Patrick ANDRIEUX email : [email protected]
Quoted 11 lines · Patrick Andrieux
Hi again,
I find out what was the problem. I recompile the latest 2.6.20 kernel with Ian's patches, and my iperf client doesn't freeze anymore. So I guess there is something wrong in Dave Miller's tree (I didn't use Ian's patches).
dccp_probemodule doesn't work either with his tree, it seg fault trying to insert it.Patrick.
Can you send your kernel .config files and also the scripts you use to load dccp and netem so I can try and replicate here and fix.
I can't promise a quick fix but will look into it. Given Dave M's tree for DCCP is the same as what Linus has I would like to fix it...
Do you have any more info from the segfault or freeze in your logs?
Thanks,
Ian
Signature · 3 lines
Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Quoted 13 lines · Ian McDonald
Quoted 11 lines · Patrick Andrieux
Hi again,
I find out what was the problem. I recompile the latest 2.6.20 kernel with Ian's patches, and my iperf client doesn't freeze anymore. So I guess there is something wrong in Dave Miller's tree (I didn't use Ian's patches).
dccp_probemodule doesn't work either with his tree, it seg fault trying to insert it.Patrick.
Quoted 7 lines
Can you send your kernel .config files and also the scripts you use to load dccp and netem so I can try and replicate here and fix.
I can't promise a quick fix but will look into it. Given Dave M's tree for DCCP is the same as what Linus has I would like to fix it...
Do you have any more info from the segfault or freeze in your logs?
Please, send all this information to the list.
- Arnaldo
Arnaldo,
Yes I'll send everything to the list, but I can't do it before tuesday.
Ian,
I have a few lines in logs about the seg fault, but about the freeze, not sure syslog keeps any info... I'll send that tuesday.
rgds,
Patrick.
Quoted 26 lines · Arnaldo Carvalho de Melo
Quoted 13 lines · Ian McDonald
Quoted 11 lines · Patrick Andrieux
Hi again,
I find out what was the problem. I recompile the latest 2.6.20 kernel with Ian's patches, and my iperf client doesn't freeze anymore. So I guess there is something wrong in Dave Miller's tree (I didn't use Ian's patches).
dccp_probemodule doesn't work either with his tree, it seg fault trying to insert it.Patrick.
Quoted 7 lines
Can you send your kernel .config files and also the scripts you use to load dccp and netem so I can try and replicate here and fix.
I can't promise a quick fix but will look into it. Given Dave M's tree for DCCP is the same as what Linus has I would like to fix it...
Do you have any more info from the segfault or freeze in your logs?
Please, send all this information to the list.
- Arnaldo