[c-nsp] Effect of simultaneous TCP sessions on bandwidth

[Phil Mayers]

On 11/10/2013 05:42 AM, Youssef Bengelloun-Zahr wrote:

>     - UDP traffic reaches up to 95 Mbits/s for one way streams (both ways)
> and simaltaneous bi-directionnal streams,

If there's no (significant) loss or reordering on a simultanous bi-dir 
UDP stream at 95Mbit/sec, that suggests the pipe is absolutely fine.

Did you measure loss/jitter/reodering in this case? At frequent 
(1-second) intervals?

>
>     - TCP traffic reaches up to 90 Mbits/s for one way streams (both ways),
>
>     - TCP traffic hits some kind of limit and isn't able to achieve more
> than 40-60 Mbits/s in average      <=== That's the problem we are facing

I'm not really sure I understand this - those two statements sound 
contradictory.

How are you doing your testing? With what tool, and from what 
endpoints/OSes? In particular, we've seen some inconsistencies from 
iperf on windows; my tool of choice these days is netperf on a recent 
Linux kernel/distro.

Anyway, I would arrange to take a packet capture of a non-performing TCP 
stream at both ends, then use an analysis tool to identify the cause, 
and manual inspection to see if packets are being dropped and/or 
re-ordered or unduly delayed (hence taking the capture at both ends).

Wireshark has some reasonable TCP analysis tools built into recent 
versions, but my favourite for hardcore TCP debugging is still tcptrace 
and xplot; they're a pig to drive, but give you a much better detailed 
view of the TCP connection evolving.

> One bit of information I think is relevant :

It's worth mentioning that the specific type of equipment might be a 
factor, in particular if the handoff is on equipment with small buffers, 
microbursts might be eating into TCPs ability to drive the link. That 
would be quite odd on a system with modern congestion control algorithms 
and such a low bandwidth*delay, but you didn't say what you were using 
to test...

Check the handoff isn't on Cat3xxx gear or similar. But primarily, 
re-check the UDP test looking for loss/jitter/reordering, and look at a 
pcap of the bad TCP case.