The QoS tools

Previous

2.4. The QoS tools

Last section we talked that we have to locate some guards on every outside door of our domain to control flows flowing out and flowing into, being our main goal to protect it and its networks against misbehaving and/or out of agreement traffic. The question now is: How? Where? Using what?

It has been proved, and it is at least less than obvious, that the best place to control flows is at routers. Other component of the network (hosts, switches, servers, media, etc.) could be used, and in fact are used, but just the routers offer the required characteristics for implementing packet, and indeed, flow control.

Network experts Sally Floyd and Van Jacobson wrote in their paper "Random Early Detection Gateways for Congestion Avoidance" in 1993: "In the absence of explicit feedback from the gateway, transport-layer protocols could infer congestion from the estimated bottleneck service time, from changes in throughput, from changes in end-to-end delay, as well as from packet drops or other method. Nevertheless, the view of an individual connection is limited by the timescale of the connection, the traffic pattern of the connection, the lack of knowledge of the number of congested gateways, the possibilities of routing changes, as well as by other difficulties in distinguishing propagation delay from persistant queueing delay. The most effective detection of congestion can occur in the gateway itself. The gateway can reliably distinguish between propagation delay and persistant queueing delay. Only the gateway has a unified view of the queueing behavior over time; the perspective of individual connections is limited by the packet arrival patterns for those connections. In addition, a gateway is shared by many active connections, with a wide range of roundtrip times, tolerance of delay, throughput requirements, etc.; decisions about the duration and magnitude of transient congestion to be allowed at the gateway are best made by the gateway itself ".

Their arguments are overwhelmings. Hosts and servers are in fact end or individual connections and because of this their perspective of the network behavior is highly limited. Switches could help and some of these devices include mechanisms to control, shape or at least detect and inform about misbehaving flows. But switch's view of the network behavior is also limited because it is confined to its own link-layer space (network segment) and because it lacks from network-layer information knowledge (network addressing).

Reading from Floyd & Jacobson with care, observe that they insist in the gateway (router) queueing behavior. Let's talk a little about routers to understand this better. Routers are simply forwarding mechanisms of traffic. Flows are received from one of the interfaces and forwarded to one of the other interfaces. As soon as is possible, these flows are respected when traveling through the router. They are just forwarded ASAP. Of course, for doing this, routers has to snoop in the destination address of each packet to select the best route to take, and following this, select also the next forwarding interface. For implementing this process the router uses its routing knowledge based on static routes, or better yet, running a dynamic routing protocol like RIP, OSPF, BGP and others.

But this process, apparently simple, in fact it isn't. Flows are like rivers. Sometimes the running is weak, the river seems a thread that almost doesn't reach the sea; but sometimes the running is strong, subjugating, and it could destroy everything that obstruct its way. To deal with all these changing behaviors and putting under control the river you need to build dams, where in fact you are not doing more that enqueueing the water. And these dams have to be always prepared, independently of being the running weak or strong.

Same way, routers have to enqueue flow packets before forwarding them. When throughputs are weak the forwarding process is very fast and queues are almost empty. But when flows are bursty, the flow packets have to be enqueued and routers will try to make their job as better as possible, endeavoing to forward them ASAP. The queues act as containment buffers to deal with bursty flows and trying to avoid, when it is possible, to drop packets.

Nevertheless, as soon as rivers overflow, router queues do. We are then in presence of a congestion environment where routers have no more choice that dropping packets. And just here problems begin. Protocols are designed to be as conservative as possible in relation to packet survival. When packets need to be dropped, really worst problems, like global synchronization (all TCP flows starve at the same time because simultaneous fire of congestion avoidance mechanism bring the network utilization factor to almost zero - our network is idle; practically self shutdown) or uncontrolled oscillations (some TCP flows going up and some going down trying to find a throughput point of equilibrium) and, of course, misbehaving applications and angry users begin to cover the scene.

But, it's logical to ask, what or who, is/are responsible for these overflows? It's really a very difficult question to answer. Internet grows like grass. Everyday, and always, there are over here and over there new people interested in having an Internet connection and this is really a very nice wish. Also, current users are depending more and more from having, always available, an Internet connection to be used as much as everyone, everyday. Problem perhaps begin, or has its seed, when ISPs oversell their connections, or being more condescending, underestimate the rate of connection of their users. This little seed, propagates and grows very fast, making network congestion problems a common behavior to deal with.

But now we know where the battle is going to be given. Just in the router queues. It brings that a good understanding of router queue behavior and configuration could help us a lot to be better prepared to deal with all these congestion problems and their devasting consequences. Don't forget that you, as an ISP, are the seed where all problems begin, and to start correcting this, a good place to try is by putting your own users and customers under control.

Previous

Content

Next