[e2e] TCP Performance with Traffic Policing
alexander.zimmermann at comsys.rwth-aachen.de
Wed Aug 17 00:08:19 PDT 2011
Ok, once again...
my pgp plugin seems to have a bug...
Berry, could you put your dumps somewhere so that I can download them?
I will run tcptrace/xplot by my own. I hard to see anything on your plots.
Am 16.08.2011 um 22:37 schrieb Barry Constantine:
> Hi Anil,
> Attached is a Word document with the sequence charts from Wireshark.
> The 64KB and 128KB window sizes are shown for each OS.
> -----Original Message-----
> From: anil at cmmacs.ernet.in [mailto:anil at cmmacs.ernet.in]
> Sent: Saturday, August 13, 2011 4:24 PM
> To: Barry Constantine
> Cc: anil at cmmacs.ernet.in; end2end-interest at postel.org
> Subject: RE: [e2e] TCP Performance with Traffic Policing
> Hi Barry:
> Would be glad to see the plots/sequence data in case you would like to
> share them.
> If the cause is burst, then the next interesting question whould be: why
> the same TCP sender reacted quite differetnly to different (standard)
> clients when the policing was in between and normal otherwise.
>> Hi Anil,
>> Your assessments seem reasonable and I will look at the packet captures
>> with Wireshark as you suggest.
>> Also, thanks for pointing me to the old post; it was useful as well.
>> -----Original Message-----
>> From: anil at cmmacs.ernet.in [mailto:anil at cmmacs.ernet.in]
>> Sent: Saturday, August 13, 2011 3:15 PM
>> To: Barry Constantine
>> Cc: end2end-interest at postel.org
>> Subject: Re: [e2e] TCP Performance with Traffic Policing
>> Hi Barry,
>> Quite interesting
>> I would guess that the different flows (Linux, XP and Win7) in your
>> experiment might have expressed varying bursty patterns, and that would
>> have made the policing process to treat these flows differently. A time vs
>> sequence plot on either side of the policing box should help to bring out
>> the real dynamics.
>> Also, there was a similar post in e2e almost about a decade ago.
>> It is worth having a look
>>> I did some testing to compare various TCP stack behaviors in the midst
>>> 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
>>> midst of
>>> Traffic policing? I was surprised to see such a variation in
>>> especially since Windows 7 is supposed to more advanced than XP,
>>> I am going to comb through the packet captures, but wondered if anyone
>>> Thank you,
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: zimmermann at cs.rwth-aachen.de
// web: http://www.umic-mesh.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 163 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20110817/f7cfd91d/PGP.bin
More information about the end2end-interest