> | > | What I'm noticing is that the DCCP sender doesn't update it's ack > | numbers very often. In examining packet captures, it is typical for DCCP > | to send 20-60 packets with the same ack number (If I increase the ack > | and seq validity windows to 1000, I've seen 200 packets with the same > | ack number). > | > Depending on the type of link (duplex or half-duplex as in WiFi) and the > application sending rate, this might even be normal. Good point. I hadn't thought of checking whether the network was running duplex or half-duplex. It turns out that it was running half-duplex because I had a dumb hub in the testbed setup. Once I adjusted the testbed setup to remove the hub, I was able to run full duplex and DCCP started to work much better. I'm now seeing an increase in the ack number with almost every packet(which is what I would expect to see). Right now, I'm seeing speeds of 9.43Mbits/sec over a 10Mbit/sec link and 85Mbit/sec over a 100Mbit/sec link (TCP does 91Mbit/sec). Those speeds seem very reasonable and are much better than anything I have seen yet in working with DCCP. Is that about what I should expect to get out of DCCP? Or is it typical to get better performance than that? Samuel Jero Internetworking Research Group Ohio University
Attachment:
signature.asc
Description: This is a digitally signed message part
