Linux Teleconferencing: Improving the Wireless Network
A stated goal of the Third Generation cellular standards bodies (3G) is for the wireless network to function as a seamless extension to the Internet and other IP-based packet network services. The brunt of the ground-breaking work we still await has been passed from companies to standards bodies to the Internet Engineering Task Force (IETF). IP transparency extends a plethora of services to the mobile devices already available to those with a wire line to the Internet, as well as simplicity and ease of adding new and more creative services explicitly designed to enhance wireless experience. An obvious result is an increase in the demand for wireless minutes by customers of the 3G carrier members.
The bandwidth available for broadband data transmission is both restricted and costly. Licenses for the frequency spectrum needed to support 3G services have been auctioned to network operators in the UK for $36 billion. More recently the Federal Communications Commission (FCC) raised a net $17 billion in a similar auction to US-based operators. This prompts carriers to improve the efficiency with which they employ the spectrum. The use of IP as a transport mechanism for voice (e.g., VoIP) requires the wireless network to carry real-time multimedia, even as it struggles to do non-real-time multimedia. For example, a full rate voice encoder like the G721.1 used by GSM-type networks generates 30ms (milliseconds) of payload, straddled with 40 bytes of a combined IP, UDP and real-time protocol (RTP) header as prescribed in the H.323 International Telecommunications Union (ITU) protocol for the delivery of multimedia. The 30ms of speech payload typically translates to 20 bytes, thereby giving us an efficiency of only 33%.
Header compression algorithms proposed to the IETF reduce the header down to one byte in steady state but have varying degrees of hobbling complexity. The header compression algorithm is required to present both bit-exact payload and an encapsulating IP protocol header to the mobile device. This is referred to as loss-less compression.
The benefits presented by header compression prove to be an imperative measure in increasing the spectral efficiency of multimedia communications, particularly since CRTP, proposed in the late 1990s by Cisco, is deemed insufficient, or not robust enough, by the involved steering committees of the IETF, as well as the Third Generation Partnership Project (3GPP).
The details of which header compression algorithm the IETF will choose have not been fully determined. Nonetheless, the requirements have been hammered out and are summarized in Table 1. In fact, the current proposals meet many of the requirements but are peppered with intellectual property rights—something that defeats the objective of the IETF. A second round of proposals are under consideration so that different methodologies may be solicited. The current algorithms exploit the nature of the IP/UDP/RTP streams. Tables 3, 4 and 5 classify the nature of the header field for each protocol IP, UDP and RTP respectively. Table 2 defines the classifications.
The essences of these algorithms are the strategies borne from these classifications. They are “never send”, “communicate at least once”, “communicate at least once or update”, “communicate update and/or refresh frequently”, “guarantee continuous robustness”, “communicate as is in all packets and establish” and “be prepared to update delta”.
Telecommunications companies that have pursued this approach to compress packet headers range from Nokia, Matsushita and Cisco to, most notably, Ericsson, for their heavyweight effort. The full details of their proposed algorithm have been submitted in IETF draft form and can be found at http://www.dmn.tzi.org.org/ietf/rohc/.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Technical Support Rep
- Senior Perl Developer
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- Weechat, Irssi's Little Brother
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?