Queuing is what happens when traffic bursts beyond the physical capabilities of the tx of an interface. So if you take a burst of traffic and you have a T1, queuing may hold back some traffic. With a T1, the default is to do a fair-queue. In other words, a fair use of queuing. This means that different sessions get their own little different queues. Since a lot of our traffic is TCP and tcp drops and delays slow down a session, this allows say a telnet session to get a fair shake when it is combined with a ftp session.
When we turn fair-queue off, the there is a fixed queue for everything. Conversations with more bandwidth usage can consume more than there fair share of bandwidth. Things are sort of statistically equal as far as the drop is concerned. However when you overlay this equality into a protocol like TCP, unequality happens when the conversation characteristics are different.
So why do we disable? Usueally because it works easily. Think about the fair-queue configuration. It basically creates mini queues. So the question is how many? What happens when we have a new conversation, but all of the queues are being used? The answer is that the number of queues is configurable. When the queues are all in use, new sessions are dropped. Disabling it (no fair-queue) is a easy way to disable this behavior and give a per-packet fair access to the queue. Not necessarily the best solution because then the telnet session doesn't have equal access to bandwidth. But it is better than new conversations being dropped.
Can you clarify a bit for me. You say that that disabling fair-que would be better than new conversations being dropped.
I agree, but if the FIFO que fills upp the same will happen.
So the question is whats the difference, except that we dont have the fair bw assigment.
Assume transaction one uses queue one and transaction n uses queue n. Now queue one might be at its max capacity so data for this transaction will be dropped (it is a bit more complex but ignore for this example). Queue two might be empty so transaction two can go into queue two. It might be low data such as telnet. The queue are assigned and eventually we run out of queues. Queue one is 100% full Queue two is 10% full so there is space in the router buffers.
With no fair queue then queue one is the only queue and has all the buffer space so theoretically a FTP could hog the queue but after the first drop the TCP window would change to slow it down.
Now in reality no network designer would want queuing because the users would complain and also queue service is based on the IP priority. Furthermore I talked about 100% but the algorithms jump in at lower percentages. You can manual assign by ACL to queues.
If you do have a TCP session hogging the circuit then you can police it.
If you are shifting data at very high speed then your buffers would quickly fill up once the line started to get above 60% so generally you do not see much queuing nowadays.
You seem to be talking about cbwfq/llq and wred.
Im still not sure how that would apply to fair queue on default traffic and turning it off.
The question still is why we would want to turn it off and why that would be an improvement. Ok so there might be some unused queue space with wfq, but by turning it off it seems that we risk the ftp traffic(example) filling up the queue anyways with the added downside to the other flows.
I was hoping that Paul (or someone else) might have some RL example where turning of the fair queing on an interface might be as good idea. Since my point being that the single flow(queue) will probably fill upp anyway and we end up just loosing the "fairness" of it.
Edit: I guess it might come down to there being no practical reason for turning it off, and that the option is there simply due to legacy.
With FIFO, yes packets are dropped when the queue is full. These will be dropped based on when they would otherwise be queued. The affected conversations should be sort of random based on this fact. This causes tcp to slow down and eventually it is sort of equally unfair (if you follow that). All sessions will slow down. With a wfq without adequate queues, new queues cannot be created for new sessions. Therefore all packets are dropped for the new session. I'm not advocating FIFO over wfq. We just need to understand these things and configure to meet the needs as closely as possible.
It sure sounds like a lot of thought process goes into deciding whether fair queuing should be done or not. Is there any quick rule of what should be used if we do not have time to do a detail analyse on the network?
Yes, if you are doing QoS on your serial links then you MUST use queuing. Cannot have QoS without queuing. If you have a lot of high data rate sessions or other bandwidth hungry applications you want to use queuing and QoS.
Otherwise if you used FIFO (no fair-queue) on the serial interface with these types of bandwidth hungry applications they will consume all the bandwidth and starve others. With FIFO, think of it as a single line we all must wait in to buy U2 tickets, whereas queuing allows multiple lines to the ticket counter.
Low-speed links default to WFQ
high-speed links default to FIFO
The reason behind FIFO on high-speed links such as DS3, OC3, FE, GE is that the link "should" have adaquate bandwidth available and congestion "should" be minimal in most cases.