[nsp] Bandwidth Cap Question

[Dmitri Kalintsev]

Hi Dan,

On Mon, Mar 31, 2003 at 08:20:16AM -0500, Dan Armstrong wrote:
> >From what I have seen, CAR seems to work well if you have 1 "flow".  If you are trying to choke a port, it
> could conceivably have a whole network of flows behind it.

TCP flow, you mean. UDP does not care about lost packets.

> Here is was I think, please correct me if I am wrong.
> 
> With CAR, ie choking at layer3, the router drops packets that exceed the rate limit WITHOUT sending back an

CAR is *not* a choking at L3. It is applied to the packets that have matched
some specific criteria, would it be L2 or L4 match, all the same. Dropping
component is also not mandatory - you can simply re-label your packets
somehow for instance.

> ICMP source-quench.  You then rely on the stack of the sending application to realize that packet did not
> arrive, and re-transmit.  Eventually, the sliding window will reach an equalibrium, and the flow will go
> through at the specified rate.

Yes, for large transfers.

> Now, what if there are say 50 individuals ie 50 individual IP stacks all doing the same thing, for relativley
> short periods of time, like say surfing the web?  TCP will never have a chance to stabilize, and you will be
> putting a huge amount of extra traffic through your edge/access network that just gets dropped at the first
> router that is doing CAR....

CAR is plain bad when you don't have enough flows through the router not to
cause back-out synchronization. When you *do* have enough flows, then it's
reasonable.

All in all, CAR is bad. GTS is bad, too. Vendors were promising a "better
CAR" for some time, but it is still to eventuate.

SY,
--
D.K.

> 
> ?
> 
> Dan.
> 
> 
> Alexandre Snarskii wrote:
> 
> > On Fri, Mar 28, 2003 at 08:16:38AM +0100, sthaug at nethelp.no wrote:
> > > >     I have a 6500 running in native mode, and I'm
> > > > wondering whats the best way to cap VLANs or specific
> > > > subnets. I've tried setting up Qos Policers for 1Mbps
> > > > but it did not work well at all, and was only able to
> > > > do a few kB/s. TAC told me its because of TCP and
> > > > theres no way around it.
> > >
> > > If you're trying to limit bandwidth on *output*, the current 6500
> > > hardware (Sup2/PFC2) simply cannot do it. Has nothing do to with
> > > TCP and everything to do with the hardware implementation.
> >
> > Hmmm... Just tried CAR my computer with 6500/native (msfc2/pfc2):
> >
> > Interface configuration with policy applied:
> > interface Vlan155
> > [...]
> >  rate-limit output access-group 199 256000 48000 96000 conform-action transmit exceed-action drop
> >
> > access-list 199 permit ip any host x.x.x.x
> > access-list 199 deny   ip any any
> >
> > Getting ftp receive rate:
> > 2243759 bytes received in 79.47 secs (27.6 kB/s)
> >
> > FTP'ing the same file from the same host within seconds after
> > (just those seconds required to drop rate-limit statement from configuration):
> >
> > 2243759 bytes received in 7.73 secs (2.8e+02 Kbytes/sec)
> >
> > IOS version is:
> >
> > IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(11b)E4, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > http://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
---end quoted text---

-- 
 CCNP, CCDP (R&S)                          Dmitri E. Kalintsev
 CDPlayer at irc               Network Architect @ connect.com.au
 dek @ connect.com.au    phone: +61 3 8687 5954 fax: 8414 3115
 http://-UNAVAIL-         UIN:7150410    cell: +61 414 821 382