Re: Reduce the bandwidth of Gig Interface

From: P729 (p729@cox.net)
Date: Tue Dec 10 2002 - 15:33:16 GMT-3


"Policing will cause disaster with TCP traffic"

I would agree that policing _without accommodating any bursting_ would be
disastrous. But only to the extent that connecting your home 10/100 Mbit/s
LAN to a 384 Kbit/s DSL line would be "disastrous." I would be surprised if
any modern TCP implementation did not implement slow-start.

"But you can use tail-drop-WRED available on gigabit ports of 3550"

This is fine for managing the egress queues. But based on the original post,
I assumed that the poster only had control of the 3550, which means somehow
exerting control of the ingress-side of things as well...

Regards,

Mas Kato
https://ecardfile.com/id/mkato
----- Original Message -----
From: "Robert Slaski" <robin@atm.com.pl>
To: "P729" <p729@cox.net>
Cc: "sg p" <sgp4377@yahoo.com>; <ccielab@groupstudy.com>
Sent: Tuesday, December 10, 2002 6:29 AM
Subject: Re: Reduce the bandwidth of Gig Interface

P729 wrote:
> "We want to use some type of traffic policing so that the excess traffic
> that arrives at our port (10Mb) doesnt get dropped due to the bandwidth
> reduction."
>
> Herein lies one of the differences between policing and shaping. With
> policing, you're allowing for a certain amount of bursting such that TCP
> between the end-nodes polices itself to your desired commited rate.
> Excessive bursting will lead to dropped (vs. delayed) frames. This is
> necessary to "close the window." With shaping, you begin delaying

Policing will cause disaster with TCP traffic, especially if you discard
99 out of 100 frames (1Gbps->10Mbps). But you can use tail-drop-WRED
available on gigabit ports of 3550 along with aggregate policing. This
will cause TCP traffic to be smoothed using its windowing mechanisms,
and policing will not allow the traffic to excess 10Mb.

mikrobi,

--
.


This archive was generated by hypermail 2.1.4 : Fri Jan 17 2003 - 17:21:42 GMT-3