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

Richard Clayton sledge121 at gmail.com
Sun Nov 10 16:07:43 EST 2013


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 <javascript:;>>
>
> > 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 <javascript:;>
> > 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 <javascript:;>
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list