[e2e] TCP Performance with Traffic Policing

[Eli Dart]

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