[e2e] TCP Performance with Traffic Policing
mellia at tlc.polito.it
Fri Aug 12 09:16:38 PDT 2011
Welcome to the TCP testing mess :)
From my experience:
- do consider buffering policies. It's much more critical than anything else
- to this extent, do not trust delay generators: they have to buffer
packets, and sometimes the buffer they have is simply too small so that
they end up adding a huge loss probability.
- same for shapers buffering and algorithms. How big is the buffer?
- similarly, do not trust iperf too much. Especially the window
parameter is very fuzzy in my experience.
Another hint: avoid connecting gbps links to arrive to a bottleneck
which is 2 order of magnitude slower. that means that 100 packets arrive
at the congested buffer while only 1 packet can exit. As you can
imagine, the burstiness makes everything worse...
FYI, we have done similar tests, and got similar results. I can forward
then to you if you like.
Hope this helps,
> I did some testing to compare various TCP stack behaviors in the midst
> of traffic policing.
> It is common practice for a network provider to police traffic to a
> subscriber level agreement (SLA).
> In the iperf testing I conducted, the following set-up was used:
> Client -> Delay (50ms RTT) -> Cisco (with 10M Policing) -> Server
> The delay was induced using hardware base commercial gear.
> 50 msec RTT and bottleneck bandwidth = 10 Mbps, so BDP was 62,000 bytes.
> Ran Linux, Windows XP, and Windows 7 clients at 32k, 64k, 128k window
> (knowing that policing would
> kick in at 64K)
> Throughput for Window (Mbps)
> Platform 32K 64K 128K
> Linux 4.9 7.5 3.8
> XP 5.8 6.6 5.2
> Win7 5.3 3.4 0.44
> Do anyone have experience with the intricacies of the various OSes in
> the midst of
> Traffic policing? I was surprised to see such a variation in
> performance, especially since Windows 7 is supposed to more advanced
> than XP,
> I am going to comb through the packet captures, but wondered if anyone
> had insight.
> Thank you,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest