RE: QOS, traffic policing and shaping (real-world)

From: Brian McGahan (brian@cyscoexpert.com)
Date: Tue Apr 08 2003 - 13:33:17 GMT-3


Tony,

        Like Chuck said, policing inbound will work well for anything
TCP based. When the router drops a packet, the destination will not be
sending an ACK for the dropped packets. This will cause the sender to
go into either TCP slow start or congestion avoidance. Due to this
sliding windowing mechanism, TCP behaves pretty well when you want to
enforce a rate limit on it.
        
        For TCP traffic, the recommended formula is

NORMAL_BURST_bytes = (TARGET_bits / 8) * 1.5
EXCESS_BURST_bytes = NORMAL_BURST_bytes * 2

        Combine this with NBAR, and who needs a packeteer? ;)

For more info:

RFC 2001: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and
Fast Recovery Algorithms

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2001.html

Policing and Shaping Overview:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
fqos_c/fqcprt4/qcfpolsh.htm#1000977

NBAR:

http://www.cisco.com/warp/public/732/Tech/qos/nbar/

HTH,

Brian McGahan, CCIE #8593
Director of Design and Implementation
brian@cyscoexpert.com

CyscoExpert Corporation
Internetwork Consulting & Training
Toll Free: 866.CyscoXP
Fax: 847.674.2625

> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Anthony Pace
> Sent: Monday, April 07, 2003 8:01 PM
> To: ccielab@groupstudy.com
> Subject: QOS, traffic policing and shaping (real-world)
>
> I have a sort of generic real world question about traffic
engineering.
> How can you control the bursty traffic on a connection to the Internet
> (or anywhere) when the EGRESS traffic is relatively light compared to
the
> massive amount of traffic coming back. In this scenario we don't
control
> the upstream (PROVIDER) router.
>
> - "Police it coming in" won't help as it has already done it's damage
by
> consuming the link
>
> - "Shape it going out" won't help because the "requests" are not
> bandwidth intensive, and queuing never really kicks in; unless the
> outbound traffic begins to fill the queue (which it doesn't).
>
> I have used traffic-policing in the past to control a customers
INGRESS
> traffic, as it leaves their spoke destined for the HUB, stopping them
> from getting more bandwidth than they paid for. I have also worked
> through the countless traffic shaping and QOS labs for CCIE, and read
all
> the examples on this in books, where we are asked to divide the
bandwidth
> up by managing who gets dropped out of the queue as their packets are
> waiting to be put on the wire.
>
> Does this question make sense? I don't see the Asymmetrical nature of
> Internet or Client/Server traffic addressed in any of the books I have
or
> on CCO. It is seems like everyone is always more obsessed with the
"exact
> byte count in the queues".
>
> Anthony Pace CCIE 10349
> --
> Anthony Pace
> anthonypace@fastmail.fm
>
> --
> http://www.fastmail.fm - The way an email service should be



This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:35:49 GMT-3