From: Anthony Pace (anthonypace@fastmail.fm)
Date: Wed Apr 09 2003 - 17:13:49 GMT-3
Thanx everybody for the ideas on traffic shapeing and QOS "on the leaf of
the tree". I am going to experiment with all of them. I put them all in a
notepad ad attatched them below in case anyone also is interested in
this. (It may need to be reformatted to fix the carriage returns)
QUESTION WAS:
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".
-------------------------------------------------------------------------------------------
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
-------------------------------------------------------------------------
That's when you need to talk to your ISP and request rate limiting
implementation.
Usually companies request that to protect the pipes from denial of
service
attack by rate limiting ICMP and other traffic they don't deem business
critical.
Peter
#7247 (R&S, Security, C&S)
CyscoExpert Corp.
4433 W. Touhy Ave. Suite 410
Lincolnwood, IL 60712
Phone (847) 674-3392
Toll Free (866) CyscoXP (297-2697)
Fax (847) 674-2625
------------------------------------------------------------------------------------------
Anthony,
"Policing it coming in" will help for many applications,
particularly
anything TCP based. Think about it. An incoming datagram is dropped.
The
receiving station doesn't receive it, so it waits. The sender also waits
for an ACK. This second or so of waiting can save a ton of bandwidth if
you
multiply it by dozens or hundreds of individual flows. It won't show
much
of an improvement in a hopeless situation like a congested 56 kb circuit,
but for a T1 and above that can handle many flows at once, it'll help a
bunch. I've used NBAR to rate limit file-sharing apps inbound at a
college.
The circuit usage dropped about 70% over the course of a month. Use NBAR
protocol-discovery on the internet interface, and rate limit what you
deem
as less-critical. It'll take some experimentation, but it really works.
HTH,
Chuck Church
CCIE #8776, MCNE, MCSE
Wam!Net Government Services
13665 Dulles Technology Dr. Ste 250
Herndon, VA 20171
Office: 703-480-2569
Cell: 585-233-2706
cchurch@wamnet.com
-------------------------------------------------------------------------------------
I've managed to use generic traffic shaping quite successfully for this
scenario. You
configure the GTS on the outgoing interface of your router.
For example:
256k Serial to Internet - Heaps of incoming HTTP from internet web sites,
no room for other
"critical" apps..
Apply GTS on ethernet interface, limiting the HTTP to 192k:
int e0
traffic-shape group 177 192000 24000 8000 1000
access-list 177 permit tcp any eq 80 any
This gives us 64k clear bandwidth for non http traffic....
Shaping seems to works well because the packets are delayed, slowing down
the outbound acks
....which in turn slows down the incoming HTTP...
Hope this helps.
Daniel
danielcgs@imc.net.au
-- Anthony Pace anthonypace@fastmail.fm-- http://www.fastmail.fm - Consolidate POP email and Hotmail in one place
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:35:50 GMT-3