1

I'm trying to understand the mechanism by which bandwidth is consumed so that I can set the appropriate QoS and/or priority policies on the firewall. Here's the scenario:

Our setup is a Fortigate 60E that sits between our LAN and an AT&T Managed Router with a 10Mbps connection.

When there is no one inside our facility but me, I initiate a single request from my PC browser to a site that starts the download of a 180Mb file. I can watch the bandwidth usage graph for the internal and external interfaces immediately jump to 10Mbps (i.e. the full limit of our service) and, when the download completes, the throughput graph drops back down to 0.

Before the download completes, I initiate another browser request (pick your typical news site with images and text), the firewall graph of bandwidth usage stays at 10Mbps and my second request ultimately gets served.

My question is this: what determines how much bandwidth is allocated to my second browser request? Furthermore, since the default priority (according to Fortigate) is that all requests have a default priority of "high" how are "competing requests" resolved? Clearly it's not sequential (first come, first served) because the second request is fulfilled before the first request (download) is completed.

When there are 10 or 15 people in the office, this scenario will be repeated and amplified many times over. I don't have VOIP or email or an ecommerce server that I need to elevate or prioritize over "normal" internet use. I just have a bunch of people accessing the web simultaneously and they have an expectation of a reasonably responsive internet. So I want to prevent the first requestor having a super fast awesome experience while everyone else (i.e. the subsequent requestors) waits.

My initial thought was to set a maximum bandwidth for all requests (i.e. no request would be allocated more than say 1Mbps of bandwidth), thinking that this would prevent one request from sucking up all the bandwidth. Is this advisable? If so, how would you do it? (Traffic shaping policy? or something else?) Would changing the priority of all traffic to medium (vs. the default high priority) have a favorable effect? Would it be advisable?

I'm new to this stuff, our company is new and our IT infrastructure setup is fresh as well. Feel free to let me know if I'm just not thinking about this the right way. I've read a ton but understand less than half of the jargon that gets tossed around. A layman's explanation/response would be most welcomed!

3

What you are asking about is incoming data, and you have no real direct control over the bandwidth use of incoming data. Remember that by the time you see the incoming traffic in order to police it, it has already used your incoming bandwidth. It is really first-come, first-served.

It is likely that the servers are sending faster than your link from the ISP, and many packets are dropped and re-requested. TCP will strike a balance because it uses connections, but any incoming UDP traffic (including real-time traffic like VoIP or video) will not be controlled, and it can completely clog your incoming link. The best you can do for incoming traffic is to police (drop) it, and that will give you a rough control over TCP traffic, but nothing for connectionless traffic.

The only thing you can directly control are the QoS policies and implementation on your own network. Some ISPs will allow you to pay extra to give you some QoS on their network, but on the greater Internet, your QoS policies and markings are ignored or reset to BE (Best Effort). You can, and really should, mark high- and low-priority traffic on your own network, and you can shape it out your WAN link.

Don't go overboard on the classification of traffic; usually four or five classification are enough. VoIP should be priority, and control traffic for routing protocols and things like VoIP should be the second highest priority. Things like server backup or other bulk traffic that can interfere with your business traffic should be a low priority. The vast majority of your traffic should remain as BE. Most people first getting into QoS try to mark everything in many different classifications, but this is a rookie mistake. Keep it simple, and if you get a half-dozen classifications, then you should really rethink things.

  • I see your point...in the download scenario its the external site/service feeding in the data. I was not thinking correctly about that. The download request originating from inside the LAN is indeed small. The result of the request is the problem. On the QoS, I have nothing to prioritize. We have no VOIP, no servers, nothing. We are a coworking space so volume varies a lot and the type of traffic is unpredictable. Is your advice, therefore, that we just get a big fat pipe and let web surfers be web surfers? – globalSchmidt Nov 5 '17 at 2:45
  • No. You can let TCP level the flows among the surfers, and you do have some control by dropping packets, which will cause TCP connection to slow down, but it is a pretty inexact way to do it compared to the almost exact method you have for outbound traffic. You could also shape or police the outbound TCP web requests.If it starts interfering with your business traffic, then you can get draconian. Our business uses proxies for web traffic that really restricts what you can do on the web, but we have over a quarter of a million employees. – Ron Maupin Nov 5 '17 at 2:50
  • Thanks... I can't get draconian...I won't have anyone wanting to use our coworking space. "You can let TCP level the flows"...how exactly is that done? Is that a "policy" that I would create on the firewall or something else? – globalSchmidt Nov 5 '17 at 2:53
  • One of the features of TCP is that as traffic is lost, and congestion will cause lost traffic, it will slow down. TCP speeds up sending until it finds problems, then it backs off a lot, and starts increasing until it runs into problems. When this behavior happens with a lot of flows, it can be a problem. There is a QoS method call RED that randomly drops packets in queues to prevent the synchronization of different flows from doing this. You can police incoming flows so that the servers slow down, but keep things like this in mind. You can also drop or shape outgoing TCP requests. – Ron Maupin Nov 5 '17 at 2:59
  • Are you suggesting that TCP handles the throttling of traffic by itself or are you suggesting that's a setting I need to find or create on the firewall? WRT to RED, I read up on that (no pun intended), but am too much of a newb to understand how I translate that theory into practice. Guidance welcomed. – globalSchmidt Nov 5 '17 at 19:31
2

Given the type of traffic you are describing, Ron Maupin is right about priorities. Since you are dealing with a varied number of users and therefore a varied amount of traffic you have to consider burst levels. Look at the QoS options you have with AT&T and what configuration settings on the Fortigate apply to traffic management and QoS.

You should consider at least Best Effort, Sensitive and Undesired traffic classifications. By filtering out Undesired traffic you can save bandwidth for real traffic, and not waste it on junk. You don't mention any network switches in your post, but you can also use those to do some traffic management. Again, check the configuration options.

I would also look into a network monitoring tool. It is somewhat reaction based but if you have alerts setup then you can find the troubled connection and delete it.

  • Thanks Yuli. The question becomes what "rule" would you write for Best Effort, Sensitive, and Undesired traffic? In other words, am I putting website and IP addresses in each of these lists? I can't imagine this is practical or scalable. As for switches, they are all "dumb" switches, but the same issue would apply if they were smart - how would you create definitions for each of the three categories? – globalSchmidt Nov 5 '17 at 19:27
  • @globalSchmidt, that is going to depend on your network, and what you need. The IP packet headers have a field for classification, and you mark the packets based on the criteria you decide. It can be by many different things (source or destination address, layer-4 protocol and port number, VLAN, etc.). There are entire books about QoS, which is a topic too big to properly discuss on this site. We can answer specific questions, but we can't give you a full tutorial on QoS. This is not a discussion site, but you could ask for a discussion on Network Engineering Chat. – Ron Maupin Nov 5 '17 at 19:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.