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

[Youssef Bengelloun-Zahr]

Hello,

I don't have access to the CPE, or intermediate PEs, they are not under our responsability.

Yes, we already been down that road and it has been increased more than enough on both. Wireshark captures confirm that.

Thanks.



Le 11 nov. 2013 à 05:07, Richard Clayton <sledge121 at gmail.com> a écrit :

> Whats the cpe cpu running at with both streams, have you tried adjusting the window sizes on the servers, could help with bandwidth delay product.
> 
> On Sunday, 10 November 2013, Youssef Bengelloun-Zahr wrote:
>> 2013/11/10 Phil Mayers <p.mayers at imperial.ac.uk>
>> 
>> > 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?
>> 
>> 
>> Yes, we internally use a tool called IXChariot which provides us
>> loss/jitter, etc. Everything is fine.
>> 
>> 
>> >
>> >
>> >
>> >>     - 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.
>> >
>> 
>> To be more clear :
>> 
>>     - When we initiate TCP streams only in way (FRA > HAM or HAM > FRA), we
>> are able to reach up to 90 Mbits/s,
>> 
>>     - When we initiate TCP streams both ways simultanaously (FRA > HAM and
>> HAM > FRA), BP drops between 40 to 60 Mbits/s,
>> 
>> 
>> >
>> > 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.
>> >
>> 
>> We generally use IXChariot on windows :
>> 
>> http://www.ixiacom.com/products/ixchariot/
>> 
>> At the request of our provider, we also used iperf. We are a Windows home,
>> nothing I can do about that ;-)
>> 
>> 
>> >
>> > 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 of my colleagues who has access to the boxes have been able to do just
>> that using Wireshark, he noticed a few percentage of TCP re-transmits (2%)
>> when we initiate TCP streams for HAM to FRA but that was at the beginning.
>> I don't think this is the case anymore.
>> 
>> 
>> >
>> >
>> >  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.
>> 
>> 
>> I thought about it two and I asked.
>> 
>> I know our provider isn't using that kind of equipment at the handoff
>> points in FRA and HAM, they mostly use Cat45xx and some Juniper gear.
>> 
>> Impossible to get the information from the LL provider as we don't have a
>> direct contractual link.
>> 
>> 
>> >
>> > _______________________________________________
>> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-nsp
>> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>> >
>> 
>> 
>> 
>> --
>> Youssef BENGELLOUN-ZAHR
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/