[e2e] TCP Performance with Traffic Policing

[Barry Constantine]

Hi,

Let me provide better background information.

End-customers (business companies) purchase a network service from a network provider and purchase a Service Level Agreement (SLA).  This SLA specifies the committed information rate (CIR) which the provider will guarantee along with loss / latency specifications.

The end customer connects up either with 100M or 1G interface (generally) and the provider generally polices down to the CIR.

The disconnect comes about as this; providers qualify the network at Layer2/3 and run stateless traffic up to the CIR and of course network performance is fine.

The end customer runs their traffic across the network (many times running iperf or FTP first), gets significantly worse performance then the CIR, and the finger-pointing and churn begins.

I am trying to educate network providers that:

a) Testing a network with Layer 2/3 stateless traffic is not a great test (good starting point, but needs to add TCP testing as best practice
b) The benefits of traffic shaping can be enormous

So I hope this provides some background, and again, this list has provided great nuggets of information very quickly.

Regards,
Barry


-----Original Message-----
From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Eli Dart
Sent: Friday, August 12, 2011 12:11 PM
To: end2end-interest at postel.org
Subject: Re: [e2e] TCP Performance with Traffic Policing

The thing about policers is that they induce loss.  So, what you're 
really testing is the ability of a TCP implementation to recover from 
loss under high-latency conditions, and adapt a connection to the 
existence of a bottleneck link with no buffer when TCP has potentially 
allocated more window than the BDP of the path requires.

(I'm assuming that the host interface was 100Mbps or faster - this means 
that the bursts coming out of the host have an instantaneous rate that 
is probably at least 10x the policed rate, increasing the chance of loss 
even if the window is not too big).

In my experience, most TCP implementations (and I say most only because 
I have not exhaustively tested all the various flavors) perform poorly 
in circumstances where there is any loss at all and latency is over 
15-20 msec.

Thanks,

		--eli



On 8/12/11 7:03 AM, Barry Constantine wrote:
> 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
>
>

-- 
Eli Dart                                            NOC: (510) 486-7600
ESnet Network Engineering Group (AS293)                  (800) 333-7638
Lawrence Berkeley National Laboratory
PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3