Linux and the Next Generation Internet
Our Diffserv implementation is relatively simple, but highlights many of the strengths and flexibilities of Linux, which we believe are especially important in the era of Internet-centric computing. To make this a more complete description of the several technologies related to “differentiated services”, we include some background material on the purpose and structure of Diffserv as well as highlights of other, more complex implementations of Diffserv environments which have benefitted from the sophistication of the Linux kernel.
Although our implementation of a Diffserv environment is fairly straightforward, we feel it's also interesting for these reasons:
We use an approach that allows reconfiguration of the entire network instantaneously and on-demand from a “network management workstation”. This was a key component of our environment, because one of our main goals was to demonstrate concisely, for a non-technical audience, using real-time applications, the “before-after” effects of a Diffserv-enabled network.
We developed this environment supported, in part, by one of the major Regional Bell Operating Companies (RBOCs) and by the National Science Foundation through a “Research Experiences for Undergraduates” (REU) supplement to an existing NSF grant. As such, the system configurations, software and most of the architecture was developed primarily by undergraduate engineering students at our university.
Our demonstration environment has been used for live, hands-on demonstrations at two large regional meetings: the Southeastern Universities Research Association (SURA) Applications Workshop (Sept. 1999) and the Bellsouth Science & Technology Innovations Showcase (Oct. 1999).
The key to “service differentiation” (or Quality of Service, QoS) in the Internet is the way routers handle (or can be easily modified to handle) multiple classes of traffic with various requirements for transport. The term “Diffserv” refers to an approach for implementing such capabilities which is being defined (through the usual method of constructing Internet standards) to be broadly compatible with the scope and flavor of the global Internet (see Resources 1).
The architecture of Diffserv can be viewed in terms of relatively simple functional units in the Internet's “forwarding nodes” (routers) (see Resources 2). The simplicity of Diffserv is important because, in theory, it has the potential to provide coarse differentiation between types of Internet traffic without requiring a fundamental change to the current configuration of the Internet.
One of the functional units described by Diffserv is a set of “per-hop behaviors” (PHBs). The idea behind PHBs is to let each router easily and quickly classify packets into different types of output queues based on a “tag” embedded in the packet header. Square tags go in “square” queues. Round tags go in “round” queues. Packets in the “square” queue get treated differently than packets in the “round” queue.
The scheme works in much the same way airline passengers are allowed to check bags or board the plane: “first class” goes first, “coach class” is next, and “standby” is last if there's enough room. There are also other functional units in Diffserv which are often called packet classification and traffic conditioning. In keeping with the airline analogy, packet classification is akin to the act of purchasing a type of ticket (or having one assigned to you, based on some rules) and traffic conditioning is like the disturbances (e.g., bumping and rerouting) experienced by a group of passengers when a flight is canceled or delayed. For our demonstration environment, we focus primarily on the PHBs and differences between particular classifications of traffic when the network is congested. To put it another way, we essentially ask the following questions: “Is first class really better than coach?” and “How can I tell?”
In Diffserv, the “first class” designation is called expedited forwarding (EF) (see Resources 3). The idea of EF is to simulate a “virtual leased line” by ensuring minimal queuing of packets within each router along the transport path. As such, the EF class hopes to provide guarantees on delay and jitter, which are important for isochronous data streams (i.e., video and audio). This is one of Diffserv's weak points, in our opinion. Due to an explicitly designed inability to distinguish between individual traffic streams, the aggregate EF flow receives the desired treatment. There can be no “hard promises” made to individual flows unless there are very few EF flows. This result has been noted with some chagrin in many publications (see Resources 4). The effect of EF classification is the presence of high amounts of jitter between subsequent packets in individual streams. As a result of the stated goals and the architecture of Diffserv, the only way to minimize these effects is to practice “gross overprovisioning”, where only a small percentage of the available bandwidth is made available to the EF class, and only a few EF streams are allowed. In the airline analogy, the number of first-class passengers on any flight would have to be limited strictly to a tiny proportion of the available seats. Otherwise, the flight attendants wouldn't be able to guarantee good service.
The “coach class” designation in Diffserv is called assured forwarding (AF) (see Resources 5) and is a bit more complicated than EF. The complication of AF is primarily due to the fact that there are four different classes of AF, and each class has three subtypes. The difference between AF classes is related to different levels of “forwarding assurances”. The difference between subtypes in each AF class is related to different levels of “drop precedence” or relative importance within the class (i.e., low, medium, high).
The relationship between “class” and “drop precedence” is subtle. Each class is allocated resources (such as buffer space, bandwidth and so on) at each forwarding node (router). These resources comprise a level of “assurance” that packets from each class will be forwarded as desired. Transmissions can exceed these resources at their own peril, described by the “drop precedence”. So, within the AF designation, forwarding depends on the relationships between the instantaneous traffic load at a router, the “available” resources compared to the “desired” resources and the drop precedence of each packet.
The “standby class” designation in Diffserv is the well-known best effort (BE) behavior of the current Internet. So, coarse differentiation between service levels is made by classifying packets as BE (poor), AF (better with conditions) or EF (best).
As a result of the functional unit architecture of Diffserv, and in an effort to push per-stream complexity to the edge of the network, there are actually at least two different types of routing/forwarding nodes in a Diffserv domain. According to the Diffserv specification, “edge” routers use a (possibly complex) set of rules to insert tags into the header of each IP packet. These tags are called “Diffserv Code Points” or DSCP (see Resources 6). Once the packets have been tagged and admitted into the interior of the Diffserv domain, “core” routers simply have to examine each packet's DSCP and assign it to the corresponding output queue to be forwarded on to the next node. With proper network architecture, each packet should be able to consume the forwarding resources it needs and is entitled to as a result of its “tag”.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide