[e2e] TCP Performance with Traffic Policing
dart at es.net
Fri Aug 12 09:10:57 PDT 2011
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
On 8/12/11 7:03 AM, Barry Constantine wrote:
> 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,
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
More information about the end2end-interest