From: Chris Home (clarson52@comcast.net)
Date: Tue Dec 10 2002 - 20:18:22 GMT-3
I understand and agree, those mechanisms can make a significant impact.
I was hurried when I wrote my post. I don't know if Sprint does CAR in all
of it's pops. I only know they do it in the 2 we are in. I would assume
that is how most ISP's would do it but I don't really know.
----- Original Message -----
From: "Robert Slaski" <robin@atm.com.pl>
To: "Larson, Chris" <CLarson@usaid.gov>
Cc: "P729" <p729@cox.net>; "sg p" <sgp4377@yahoo.com>;
<ccielab@groupstudy.com>
Sent: Tuesday, December 10, 2002 5:09 PM
Subject: Re: Reduce the bandwidth of Gig Interface
> Larson, Chris wrote:
> > I would have to disagree that "policing TCP traffic would be
disastrous." It
> > is done in many networks and I know Sprint does it in their Internet
pops.
> >
>
> I generally agree with your and P729's thoughts but WRED (you can forget
> 'W', for RED to work the traffic does not have to be classified or
> weighted) helps TCP windowing and slow start mechanisms to obtain best
> throughput. With 100:1 ratio of incoming to outgoing traffic output
> buffers on a switch will be continuously filled-up so packets will be
> dropped out from queue randomly. So you'll get 10Mbps of traffic but
> only few Mbps (maximum) of usefull traffic as the rest would be
> retransmissions. Enabling WRED and setting drop thresholds such that
> output queues never become 100% filled up and they can accomodate TCP
> bursts before policers start cutting traffic. This will help you obtain
> most of required 10Mbps.
>
> Sprint may police traffic in their POPs but to ensure that customers
> won't exceed the bandwidth they pay for - in fact most ISPs do this. But
> on the other hand I saw networks where ordinary policing from 10Mbps to
> 2Mbps was made on their ISP link and this caused the whole network to
> shut down while the link utilization did not exceed 200kbps. This is
> what I meant by "disaster". Enabling shaping, WRED or some fancy
> queueing helped there a lot.
>
>
> mikrobi,
> --
> .
.
This archive was generated by hypermail 2.1.4 : Fri Jan 17 2003 - 17:21:43 GMT-3