A flow consists of all the packets about which the following are true:
•
All packets use the same transport layer protocol (for instance, UDP or TCP).•
All packets have the same source IP address.•
All packets have the same source port number.•
All packets have the same destination IP address.•
All packets have the same destination port number.The slightly different, but just as exact definition, is that a flow consists of the packets between two IP sockets. For instance, a web browser on a PC, connecting to a server, creates a flow.
(Actually, in the case of HTTP, it may create multiple TCP connections, which would actually be multiple flows.) Regardless, consider Figure 2-9. In this network, one flow exists from Hannah to Server1’s web server.
Figure 2-9 GOCS Approach to QoS for a Single Flow
R1
IP
R2 R3
IP
SW1 Hannah
201
s0 s0 s1 T1 s0
FA0
SW2
301
Server 1
-Classify into Flows
-Apply Other QoS Tools, per Flow -Performed at Each Router
Single Flow: Hannah’s Browser to Server1 Web Server
The single flow shown in the figure consists of the packets sent by Hannah to Server1. Note that flows are unidirectional—in effect, two flows, one in each direction, would exist. To reduce the complexity, the samples in this section show flows going left to right only.
Flow-based QoS tools behave like the logic shown in the figure. Some QoS tools recognize flows and treat packets in one flow differently than another flow. So, common sense may imply that the QoS tools must first identify the packets that belong to this single flow, and then take some QoS action—such as queuing, LFI, shaping, and so on—for the packets in that flow. The tools may be applied for packets entering an interface, and other QoS tools may be applied for packets exiting an interface. Some tools may even be applied on the LAN switches. Some QoS tools may be applied in the Frame Relay cloud—but those are not typically under your control.
Real networks will have a widely varying number of flows, but the general ideas behind flow-based QoS tools do not change when more flows exist. Take a look at Figure 2-10, which shows a pretty small network with only four flows at this point.
Figure 2-10 GOCS Approach to QoS for Multiple Flows
R1 R2 R3
IP
SW1 Hannah
Vinnie
201
s0 s0 s1 T1 s0
FA0
SW2
301
Server 1 Class. (Flow-Based)
?
Dropped
Queueing (Flow-Based)
Drop Policy
Same General Logic as R2 Same General
Logic as R2
Flow1: Hannah’s Browser1 to Server1 Web Server Flow2: Hannah’s FTP Client to Server1 FTP Server Flow3: Vinnie’s Browser1 to Server1 Web Server Flow4: Vinnie’s Browser2 to Server1 Web Server Example with 4 Flows:
This figure shows four flows. Even though Vinnie sends all packets for both flows to Server1, they are in two different flows, because each of the two browser windows would open separate TCP connections, with different source TCP port numbers. (Note: HTTP 1.1 could cause mul-tiple connections to be opened; FTP uses a control and data connection, which would result in two flows.) However, assume that only four flows exist at this point.
How does the GOCS model with flow-based tools change with multiple flows? Well, not much.
Each flow must be identified, based on its unique source/destination address/port values. The QoS actions at each router may be different for each flow—for instance, maybe FTP just gets leftover bandwidth, or maybe Hannah gets better treatment for her web flow than does Vinnie.
The reasons and rationale behind deciding what traffic gets what QoS treatment will change from network to network, but the basic process works the same:
•
Identify each packet, determining which flow it belongs to.•
Apply some QoS action to the packets in each flow.•
The QoS actions on a single router may be different for each flow.•
The QoS actions among all routers may be different for each flow.Flow-based QoS tools provide some advantages and some disadvantages. Because each sepa-rate flow is identified, the QoS tools can literally provide different levels of service to every flow. A single queue could be used for each flow, for instance, giving each a different reserved bandwidth. With a large number of flows, however, the overhead associated with keeping state information about each flow can be a lot of work. Imagine a router with 1000, or even 10,000, concurrent flows, which would not be surprising in the Internet—and then imagine the overhead in trying to perform queuing with 1000 or 10,000 queues! So, flow-based QoS tools provide a great deal of granularity, but they do not scale as well as some other QoS tools that do not con-sider flows (particularly with very large networks or the Internet).
Engineers gain another advantage and disadvantage when configuring flow-based QoS tools.
Suppose that your job is to explicitly configure the routers in Figure 2-10 as to which source and destination IP addresses and ports to use to find each flow. And instead of 4 flows, there are 1000 concurrent flows. Over the course of a day, there may be hundreds of thousands of flows.
Your job is to find the details that make each flow unique and configure it! Well, that would be rather ridiculous, a lot of work, and mostly impractical. Therefore, flow-based tools typically require no configuration to match and classify packets into a flow. However, some configuration control is lost.
The following list summarizes the key points about flow-based QoS tools: