Internet management for receive traffic?

Answered Question
Oct 14th, 2009
User Badges:

Our internet pipe is getting pounded (receive/return traffic) since we upgraded our school's T1 to Gig. My question, would the only way to improve the congestion be with a bandwidth upgrade? I can't perform policing or shaping on received traffic from the isp on our router's outside int right?


If I did do a service policy to police traffic at lets say 256K, wouldn't the clients adjust the tcp window accordingly, which may help?


Any suggestions or comments are welcomed. Thanks in advance

Correct Answer by Joseph W. Doherty about 7 years 5 months ago

Your reference does discuss the 6500 series Microflow policing feature I had in mind.


As for other documentation, don't have any good references because what we're dicussing is a bit on the extreme edge of QoS. Most documentation would assume you have the capability to manage bandwidth upstream of a bottleneck, not downstream of it. Most QoS documentation really doesn't address TCP per-flow bandwidth management by drop management (except perhaps RED). We're also limited by the capabilities of typical network devices. Applicances (e.g. Packeteer's) designed for bandwidth management (which I don't think Cisco has within their product line), provide other interesting features. For instance, spoofing a receiver's TCP RWIN can be used to regulate a TCP sender's transmission rate.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Lucien Avramov Wed, 10/14/2009 - 18:16
User Badges:
  • Red, 2250 points or more

What you can optimize is the uplink from your inside going to your ISP with policing / shaping.


You can not get more BW from your provider with QoS.


If you police traffic at 256k, what is your intend? drop traffic exceeding 256k? that may not be a good solution.


The way I understand your problem is that the bw from your provider is smaller now that you have a gig inside network.

You can definitely prioritize certain traffic with class-maps for example, but you will not get a bigger pipe, with QoS.

Joseph W. Doherty Thu, 10/15/2009 - 06:17
User Badges:
  • Super Bronze, 10000 points or more

You've upgraded your Internet connection from a T1 to (full?) gig and you now have inbound internet link congestion? (Is this correct?)


Yes, you can perform inbound policing, although except for TCP traffic, such inbound policing might be ineffective in managing inbound congestion. Ideally you want to mangage congestion on the other side of the link, egress.


If you police traffic, and drop packets, drops seen by a TCP sender should adjust its congestion window. Is this the TCP window you had in mind or were you thinking of the TCP receiver's window?

rhopkins_rcps Thu, 10/15/2009 - 07:19
User Badges:

I don't think I explained my situation to well so hopefully the attached drawing will.


I know I can police and shape traffic bw the data center and schools internal to control bandwidth.


Is there anyway to control usage from the isp to us? Not upstream/sent traffic since most of the bandwidth is used for downloading. For example could I write a service policy(on the router or firewall or router at each school), that when a user requests a stream of video from youtube that it will throttle it down to 256k?


I doubt any of this is possible without control of the isp router, but thought I would ask. I think my only option is restricting certian http traffic with our webfilter. I was just hoping instead of restricting I could throttle it some.


Well again, thanks for any comments.



Attachment: 
Joseph W. Doherty Thu, 10/15/2009 - 11:37
User Badges:
  • Super Bronze, 10000 points or more

Diagram does help!


Controlling congestion downstream of the congestion point is difficult. Policing traffic like TCP, or shaping return ACKs, can get TCP flows to slow since they adapt their flow rate when they see lost packets. Other traffic types often don't slow. I.e. you can certainly police traffic as it ingresses (to you) on the Internet link or before passing it on to individual schools, which will certainly limit their received rate, but this might not slow or reduce inbound congestion on the Internet link. However, if you drop enough packets out of a video stream, the receipient of the stream might discontinue attempting to view it since the quality would be so bad (taking this bandwidth demand off your Internet link).


On most Cisco devices you could set an aggregate bandwidth for something like all received youtube traffic and/or set an aggregate on each school link; policing per flow, though, isn't as common. Some 6500s support it, i.e. microflow policing, don't know about other devices such as firewalls.


Since you note this is only a problem since the school links were upgraded to gig, I suspect the fact of the prior T1 links effectively did something similar to above (again, too many youtube requests would just degrade them so such requests, and their bandwidth demand, would be self limiting).


If this is correct, you can certainly try to either police or de-prioritize traffic, such as youtube traffic, and see how it works for you. You can also investigate what other QoS features your network devices support look especially for anything like per flow rate management.

Correct Answer
Joseph W. Doherty Fri, 10/16/2009 - 08:29
User Badges:
  • Super Bronze, 10000 points or more

Your reference does discuss the 6500 series Microflow policing feature I had in mind.


As for other documentation, don't have any good references because what we're dicussing is a bit on the extreme edge of QoS. Most documentation would assume you have the capability to manage bandwidth upstream of a bottleneck, not downstream of it. Most QoS documentation really doesn't address TCP per-flow bandwidth management by drop management (except perhaps RED). We're also limited by the capabilities of typical network devices. Applicances (e.g. Packeteer's) designed for bandwidth management (which I don't think Cisco has within their product line), provide other interesting features. For instance, spoofing a receiver's TCP RWIN can be used to regulate a TCP sender's transmission rate.

rhopkins_rcps Tue, 10/20/2009 - 08:32
User Badges:

Thanks for the advice Joseph, I'll start tinkering around and see what I can mess up! Have a good one.

Actions

This Discussion