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

["Mark Tinka" <mtinka at africaonline.co.ug>]

Are you then saying that the service provider should strive to give the
client more than the 256Kbps the client isn't feeling satisfied with? 

In the client-provider SLA - "I can guarantee you 256Kbps as long as you
keep within 256Kbps or 32Kbps data trasnfer rate. I can't guarantee you full
passage if you attempt to go beyond this capacity."

Isn't this what the provider is trying to achieve for the client? If the
client wants to connect at speeds in excess of the 256Kbps, the provider is
obliged to bring him down to sanity, or else he upgrades and a new SLA is
written up.

In what I have experienced, if a client has 128Kbps [16Kbps data transfer
rate], the application that can hog all this capacity will sustainably
maintain 16Kbps transfer rates at all times e.g. your favorite p2p software.
All other clients sourcing the same IP address will suffer because they are
trying to exceed 128Kbps, and their packets will be dropped. In this case,
client hasn't kept his side of the SLA.

Regards,

Mark Tinka - CCNA
Network Engineer
Africa Online Uganda
5th Floor, Commercial Plaza
7 Kampala Rd,
Tel:   +256-41-258143
Fax:   +256-41-258144
E-mail: mtinka at africaonline.co.ug
Web:     www.africaonline.co.ug
 

-----Original Message-----
From: Brian Candler [mailto:B.Candler at pobox.com] 
Sent: Monday, May 19, 2003 10:07 AM
To: Mark Tinka
Cc: 'Robert'; afnog at afnog.org
Subject: Re: [spam score 3/10 -pobox] RE: Router with bandwidth management


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