[nsp] Bandwidth Cap Question

Wed Apr 2 09:34:39 EST 2003

Here is a somewhat rhetorical question.  Again, please poke lots of holes in this.

What happens when you have a 100megabit "LAN" of many hosts, connected to a 10megabit "LAN" of many hosts, via an
Ethernet switch.  From any or all of those 100megabit hosts, I can flood ping the crap out of many 10 megabit
hosts and never drop a packet.  The switch can buffer the difference in speed for a fineite period of time, and
then it can either assert a carrier on the incoming port to force collisions, so the IP stacks in the sending
applications will chill out.  Recently X frames have been introduced to deal with the growing number of full
duplex ethernets, but basically the same thing.  (Am I right so far?)

What happens when a router encounters 2 dissimlar speed links.  OC-3 into a T1.  Lots and lots of hosts behind
each, like say on the Internet.  Packets come in on the OC3, way too fast to be sent down the T1.  The router
buffers for a fineite period of time, applies WRED, and if/when it drops a packet it sends an ICMP Source-quence
for every packet dropped..  (is that right?)  In reality I imagine that buffering alone takes care of 90% of the
differences in speed, since as I maintain most individual tcp flows across the Internet are very short, and small.

So, to properly choke a link down, you have to do it at layer 2 incoming from the customer (I am REALLY REALLY
hoping 3550 switches will do this properly) and choke the subinterface outbound on the router to the customer.

> 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.

Correct.

> > 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.

I should have been more specific, it chokes traffic above layer2.

>
> > 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.

Well this is just it.   It seems to me that CAR works great at a tradeshow with a guy and an ftp client on his
laptop demoing it, but reality is that most Internet traffic on a normal network is people suring the Internet.
Which involves lots of people with lots of short tcp flows.

> >
> > ?
> >
> > 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
>
> _______________________________________________
> 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/