[c-nsp] Re: Traffic Shaping packet loss

Tue Sep 27 01:30:34 EDT 2005

Kana,

  One of our feeds is a FE feed via a colocate too.

  My advice is as a general rule to remove any burst limiting
on your side.  Granted you are going to have customers that are complete
morons who your going to have to play games with.  But I think you need
to give more credit to most of your customers I think they are smarter
than
your giving them credit for.

  We have plenty of business customers on T1 lines that are provisioned
at 1.5MB.  We make it clear when they sign up that if we see excessive
use on their lines then we are going to raise their rates, and we graph
all of them via MRTG.  We have never had any of them wave around a
contract
claiming we can't bill them more money when we have seen excessive
use and we've gone back to them and said "Guys, we really need to talk
about what your paying us"  These have been in fact a few times that
we've brought this kind of thing up and our customer has told us to
hang on a few weeks, then they've proceeded to go through their
own organization and wack out all traces of The Weather Website applets,
IM, and other useless and bandwidth-sucking applications, whereupon
their bandwidth utilization falls off rapidly.

  The problem with limiting like what your doing is it can really badly
impact some severe latency-sensitive applications, like Telnet, xterms,
VoIP and some other things like that.  Also, keep in mind too that
when you start throwing out packets, the IP stacks of the sender
and receiver are just going to retransmit them anyway.  So you end up
increasing utilization on your lines with the retransmits.  Once a
customer
packet has arrived at your network from your own feeds, your better off
slightly delaying it in a buffer then forwarding it if you have available
bandwidth rather than tossing it, whereupon
now your own feed has just had to pass 2 packets instead of one.
It is really better to manage bandwidth at the end-user application
level, by having the app limit it, or by delaying packets through
artificial means. (which is what shaping is all about)

Ted

>-----Original Message-----
>From: cisco-nsp-bounces at puck.nether.net
>[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Kanagaraj Krishna
>Sent: Monday, September 26, 2005 5:35 AM
>To: Dan Martin
>Cc: cisco-nsp at puck.nether.net
>Subject: RE: [c-nsp] Re: Traffic Shaping packet loss
>
>
>Dan,
>   Our customers co-locate with us and are directly connected
>to the switch.
>Its just that, we provide MRTG access to customers who want to
>monitor their
>traffic utilization. By setting the burst rate high, i don't
>want the customer
>to think they are getting more than they subscribed. Another
>thing is that for
>business reason, if the MRTG shows the traffic is hitting the
>cap (just say
>64K and not more), we can ask them to upgrade. Any comments?
>
>Kana
>
>> Yes, you're right.
>>
>> This is a tough one to get, but your ping problem is a
>perfect teaching
>> tool.
>>
>> Think of it like this.  take your packets per second setting
>and divide
>> it by a thousand, because I suck at math, lets say it's a thousand
>> packets per second.  That means every millisecond, you have
>the right to
>> send one packet across that port.  I know, its not in packets, its in
>> bytes, but bear with me for another moment.
>>
>> If two packets show up during that millisecond, one gets dropped.  It
>> doesn't matter how many packets showed up the millisecond
>before or the
>> millisecond after.
>>
>> If you increase the burst size and your pings get through,
>that tells me
>> that there is not something else wrong, its only that your ping is
>> arriving at a higher rate than your contracted one.
>>
>> If you want to manage the bandwidth so tightly you should look into
>> traffic shaping on your customer's premises in order to match the
>> contract you're offering.
>>
>> -----Original Message-----
>> From: Kanagaraj Krishna [mailto:kanagaraj at aims.com.my]
>> Sent: Monday, September 26, 2005 8:03 AM
>> To: Dan Martin
>> Cc: cisco-nsp at puck.nether.net
>> Subject: RE: [c-nsp] Re: Traffic Shaping packet loss
>>
>> Dan,
>>     I thought that the burst rate only takes into effect once the
>> average
>> speed limit is passed. Am i right?
>>
>> Quoting Dan Martin <dmartin at micromuse.com>:
>>
>> > So many per unit time.
>> >
>> > It doesn't wait a whole second and then pass or fail the stream.
>> >
>> > It divides a second into some number of parts, figures out how many
>> > packets or bytes should arrive during that part, and drops the rest.
>> >
>> > That is why your burst setting fixes the problem.  You allow some
>> number
>> > of packets to arrive at a higher rate than contracted.
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: cisco-nsp-bounces at puck.nether.net
>> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kanagaraj
>> > Krishna
>> > Sent: Monday, September 26, 2005 6:26 AM
>> > To: cisco-nsp at puck.nether.net
>> > Subject: [c-nsp] Re: Traffic Shaping packet loss
>> >
>> > Hi guys,
>> >             I have a setup with a Catalyst 2950 connected to a GigE
>> port
>> > on 7206VXR. Sub-interfaces are configured on the GigE port for each
>> VLAN
>> > (dot1Q) that are assigned to each port in 2950. To control the
>> traffic,
>> > I've added the rate-limit command on the subinterface
>> >
>> > rate-limit input 64000 2000 2000 conform-action transmit
>exceed-action
>> > drop
>> > rate-limit output 64000 2000 2000 conform-action transmit
>> exceed-action
>> > drop
>> >
>> > It seems that when i do ping test, there are packet losses
>(even when
>> > the traffic is low). One thing I realised is that when the
>burst rate
>> is
>> > increased, the packet loss decreases. Any idea on why this happens?
>> >
>> > Regards,
>> > Kana
>> > _______________________________________________
>> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-nsp
>> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>> >
>>
>>
>> --
>> Kanagaraj Krishna
>> Network Engineer
>> Network Engineering
>> Applied Information Management Services Sdn. Bhd.
>> (AIMS Sdn. Bhd.)
>> Ground Floor, Menara Aik Hua,
>> Changkat Raja Chulan,
>> 50200 Kuala Lumpur,Malaysia.
>>
>> Tel     : +603-20314988 Ext : 395
>> Mobile  :  012-3266151
>> Fax     : +603-20318948
>> Email   : kanagaraj at aims.com.my
>>
>
>
>--
>Kanagaraj Krishna
>Network Engineer
>Network Engineering
>Applied Information Management Services Sdn. Bhd.
>(AIMS Sdn. Bhd.)
>Ground Floor, Menara Aik Hua,
>Changkat Raja Chulan,
>50200 Kuala Lumpur,Malaysia.
>
>Tel     : +603-20314988 Ext : 395
>Mobile  :  012-3266151
>Fax     : +603-20318948
>Email   : kanagaraj at aims.com.my
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date:
>9/23/2005
>