Re: [spam score 3/10 -pobox] RE: Router with bandwidth management

[Brian Candler <B.Candler at pobox.com>]

On Mon, May 19, 2003 at 07:51:39AM +0300, Mark Tinka wrote:
> Well Brian, that then brings us back to Cisco's basic bandwidth management
> implementation, CAR [rate-limiting].
> 
> By defining contract bandwidth, you set the actual bandwidth your client is
> paying you for, in your example, 256Kbps out of 512Kbps.

Yes, but the customer cannot control how fast traffic enters their network
from the Internet - your contract is with the customer, not with the rest of
the world. So CAR just counts the incoming traffic, and starts dropping
packets if it exceeds the CAR, once their burst has been used up.

If I start an FTP download from a remote well-connected site, it will dump
data at me as fast as it can, until the negotiated TCP window is full, and
it then slows down to match the rate at which I send ACKs to it. So taking
this example:

                  512K DSL line
       Client <---------------------- Cisco <---------- Internet <-- FTP
                                    ^                              server
                                    |
                              CAR policer
                              set to 256K

The TCP connection for data transfer opens, and negotates a window
(typically 32KB). So the FTP server sends 32KB of data immediately, at
100Mbps say. Hence the CAR better have a burst size of more than 32KB,
otherwise packets will be dropped at this point. The data is then sent to
the client at 512Kbps, which is the speed of the underlying link. For each
incoming TCP segment the client sends an ACK, which triggers the FTP server
to send another TCP segment. Since the client is receiving data at 512Kbps,
the FTP server will continue to send data at 512Kbps.

With CAR this is not sustainable: once the burst has been exceeded, the
Cisco will start dropping packets. This catastrophic packet loss will cause
TCP congestion-control to kick in, rapidly backing off the sending rate.
Once another packet can get through, the sending rate will start increasing
again, until packet loss occurs again, and so on. What you get is a nasty
sawtooth-like bandwidth usage, and the customer's average usage will be
below 256K.

By increasing the burst size you can delay the onset of this undesirable
behaviour, but then again the customer will be using 512K not the 256K they
have paid for, which is not what you want.

So, somewhere along the line, what you really want is a device which
receives packets into a queue and empties it at a slower rate, 256Kbps in
this example - just the same as if the output interface were a 256Kbps
serial line.

Regards,

Brian.

-----
This is the afnog mailing list, managed by Majordomo 1.94.5

To send a message to this list, e-mail afnog at afnog.org
To send a request to majordomo, e-mail majordomo at afnog.org and put
your request in the body of the message (i.e use "help" for help)

This list is maintained by owner-afnog at afnog.org