[e2e] TCP Performance with Traffic Policing

[Marco Mellia]

Hi Barry,

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,
Marco

> Hi,
>
> 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,
>
> Barry
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20110812/dee3249d/attachment-0001.html