Engineering Internet QoS

Engineering Internet QoS

For a listing of recent titles in the Artech House Telecommunications Library, turn to the back of this book.

Engineering Internet QoS Sanjay Jha Mahbub Hassan

Artech House Boston • London www.artechhouse.com

Library of Congress Cataloging-in-Publication Data Jha, Sanjay. Engineering Internet QoS / Sanjay Jha, Mahbub Hassan. p. cm. — (Artech House telecommunications library) Includes bibliographical references and index. ISBN 1-58053-341-8 (alk. paper) 1. Internet—Evaluation. 2. Telecommunications—Traffic management. 3. Quality control. I. Hassan, Mahbub. II. Title. III. Series. TK5105.875.I57 J53 2002 004.6—dc21

2002074494

British Library Cataloguing in Publication Data Jha, Sanjay Engineering Internet QoS. — (Artech House telecommunications library) 1. Computer engineering 2. Internet 3. Computer networks– Quality control I. Title II. Hassan, Mahbub 621.3'981 ISBN 1-58053-341-8 Cover design by Gary Ragaglia

© 2002 ARTECH HOUSE, INC. 685 Canton Street Norwood, MA 02062 All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. International Standard Book Number: 1-58053-341-8 Library of Congress Catalog Card Number: 2002074494 10 9 8 7 6 5 4 3 2 1

v

To my father, Krishna, my wife, Manju, and my pets, Kookaburra (Maansi) and Possum (Pranay). Sanjay Jha To my son, Aaron. Mahbub Hassan

vi

Contents Preface

xv

Chapter 1 Introduction 1.1 QoS Framework 1.2 Video-Conferencing System 1.3 Overview of Audio-Video Compression Techniques 1.3.1 Video-Compression Standards 1.3.2 Audio-Compression 1.4 End-System Considerations 1.5 Operating-System Approach 1.6 Overview of Networking and Media Technologies 1.7 End-to-End QoS in the Internet 1.8 Supporting QoS in Best-Effort Networks 1.9 Application-Level Adaptation 1.9.1 Montgomery’s Destination Wait Method 1.9.2 Adaptive Audio Playout 1.9.3 Feedback Control Mechanism 1.9.4 Forward Error Correction 1.9.5 Interleaving 1.9.6 Repair at Receiver 1.10 Real-Time Protocol 1.11 Real-Time Control Protocol 1.11.1 Interarrival Jitter Calculation 1.11.2 Example: Audio Transmission in the Internet 1.12 Summary

1 1 5 6 6 9 9 10 11 13 14 16 16 18 19 19 20 20 20 22 24 24 26

vii

viii

Contents

1.13 Review Questions

26

Chapter 2 QoS Fundamentals 2.1 Traffic Description 2.1.1 Types of Traffic Sources 2.1.2 Traffic Parameters 2.2 QoS Specification and Contract 2.3 QoS Signaling 2.4 Packet Classification 2.5 Resource Reservation 2.6 Admission Control 2.7 Traffic Policing 2.7.1 Requirements for Traffic Policing 2.7.2 Policing Parameters 2.7.3 Policing Algorithms 2.8 Traffic Shaping 2.9 Queuing and Scheduling 2.10 Congestion Control and Buffer Management 2.11 Research Directions 2.12 Summary 2.13 Review Questions

31 31 31 32 34 34 34 35 35 36 36 37 37 42 43 44 44 45 45

Chapter 3 Scheduling for QoS Management 3.1 Scheduling Goals 3.2 Scheduling Techniques 3.2.1 First Come First Serve 3.2.2 Priority Queuing 3.2.3 Generalized Processor Sharing 3.2.4 Round Robin 3.2.5 Weighted Round Robin 3.2.6 Deficit Round Robin 3.2.7 Weighted Fair Queuing 3.2.8 Virtual Clock 3.3 Class-Based Queuing 3.4 Implementation Status 3.5 Research Directions in Scheduling 3.6 Summary 3.7 Review Questions 3.8 Implementation Project

49 49 52 52 53 54 56 57 58 60 66 67 69 71 73 74 74

Contents

ix

Chapter 4 TCP/IP and Queue Management 4.1 Internet Protocol 4.1.1 Datagram Forwarding 4.1.2 Unreliable Delivery of Datagrams 4.1.3 Datagram Format 4.2 User Datagram Protocol 4.3 TCP Basics 4.4 TCP Segment Format 4.5 TCP Three-Way Handshake 4.6 TCP Acknowledgment 4.7 Flow Control 4.8 Congestion Control 4.8.1 Packet Loss Detection 4.8.2 Retransmission Timer 4.8.3 RTT Estimation 4.8.4 Slow Start 4.8.5 AIMD 4.8.6 TCP Tahoe/Reno/Vegas 4.9 Queue Management 4.9.1 Explicit Congestion Notification 4.9.2 Packet Drop Schemes 4.9.3 Global Synchronization Problem 4.9.4 Random Early Detection Scheme 4.9.5 Weighted Random Early Detection 4.9.6 RED with In/Out 4.9.7 Problems with RED 4.10 Research Directions 4.10.1 Blue 4.10.2 Related Work 4.11 Summary 4.12 Review Questions

77 77 78 78 78 81 82 82 85 86 86 88 88 89 89 90 90 92 93 93 94 95 95 98 98 99 100 100 101 102 102

Chapter 5 Integrated Services Packet Network 5.1 Intserv Aim 5.2 Application Classification 5.2.1 Elastic Applications 5.2.2 Tolerant Real-Time Applications 5.2.3 Intolerant Real-Time Applications

107 108 108 108 109 109

x

Contents

5.3

5.4 5.5 5.6 5.7 5.8

5.9

5.10 5.11 5.12 5.13

Intserv Service Classes 5.3.1 Controlled Load Service Class 5.3.2 Guaranteed Service Class Flow Definition Signaling/Flow Setup Routing Protocol Independence Reservation Specs IS-Capable Router Components 5.8.1 Admission Control 5.8.2 Policing and Shaping 5.8.3 Packet Classifier 5.8.4 Packet Scheduler 5.8.5 Packet Processing 5.8.6 Traffic Control Implementation LAN QoS and Intserv 5.9.1 QoS Problem in LAN 5.9.2 IEEE Solution for LAN QoS 5.9.3 Mapping of Intserv QoS to LAN QoS Intserv Problems Research Directions Summary Review Questions

Chapter 6 Resource Reservation Protocol 6.1 RSVP Features 6.1.1 Simplex Protocol 6.1.2 Receiver-Oriented Approach 6.1.3 Routing-Protocol Independent 6.1.4 Reservation Setup 6.1.5 Soft State Refresh 6.2 Reservation Merger 6.3 Reservation Styles 6.3.1 Wildcard Filter 6.3.2 Shared Explicit 6.3.3 Fixed Filter 6.3.4 RSVP/ns Simulation 6.4 RSVP Messages 6.4.1 PATH Messages

109 110 110 111 111 112 113 116 116 117 117 118 118 118 120 120 120 124 125 126 128 128 133 133 133 134 134 134 135 135 137 137 138 139 141 143 144

Contents

6.4.2 RESV Messages 6.4.3 Other RSVP Messages 6.4.4 Message Processing 6.5 RSVP Message Format 6.5.1 Session Objects 6.5.2 TSpec Object 6.5.3 AdSpec Object Class 6.5.4 AdSpec Functional Block 6.5.5 Other RSVP Objects 6.5.6 PATH Message Format 6.5.7 RESV Message Format 6.5.8 Controlled Load Flow Specification 6.5.9 Guaranteed Load Flow Specification 6.6 RSVP APIs 6.7 RSVP Problems 6.8 Other Resource Reservation Protocols 6.9 RSVP Extensions 6.9.1 Improvement-Related Extensions 6.9.2 Subnet Bandwidth Manager 6.9.3 New Application-Related Extensions 6.10 Summary 6.11 Review Questions 6.12 Implementation Project Chapter 7 IP Differentiated Services Network 7.1 Diffserv Architecture 7.1.1 Per-Hop Behavior 7.1.2 Per-Domain Behavior 7.1.3 Existing IPv4 ToS 7.1.4 Diffserv Codepoint 7.1.5 PHB Encoding 7.2 Diffserv Router 7.3 Premium Service 7.4 Experimental Evaluation of Premium Service Under Linux 7.5 Assured Service 7.6 Open Issues with Diffserv 7.7 Diffserv Research Directions 7.8 Summary

xi

145 145 146 147 148 148 149 150 151 152 153 154 154 155 157 159 160 161 161 163 164 164 165 169 169 171 171 172 172 173 175 178 179 184 187 187 190

xii

Contents

7.9 Review Questions 7.10 Implementation Project

190 191

Chapter 8 Policy-Based QoS Management 8.1 Definition of Terminologies 8.2 Bandwidth Broker 8.3 Policy Framework 8.3.1 Policy Protocols 8.3.2 Policy Rules and Representations 8.3.3 Policy Database 8.4 Policy and RSVP 8.5 Bandwidth Broker Implementation 8.6 Internet2 and QBone 8.7 Research Directions 8.8 Summary 8.9 Review Questions

195 195 196 198 200 201 202 203 203 208 209 209 210

Chapter 9 ATM QoS 9.1 Why ATM Networks? 9.2 Protocol Architecture 9.3 Connections 9.3.1 Virtual Channel 9.3.2 Virtual Path 9.3.3 Permanent and Switched Virtual Circuits 9.4 Interfaces 9.5 Cell Formats 9.6 QoS Support 9.6.1 Traffic Contract 9.6.2 Traffic Descriptions 9.6.3 QoS Parameters 9.6.4 Service Classes 9.7 Adaptation Layers 9.8 IP-ATM Integration 9.8.1 ATM Deployment in IP Networks 9.8.2 Encapsulation of IP Datagrams into ATM Cells 9.9 IP-ATM QoS Mapping 9.9.1 Intserv over ATM 9.9.2 Diffserv over ATM 9.9.3 Performance Implications of QoS Mapping

213 213 214 215 216 216 216 217 218 220 220 221 222 222 224 227 227 228 232 233 233 235

Contents

9.10 9.11 9.12 9.13

9.9.4 MPLS Solution Research Directions Summary Further Reading Review Questions

xiii

235 236 236 237 237

Chapter 10Multiprotocol Label Switching 10.1 Proprietary Protocols 10.2 Motivation 10.3 MPLS Basics 10.4 Conventional IP Routing 10.5 MPLS Approach 10.5.1 Label Encoding 10.5.2 TTL Handling 10.5.3 MPLS Encapsulation 10.5.4 Label Processing 10.6 Label Distribution 10.6.1 Sample Network 10.6.2 Label Binding 10.6.3 Label Allocation 10.6.4 Label Switching 10.7 Hierarchical Routing 10.8 MPLS over ATM 10.9 Traffic Engineering Using MPLS 10.9.1 Constraint Routed LSP 10.9.2 Path Resource Reservation Protocols 10.9.3 Traffic Trunk 10.9.4 MPLS Experimental Results 10.9.5 No Trunking 10.9.6 Two Trunks Using LSPs 10.10MPLS and latest developments 10.10.1 Diffserv over MPLS 10.10.2 Generalized MPLS (GMPLS) 10.11Summary 10.12Review Questions

241 241 242 243 244 245 245 246 246 246 247 247 248 249 250 252 254 256 257 258 260 261 261 262 262 262 264 265 265

Chapter 11QoS in Mobile Wireless Networks 11.1 Mobile Applications 11.2 Mobile Wireless Networks

269 269 270

xiv

Contents

11.3

11.4

11.5

11.6 11.7 11.8

11.2.1 Wireless LAN 11.2.2 Bluetooth 11.2.3 Cellular Networks 11.2.4 Comparison of Wireless Networks Mobile Services over IP Networks 11.3.1 Mobile IP 11.3.2 Cellular IP Impact of Mobility on QoS 11.4.1 Effect of Wireless Links 11.4.2 Effect of Movement 11.4.3 Limitations of Portable Devices Managing QoS in Mobile Environments 11.5.1 Resource Reservation 11.5.2 Context-Aware Handoff 11.5.3 Application Adaptivity Research Directions Summary Review Questions

271 272 273 274 274 274 277 278 278 279 279 280 280 282 282 283 287 287

Chapter 12Future 12.1 Intserv over Diffserv 12.1.1 Motivation 12.1.2 Generic Framework for Intserv over Diffserv 12.1.3 Guaranteed Service over EF PHB 12.1.4 Controlled Load over AF PHB 12.2 QoS Routing 12.3 Resource Discovery and QoS 12.4 Virtual Private Network and QoS 12.5 Content Distribution Network and QoS 12.6 Web QoS 12.7 Billing and Charging for QoS 12.8 Final Words 12.9 Summary 12.10Review Questions

293 293 293 293 295 296 297 297 298 299 300 301 302 303 303

About the Authors

307

Index

309

Preface Engineering Internet QoS addresses the technical issues raised by the emergence of new types, classes, and qualities of the Internet services. The international research community has been working for the last decade on designing solutions to the QoS problems in the Internet. The Internet Engineering Task Force (IETF) has issued many standards recommending architectures and protocols to build a QoS support infrastructure for the IP networks. The volume and pace of this QoS research and development have demanded new textbooks on this topic. Although several books on QoS have been published in the last few years, currently no text exists that provides a single comprehensive source for the QoS concepts, architectures, and algorithms. Most books cover the latest developments in IETF without going into the depth of the fundamentals that is required to provide QoS. Readers are required to consult several reference books to gain an in-depth understanding of the fundamental concepts to build QoS in the Internet. This makes it difficult to adopt any of these books as a text for a course on QoS. We have written Engineering Internet QoS to provide a comprehensive source of knowledge in the field. We have attempted to provide sufficient depth for the major QoS concepts and architectures. Simulation results have been presented to help understand some of the difficult concepts. The book has several Linux/FreeBSD– based practical examples to illustrate how QoS testbeds can be set up for experimentation and future research.

xv

xvi

Engineering Internet QoS

ASSUMED KNOWLEDGE Readers would be required to have the basic knowledge of data communications and TCP/IP protocols, with some exposure to IP routing.

AUDIENCE The book is designed for use in a second course on networking with a prerequisite of introductory networking or data communications. The name of the course can be as specific as “QoS in the Internet.” The book can also be used in some existing networking courses. Some of the possible courses for which the book can be adopted include Advanced Computer Networks and High Performance Networks. Graduate students will find the sections on “research direction” useful for their literature survey in the respective fields. Professionals working as network engineers, telecommunication and network software developers, R&D managers, research scientists, and network administrators will also find this book valuable to understanding the QoS issues and how to implement, maintain, and deploy QoS technologies. QoS API and traffic control examples will help engineers learn how to configure a router/switch supporting QoS. Since this book is partly based on the industry short courses the authors developed, the book will be suitable for internal training in many telecommunication industries. The trainees will find the knowledge acquired useful in creating new products or setting new directions for their team.

ORGANIZATION 1. Introduction: We believe that it will be easier to understand the specific architectures once the readers have absorbed the fundamental issues and techniques. This chapter provides definition of the QoS problem and QoS parameters and answers why QoS is an important problem. This is followed by the issues in providing QoS in the Internet environment. Through an example, we discuss issues related to providing end-to-end QoS for real-time multimedia communications over the Internet. End system as well as network issues are discussed. The standard protocol real-time transport protocol (RTP) and RTCP are also discussed, with examples of how they provide features for supporting adaptive feedback as well as jitter calculation. Readers not familiar with the QoS area will find this chapter interesting.

Preface

xvii

2. QoS Fundamentals: In order to understand various architectures for QoS provisioning in the Internet, it is important to understand the fundamental algorithms/techniques behind these architectures. This chapter provides an overview of the fundamental issues such as traffic specification and negotiation, admission control, resource reservation, scheduling, and congestion control. A detailed treatment to shaping and policing has been provided in this chapter. Highly technical details of scheduling, congestion control, and buffer management as well as resource reservation are provided in later chapters. Readers familiar with these basic concepts may find the specialized chapters more useful. 3. Scheduling for QoS Management: Packet scheduling is an important building block for any QoS network. This chapter provides an in-depth treatment of this topic. A variety of schedulers including FCFS, priority round robin, fair queuing, and its variants are discussed in details with examples of how they could meet the delay and bandwith requirements of flows. There is an overview of several advanced schedulers, and current research issues are described. We recommend this chapter to both novice and advanced readers. 4. TCP/IP and Queue Management: This chapter provides a brief refresher on TCP and IP protocols. Another objective of this section is to provide readers with background on how the congestion control problem is currently solved in the best-effort Internet. Authors have included this material to minimize cross–referencing to other books where possible. Readers familiar with these concepts may skip this section. The later part of this chapter deals with queue management techniques used in best effort as well as QoS-capable networks. Algorithms, such as RED/RIO, wRED, and Blue are discussed in detail. An overview of current research issues relating to queue management is described in this chapter. 5. Integrated Services Packet Network: One of the earliest architectures for QoS support within IETF is the integrated services (Intserv) model. This chapter starts with classification and requirements of applications, followed by description of various components of the Intserv model. Components of an Intserv capable router are described in detail. QoS support issues in the LAN environment as well as Intserv mapping of LAN QoS are also covered in this chapter. 6. Resource Reservation Protocol: Although flow setup has been discussed briefly in the context of Intserv, a separate chapter has been dedicated to the

xviii

Engineering Internet QoS

resource reservation protocol (RSVP). This chapter covers details of RSVP protocol design and demonstrates its usefulness in the Intserv environment through examples and simulation. Resource reservation protocol is an active research area. This chapter will help researchers and implementors learn the issues involved in designing any new resource reservation protocol. An overview of various RSVP extensions and related research is also provided in this chapter. 7. IP Differentiated Services Network: This chapter describes the Diffserv architecture and its various elements. We also describe components of a Diffserv router. Premium and assured service are described in detail with experimental evaluation of premium service using Linux testbed. The chapter concludes with Diffserv problems and new research development such as perdomain behavior. 8. Policy–Based QoS Management: Policy-based QoS management is emerging as a strong research and development area for next generation Internet. We discuss resource allocation protocol (RAP) framework. Bandwidth broker is considered to be the oracle that has a global view of resources within a Diffserv domain. This chapter also describes the intra- and interdomain protocols used in the Internet along with the Internet2 and Qbone architectures. 9. ATM QoS: ATM network was designed to support QoS from the start. Currently many carriers have deployed ATM switches in their backbone network. This chapter provides an overview of ATM technology as well as the IP/ATM integration issues. This background is essential for understanding the next chapter on MPLS. However, readers familiar with ATM network may skip this chapter. 10. Multiprotocol Label Switching: Multiprotocol label switching has been a popular topic for developers and researchers in the QoS area. This chapter begins with the motivation behind developing this new technology. A detailed description of the MPLS protocol, label distribution protocol, and issues related to MPLS over ATM network is provided. Finally we discuss the traffic engineering issues, with some examples of traffic trunking in MPLS networks. 11. QoS in Mobile Wireless Networks: Mobile wireless technology has experienced the same level of growth as the Internet. A vast topic like this deserves a separate book. We start with discussion of applications and their QoS requirments in the wireless Internet. We also provide a high-level overview of

Preface

xix

measures currently being proposed to address the QoS issue in the wireless Internet. 12. Future: Besides the various architectures discussed in this book, several new architectures are evolving in the Internet. It is impossible to cover all these new developments in a single book. We start this chapter with a detailed discussion of Intserv over Diffserv followed by an overview of QoS routing, VPN and QoS, content distribution network, as well as billing and charging for QoS. Each of these sections provides a list of key references for further reading. Each chapter provides a section on either future research directions or latest developments in the area. Readers keen to explore the areas further will find these sections and references very useful. We have structured chapters in a way that readers absorb basic concepts before jumping into architectural issues. Each chapter is selfcontained. We have repeated some concepts briefly in a few chapters to make them self-contained, providing forward/backward reference for details. This facilitates readers to carry on with the current chapter without breaking their continuity.

ON-LINE SUPPORT On-line support material for each chapter and presentation foils (for adopters of the text only) will be available from the following URL: http://www.cse.unsw.edu.au/qosbook https://hhp.bvdep.com/artechhouse /Default.Asp?Frame=Book.Asp&Book=1-58053-341-8

ACKNOWLEDGMENTS First of all we would like to express our gratitude to the anyonymous reviewer for the extensive reviews of the chapters and the comments on the book’s organization. A number of other people helped with this book. Some part of this book came from our joint work with Professor Raj Jain from Ohio State University. Muneyb Minhazuddin from Avaya Communications provided helpful suggestions on Diffserv. Professor William Atwood from Concordia University provided suggestions

xx

Engineering Internet QoS

on various aspects of this book. Our graduate students William Lau, Jahan Hassan, Alfandika, and Monir Hossain, read some of the chapter drafts. Jim Wu provided graphics for the Diffserv chapter. Abdul Aziz Mustafa helped with the NS simulation setup. Matt Chalmers and Shaleeza Sohail provided references for billing and charging as well as policy-based management sections. Filip Rosenbaum provided experimental results for MPLS and helped with Linux TC examples. This book has been influenced by authors of books, articles, and RFCs provided in the refence list after each chapter. The MPLS chapter has been influenced by Bruce Davie’s MPLS tutorial in Globecom’98. We are indebted to our employer, the University of New South Wales, and our head of school, Professor Arun Sharma, for their flexibity and encouragement, which enabled us to write this book. We acknowledge Mark Walsh, Barbara Lovenvirth, Judi Stone, Jen Kelland, Susanne Schott and others at Artech House Publishers for their wonderful support. Geoff Oakley helped with Latex formatting. Finally, we extend our gratitude to our families for their continual support throughout the entire project. Sanjay Jha Mahbub Hassan July 2002

Chapter 1 Introduction There has been a dramatic increase in the processing power of workstations and bandwidth of high speed networks. This has given rise to new real-time applications such as multimedia. These applications have traffic characteristics and performance requirements that are quite different from existing data-oriented applications. Some examples of these applications are: desktop teleconference, multimedia mail and documents, remote surveillance, and video on demand. Applications have different quality of service (QoS) requirements. For example, video-on-demand applications can tolerate moderate end-to-end delay but require high throughput and very low error rate. In contrast, Internet telephony needs very low end-to-end latency but needs moderate throughput and a slightly higher error rate (than VoD) is acceptable. The Internet, in the past, has provided only best effort service with no predictable performance. The QoS term has been used primarily in the networking community to define a set of network performance characteristics such as delay, jitter, bit error rate, packet loss, and more. With new multimedia services over packet networks such as the Internet, the concept of QoS involves not only the network but also the end systems.

1.1 QoS FRAMEWORK The early 1990s saw a large number of frameworks being proposed for supporting QoS over the Internet [1, 2, 3, 4, 5]. With IETF’s efforts to come up with a standard framework such as Intserv and Diffserv, work by individual groups in proposing new architectures have slowed down. Figure 1.1 shows the abstracted view of

1

2

Engineering Internet QoS

common elements of these architectures to support end-to-end QoS consisting of user, application, and system levels adapted from Nahrstedt and Steinmetz [6]. At each of these levels QoS needs to be specified for the level below. The user specified QoS needs to be translated into layer specific parameters and then the application and system levels need to ensure that QoS expectations of the user are met.

User Perceptual QoS Application level Application QoS

System level (operating sytems and network) System QoS Device QoS

Multimedia devices

Figure 1.1

Network QoS

Network subsystem

QoS framework (Source: [6]).

Users of multimedia applications are the ultimate decision makers on what they perceive as a good quality of transmission. For example, the audio/visual synchronization parameter requires coordinating the timing of the two streams. The term lip synchronization applies to synchronizing audio with the movement of a person’s lips. If data is out of synchronization, human perception tends to

Introduction

3

Table 1.1 Network QoS Parameters Category

Parameters

Timeliness

Delay Response time Jitter Systems-level data rate Application-level data rate Transaction rate Mean time to failure (MTTF) Mean time to repair (MTTR) Mean time between failures (MTBF) Percentage of time available Packet loss rate Bit error rate

Bandwidth

Reliability

Source: [7]

identify the presentation as artificial, strange, and annoying. These user-perception parameters are required to be mapped to lower-level technology-based parameters. Application QoS parameters could include media quality, end-to-end delay requirements, inter/intra stream synchronization, and others derived from user’s QoS specifications. Application parameters are required to be mapped into system level QoS. System level QoS has two components. The device level QoS specifies timing and throughput requirements. Network level QoS could be parameters as defined in Table 1.1. A brief description of these parameters is provided below: Delay: Time it takes for a message to be transmitted; Response time: Round-trip time from request transmission to reply receipt; Jitter: Variation in delay or response time; Systems-level data rate: Bandwidth required or available, in bits or bytes per second; Application-level data rate: Bandwidth required or available, in applicationspecific units such as video frame rate; Transaction rate: Number of operations requested or processed per second;

4

Engineering Internet QoS

Table 1.2 Perceptual QoS Parameters Perceptual Parameter

System Parameter

Picture detail Picture color accuracy Video rate Video smoothness Audio quality Audio-video synchronization

Pixel resolution Maps-to-color information per pixel Maps-to-frame rate Maps-to-frame rate jitter Audio-sampling rate and number of bits Video and audio stream synchronized (e.g, lip-sync)

Source: [7]

Mean time to failure (MTTF): Normal operation time between failures. Mean time to repair (MTTR): Downtime from failure to restarting next operation; Mean time between failures (MTBF): MTBF = MTTF + MTTR ; Percentage of time available: MTTF/MTTF + MTTR. These parameters typically form part of the service level agreement (SLA) between a network service provider and a service user. For the Internet, it typically refers to availabilty of the access link to the service provider; Packet loss rate: Proportion of total packets that do not arrive as sent, e.g., lost because of congestion in the network; Bit error rate: Proportion of total data that does not arrive as sent because of errors in the network transmission system. For example, bit error rate increases if transmission speed is increased over the telephone line. QoS Translation As we have seen in Figure 1.1, QoS parameters need to be translated between levels. For example, application level QoS parameters, such as frame rate, size of video window, and quality need to be mapped to network layer QoS parameters, bandwidth, delay, etc. A description of some parameters related to user perception and their mapping to application/system parameters are presented in Table 1.2.

Introduction

5

The task of QoS translation is nontrivial. For example, an application may specify the video frame rate and frame size that gets mapped to the transmission data rate. If the network subsystem is unable to meet these requirements, a new adjusted data rate may result in either lower image quality or a reduced frame rate. This would require some renegotiation of parameters with the user. Many research papers have been published in this area [8, 9, 10]. Details of these works are beyond the scope of this book.

1.2 VIDEO-CONFERENCING SYSTEM We describe a video-conferencing system with a view toward understanding the various components of this system that are responsible for providing end-to-end quality of service. In a video-conferencing system, the video source, such as a camera converts analog signals to digital information via an analog-to-digital converter (ADC). The digital images then can be manipulated, stored, or transmitted in digital form. At the receiving end, the digital information must be transformed back into analog form via a digital-to-analog converter (DAC). Figure 1.2 shows the video data flow from the camera of the sender to the video display unit of the receiver. It shows analog video being digitized and placed in a frame buffer. This function is performed by special hardware cards called frame grabbers. These cards may also have the capability to compress the video in various formats. Alternatively, the compression can take place in a software encoder. Most of the time, the video data sent over the network is already compressed in order to save bandwidth. At the receiving end, decompression can take place either in hardware or software. All multimedia applications need to process and exchange large volumes of information. An uncompressed ten-minute video clip, for example, consumes 22 Gbytes of storage and its voice grade audio requires another 5 MBytes. An uncompressed National Television Standards Committee (NTSC) standard composite signal represents almost 2 MBytes of pixel data per second. This number is almost 20 times larger for high definition television [11]. There is a need to reduce the data to be processed or transmitted by end systems. Section 1.3 presents an overview of compression methods used for audio-video transmission. Section 1.4 considers the capabilities of end systems to process multimedia streams. The bandwidth requirement of video streams is very high. The network transferring the continuous media stream between two end systems may have limited bandwidth. It also may introduce variability in end-to-end delay. Section 1.5 provides a description of operating system issues. Section 1.6 looks at the characteristics of different networking

6

Engineering Internet QoS

Sender

Receiver

Analog video

Display

Digitized video in frame buffer

Digitized video in frame buffer

Video data in application buffer

Video data in application buffer

Video data in network buffer

Video data in network buffer

Network

Figure 1.2

Video data flow.

technologies available and their suitability for the task of transporting multimedia streams.

1.3 OVERVIEW OF AUDIO-VIDEO COMPRESSION TECHNIQUES The biggest challenge posed by digital video is the volume of data involved and how it bears on storage, transmission, throughput, and display. A video image of the size of 640 x 480 pixels with a resolution of 24 bits per pixel and a standard NTSC frame rate of 30 frames per second represents a little over 26 MB of data per second. At this rate, a 1 GB hard disk could store only about 38 seconds of video. On top of this, audio consumes more resources. 1.3.1 Video-Compression Standards The most promising solutions for integrating video and computers center on various compression technologies. Due to the massive amount of data involved and the need for a high compression ratio, most approaches are lossy in nature and take

Introduction

7

advantage of the artifacts of the human visual system. One prominent approach averages areas to take advantage of the human vision system’s lack of sensitivity to slight changes. Most of the compression methods are adaptive so they can be implemented to optimize for a given series of images [12]. The other area of interest is motion compression. In scenes that involve little action, significant data reduction can be achieved by saving only the pixels that change from frame to frame. Most video compression solutions combine various approaches such as these to yield optimum results. Figure 1.3 shows a tree diagram of existing standards based on [12]. MULTIMEDIA STANDARDS

P * 64

JPEG

MPEG

ITU−T

ISO

ISO

Image

Video

JPEG baseline

H.261 Motion Video H.263 Low Bit−Rate Visual Telephony

Video

Proprietary standards and others Video

MPEG−1 stored video

Intels’s Indeo and DVI

MPEG−2 HDTV (extension of MPEG−1)

Apple’s QuickTime Microsoft’s AVI

Video

Audio

MJPEG (motion JPEG)

MPEG−4 motion video Audio MPEG audio

G.711

Cell−B nv nvdct

(Layers 1,2,3)

G.722 G.728

Figure 1.3

Multimedia standards.

ITU-T Recommendation H.261 has been developed with the aim of video transmission at Kbps ( in range of 1 to 30). The possible applications of this standard include video phone and videoconferencing. Joint photographic experts group (JPEG) is a coding scheme for still images. The standard may be applied to various requirements such as image storage, facsimile, desktop publishing, medical imaging, electronic digital cameras, and so forth. This standard provides several coding modes, from basic to sophisticated, according to application fields. Motion video can also be achieved by transmitting, say, 30 still JPEG images per second.







8

Engineering Internet QoS

Table 1.3 Bandwidth Requirements for Video Encoding

Bandwidth

Resolution

Standard

H.261

64 Kbps–2 Mbps

M-JPEG

3–8 Mbps 15-25 Mbps 60–100 Mbps 1.2–3 Mbps 5–10 Mbps 20–40 Mbps 1–2 Mbps 4–5 Mbps 8–10 Mbps 20–30 Mbps

177x144 352x288 352x288 720x486 1920x1080 352x288 720x486 1920x1080 352x288 720x486 960x576 1920x1080

QCIF (conference) CIF (VHS quality) CIF (VHS quality) CCIR601 (PAL) HDTV CIF (VHS quality) CCIR601 (PAL) HDTV CIF (VHS quality) CCIR601 (PAL) EDT HDTV

MPEG-1

MPEG-2 (H.262)

This feature has been used in some video systems, which call it motion JPEG (MJPEG). The motion picture experts group (MPEG) is working on standards for motion video. MPEG-1 aims at achieving plausible video and audio recording and transmission at about 1.5 Mbps. Compact-disc and laser-disc players using the MPEG-1 audio-video decoders have already entered the market. MPEG-2 is an extension of the MPEG-1 standard for higher bit-rate applications, including telecommunications, broadcasting, and high-definition television (HDTV) services. MPEG-4 and H.263 are the proposed standards for very low bit-rate visual telephony ( 64 Kbps). Applications of these standards include video telephone, multipoint video-conferencing systems, audiovisual database access, and remote monitoring and control. Besides these standards there are proprietary standards such as Intel’s Indeo, Apple’s QuickTime, and Microsoft’s Audio Video Interleave (AVI). Table 1.3 summarizes the bandwidth required by a variety of these services. Here, we look at the bandwidth requirement for video applications. Depending upon the compression technique used, the bandwidth ranges from 64Kbps for H.261 to 5 to 30 Mbps for HDTV standards.



Introduction

9

Table 1.4 Bandwidth Requirements for Audio Coding Technique

Standard

Data Rate (Kbps)

PCM (pulse code modulation) 4-bit ADPCM (adaptive differential PCM) 2-bit ADPCM CELP (code-excited linear-predictive) Adaptive CELP Part of H.324

G.711 G.726 G.726 G.728 G.729 G.723.1

64 32 16 16 8 5.3 or 6.3

1.3.2 Audio-Compression Audio is formed by analog sine waves that tend to repeat for milliseconds at a time. This repetitive nature of audio signals makes it ideal for compression. Schemes such as linear predictive coding and adaptive differential pulse code modulation (ADPCM) can achieve 40 to 80% compression. ITU-T (formerly CCITT) is the main source of audio standards. A brief description of some standards and required data rates is provided in Table 1.4. Technical details of these audio and video compression techniques, products available in the market, and references to standards can be found in [12, 13].

1.4 END-SYSTEM CONSIDERATIONS In section 1.3, a range of compression/decompression standards was discussed. End systems require dynamic decoding of a multimedia stream before it can be presented to the user. The decoding and playback of a compressed multimedia stream require a very powerful central processing unit (CPU). Alternatively, special hardware such as the Intel i750B chip supporting DVI standard or digital signal processing (DSP) hardware is required. Processors such as Sun Microsystem’s SPARC, DEC’s Alpha, and Intel’s Pentium are very powerful. They can perform decompression and playback management in the CPU itself [12]. However, the speed of memory access is a bottleneck. Caches are used by CPUs to temporarily store commonly used code and data from slower memory. Video playback needs sufficient CPU time at regular intervals so that it can perform 30 repetitions (for the NTSC system) of the grab, decompress, and display

10

Engineering Internet QoS

sequence every second. Figure 1.4 shows the amount of compute time needed to decompress and display JPEG video frames from two different clips on a SunUltra1 workstation. It is evident that the compute time needed for each frame within a stream varies and also that the CPU requirements for two streams are different. It becomes hard to predict the CPU requirements for video streams.

Decompression Time

Decompression Time

35

40

35 30

30 Time (ms)

Time (ms)

25 25

20 20

15 15

10

10 0

10

20

30

40

50

60

70

80

90

100

0

Packet Sequence Number

(a) Lion King

Figure 1.4

10

20

30

40

50

60

70

80

90

100

Packet Sequence Number

(b) Song

Decompression time for JPEG.

1.5 OPERATING-SYSTEM APPROACH The processing requirements of multimedia applications are very dynamic. For example, video frames may be required to be played every 40 ms (25 fps), but processing requirements (compression/decompression) of each frame in the stream vary substantially. Most of the work to support real-time applications has been done for embedded real-time systems where application timing requirements are periodic and static. The majority of computers connected to the Internet and used for multimedia sessions run general-purpose operating systems such as UNIX or Microsoft Windows. Most multimedia applications are CPU bound and the scheduling scheme explained above lowers the priority of these applications continually over time. These time-sharing operating systems have unpredictable response times to generate, process, and display continuous media [14]. This may result in high levels of delay and jitter. In the absence of real-time support, event timings become more

Introduction

11

skewed as the workloads on the receiving systems increase [15]. To address this problem, some experiments have been performed running multimedia applications as high-priority threads. Mauthe and others have implemented these applications using high-priority threads on PS/2 workstations running OS/2 [16]. Neih et al. [17] studied the fixed priority real-time scheduler built into UNIX SVR4. They found several problems with this approach. With higher priority for video applications, Xserver will not display images in time. Several other researchers have attempted to modify operating system schedulers by increasing the number of preemption points in order to provide bounded dispatch latency [18, 19]. Lakshman [3] also conducted experiments with fixed priority scheduling. He used an audio player, a video player, and a Fast Fourier Transform (FFT) application and various I/O intensive tasks. Priorities of audio and video player were assigned so that they achieved the needed QoS. The experiments showed that when video has higher priority, the computer stops responding to keystrokes or mouse movements and the FFT application never gets a chance to run. He also used a scheme called priority capping. In this scheme, the UNIX scheduler doesn’t lower the priority of multimedia applications below a certain threshold. The results were similar to a fixed priority scheme.

1.6 OVERVIEW OF NETWORKING AND MEDIA TECHNOLOGIES The networking media is becoming faster. This applies to all forms of media. Consider copper cables. In early 1980s, Ethernet designers (IEEE 802.3 standards committee) had concluded that category 5 unshielded twisted pair (UTP-5) cannot support any more than 1 Mbps, and so the 1BASE-5 standard was designed for UTP. For higher speed, we needed coaxial cables. In 1999, the same UTP cable carried 1 Gbps over 4 pairs. This is a two orders of magnitude increase in 15 years. Moving on to fibers, fiber distributed data interface (FDDI) was designed in 1993. It allowed 100 Mbps over 2 km. In 1999, dense wavelength division multiplexing (DWDM) using 64 wavelengths of OC-192 (10 Gbps each) allowed 0.6 Tbps on a single fiber as well OC-768 (40 Gbps) was demonstrated using single wavelength. This represents a three orders of magnitude increase in the capacity in approximately 8 years. The wireless link speeds are also growing. The IEEE 802.11 standard that came out in 1998 was designed to run at 1 and 2 Mbps. They couldn’t match 10 Mbps wired Ethernet speeds then. However, just a year or two later, 11 Mbps wireless LAN products started appearing. Thus, we see that the media capacity is

12

Engineering Internet QoS

Table 1.5 Data Rate Supported by Networks Network Type

Bandwidth (Mbps)

Ethernet Fast Ethernet 100VG–ANYLAN Token Ring Wireless LANs Fiber distributed data interface (FDDI) Distributed queue dual bus (DQDB) Integrated services digital network (ISDN) Asynchronous transfer mode (ATM) Switched multimegabit data services Frame relay

10 100 100 4 to 16 1 to 11 100 45 to 140 64 to 2.048 155 to 622 1 to 34 2

increasing fast and this may lead some to argue that the QoS problem will be a shortlived one. Interestingly, the traffic on the networks is also growing exponentially. Barely a few years ago, the highest speed home connections were limited to 28.8 kpbs. Today many households have 10 Mbps cable modem connections. Asymmetric digital subscriber lines (ADSL) and very high-speed digital subscriber lines (VDSL) allow 6 to 27 Mbps access from home on the same phone wire, resulting in increased demands on the Internet. In the wide area networks, in the carrier market, bandwidth is still expensive— while in the local area networks, in the enterprise market, bandwidth is growing fast. New technology introduction in the LAN is controlled by the technology as well as affordability of each organization to procure and install these technologies in a short time frame. Rolling of new services in the WAN is controlled more by business considerations, where the network service providers do not accept a new technology simply based on its technical merits. There are several networking solutions currently used for transmission of data, voice, images, and video. These networks provide connectivity of various characteristics. Disparity occurs in data rate, medium access protocol (switched versus shared), maximum transfer unit (MTU), connection oriented versus connectionless, error rate, etc. Table 1.5 presents a range of networks and data rates supported by these networks. Details of these technologies can be found in [20].

Introduction

13

1.7 END-TO-END QoS IN THE INTERNET Comparisons of Tables 1.3 to 1.5 show that it is possible to meet the bandwidth requirement of multimedia services over a range of available networks. Connectionoriented networks such as ATM are capable of providing varying QoS negotiated by applications. However, the problem is more complicated for the Internet. Because the Internet consists of heterogenous networks, the quality of service provided to end systems is unpredictable. Bandwidth, delay, and jitter can vary dramatically, both in time and for selection of destinations. More demand than resources results in queues at the resources. If there are queues, there will be those who will pay to get a preferred position in the queue. In other words, some will pay for QoS. If there is no queue, then it is not worthwhile to pay extra for QoS guarantees. The Internet provides a best effort model. Traffic from various sources compete for resources against each other. Most of the routers implement the first come first serve (FCFS) model and drop packets if their buffer is full. As is evident from past experience, this simple model has worked successfully for the past several years supporting a very large number of users globally. Figure 1.5 shows the end-to-end delays suffered by 100 packets sent between two end systems that are 7 hops apart. Packets suffered delays ranging from 30 ms to 90 ms. This makes transmission of media such as audio and video very challenging. End to end delay 90

80

70 Delay (ms)



60

50

40

30 0

Figure 1.5

10

20

30

40 50 60 Packet Sequence Number

End-to-end delay in the Internet.

70

80

90

100

14

Engineering Internet QoS

1.8 SUPPORTING QoS IN BEST-EFFORT NETWORKS

The goals of designing a multimedia communication system that guarantees QoS would be to meet the following properties: Bounds on delay and jitter; Effective utilization of bandwidth; Acceptable error rate; Low processing overhead for the underlying communication and end systems; Adaptability to dynamically changing network and traffic conditions. As discussed earlier, interactive multimedia applications such as video-conferencing require a bound on jitter in addition to a bound on delay (variance in end-to-end delay is called jitter). Delay jitter is an important performance metric for real-time traffic. For example, if the screen is not updated regularly, the user may notice flickering in the image. Similarly, if voice samples are not played out at regular intervals, voice output may sound distorted. Some factors responsible for causing jitter are: The time required to digitize, compress, and decompress; Variation in delay in the network transport system; Operating system scheduling latencies. Figure 1.6 shows the steps involved in playing out a video frame from the moment it is grabbed by the sender until it is displayed at the receiver. The grab line shows the interval between successive frame grabbing and compression. The time interval between two successive frames is variable. The next line shows the time line of frames being sent from the sender. The receive line shows the time when frames arrive at the receiver. The jitter in network delay introduces variance in arrival of frames at the receiver. This variance can be very large in a connectionless network such as the Internet. In order to accommodate the jitter introduced by grabber, sender, and network, each frame is delayed by an additional amount . After this delay period, frames are played back at a regular interval, , depending upon the frame rate. If the operating system at the receiver supports real-time guarantees, we can expect the inter-display time to be constant. For non-real-time operating systems or where is the variation in operating such as UNIX, this interval is



 







Introduction

15

system latency. Bounds can be provided if the network is connection oriented and resources can be reserved in advance during the connection set-up phase.

Grab

Send Time

Receive d

Playout Real−Time OS D

R

R Playout Non−Real−Time OS

D

R+r

R−r

L

Figure 1.6

Video playout pipeline.

However, under the assumption that the network cannot guarantee the required bounds on delay and jitter, there is a need to accommodate the delay jitter in end systems. If the underlying network is connectionless (individual packets may take different routes), the video frames may arrive at the destination out of sequence or after the time at which they should be displayed. A gap may result if a frame is not available for display. This may affect the quality of audio-video playout. An application may reduce or eliminate delay jitter by carefully managing the process of acquiring, processing, transmitting, and displaying frames. However, this may require services from the operating system and the network transport system that are not provided in general purpose computing and networking environments.

16

Engineering Internet QoS

1.9 APPLICATION-LEVEL ADAPTATION We discuss some of the methods used for smoothing packet delay variability in the output by destination buffering. The basic idea behind each of them is to delay the display of the first packet by an amount, , (called the destination wait time) so that the receiver has at least one frame buffered most of the time. This reduces the frequency and duration of gaps caused by late arrival of packets, but results in increased latency. Selection of the value of is the key to the success of any playout algorithm.





1.9.1 Montgomery’s Destination Wait Method In this approach, the receiving system selects a destination wait time and attempts to play the received frames after this time. For each received packet, the playout time is selected as a fixed interval after which the packet is produced. Packets that arrive before their playout time are placed in a buffer (to wait for the amount of destination wait time). Packets that arrive late may be considered lost, subject to playout policies. Selection of this destination wait time is a very challenging task and should take into consideration the variation in end-to-end delay. Such systems should also dynamically adjust the destination wait time. The destination wait time should be chosen to optimize the delay and loss. Figure 1.7 (adapted from [21]) shows two delay components, fixed delay ( ) and variable delay ( ). The playout point is the sum of and . It is evident from the figure that loss of packets (because of late arrival) can be reduced by increasing the playout time. For interactive communication, there is an upper limit on acceptable end-to-end latency of packets. Hence the playout point has to be within this limit if interactivity is to be maintained. Subjective evaluations have shown that 250 ms may be an appropriate upper limit on one-way communication delay for a packet voice call in the public telephone network [22]. Montgomery suggested various ways of determining end-to-end delay and then displaying the frames based on this estimate. In a method called blind delay, the delay of the first packet is taken as and is chosen to optimize the loss factor. If sender and receiver clocks drift then this factor has to be adjusted in the playout time calculation. However, this method is not suitable for WANs where may be too large. Round-trip measurement is another way of estimating delay. This involves measuring round-trip delay to a destination and assuming that it is equally distributed in both directions (although this may not be true). This approach has been used for clock synchronization in distributed systems.















Introduction

17

100 %

% of packet arriving

0%

Df

Dv

Playout Time

Figure 1.7

Impact of destination wait time on playout.

Absolute timing uses synchronized clocks, which means that source and destination both use the same absolute timing reference. The network time protocol (NT) [23] facilitates synchronization of clocks in distributed systems to a granularity of a few milliseconds. The task of clock synchronization is becoming easier by use of the global positioning system (GPS) [24]. The GPS system is a space-based radio-positioning system consisting of a collection of satellites owned by the U.S. government that provide navigation and timing information to military and civilian users around the world. Signals from these satellites are so accurate that the time can be estimated within tens of microseconds. GPS receivers are already available in the market and can be fitted to PCs and workstations. As the price of these receivers goes down, they will become ubiquitous. The added variable delay method suggests use of an additional delay stamp field in the packet header. Each source of variable delay (queuing and processing) adds the delay introduced to this field using the local clocks (time the packet was sent – time packet was received). The playout time of packets is calculated using the local clock of the receiver as follows:


!#"%$ $'&)(+*-,./"%01*023$ $'&4(+*5 (+6 7*#89:#&',

Maximum destination wait time

Montgomery also recommends adaptation of the delay estimate as the call progresses so that the destination wait time can be changed during a silence interval. These can be compressed or expanded without compromising the quality of speech. The Pandora system [25] uses clawback buffers to place packets as they arrive. These buffers are designed to remove the effects of jitter and are placed as close to the destination as possible. Some ways have been suggested for deciding how much to buffer. This in turn accommodates jitter. 1.9.2 Adaptive Audio Playout In this section we describe an adaptive method of audio playout that is being used by most MBONE audio applications [26]. The playout time for the first packet of the talk spurt is calculated using:

?A@

? @ ,CB @ D FE 2FGIH

(1.2)

where

J? @K, Playout time for frame & B3@L, Send time for frame & H, Jitter

MEC, Adapted delay value 2N,PORQTSZO

ORQSmQVlnllnQ[



O=QSmQVlnllnQ[

a ˜ 6—™lnllnl ˜ 6%X 6  6 a ~[ ~R[-N6 a ~[• Cc8~[g6 a e}~ZO#e

ša1Q}š — Q›lnllnQ\š X

52

Engineering Internet QoS

8 Mbps (31–23) are divided equally among 4 remaining sources. This gives the remaining sources 33 Mbps each. However, the second source needs only 27 Mbps; the residual 6 (33–27) are divided among the remaining three sources. This increases the allocation for sources 3 to 5 to 35 Mbps each (since all of these sources need 35 Mbps or more, the algorithm stops allocation at this point).

3.2 SCHEDULING TECHNIQUES A number of different scheduling techniques have been proposed in literature. Several of these separate packets into different queues and serve each queue with different criteria. A detailed discussion of the most prominent of these schemes currently being used in the Internet is presented here. 3.2.1 First Come First Serve In traditional packet switching networks, packets from all flows are enqueued into a common buffer and a server serves packets from the head of the queue. This scheme is either called first come first serve (FCFS) or first in first out (FIFO) as shown in Figure 3.1(a). It shows arrival of packets into a FCFS queue and the scheduler serving packets from the head of the queue. Figure 3.1(b) shows a scenario in which all buffers are occupied and a newly arrived packet is dropped. FCFS fails to allocate max-min fair share bandwidth allocation to individual flows. A greedy source can occupy most of the queue and cause delay to other flows using the same queue. Congestion sensitive TCP flows get penalized (TCP flow reduces its sending rate in the wake of congestion) at the expense of applications using UDP flows with no congestion control. A detailed discussion of which packet to drop when a buffer is full and a variety of congestion control techniques are further discussed in Chapter 4. Figure 3.2 shows throughputs of two flows sending packets through a bottleneck router that implements the FCFS scheme. Flow 1 starts sending at 1.5 Mbps and achieves this rate until Flow 2 starts at time 5 with a rate of 1.0 Mbps. Both flows continue untill time 40. It is evident that there is no fixed pattern of sharing bandwidth between the flows as the router serves the packet that arrives first. Only after time 40, when the first flow ceases, does the second flow start getting the required bandwidth. Figure 3.3 shows the same two flows going through the same router that implements a stochastic fairness queuing scheme (discussed later in this chapter). Both flows get a fair share of bandwidth between time 5 and 40 in this case.

Scheduling for QoS Management

53

Head Arrival

Departure FCFS scheduler (a) Tail

Arrival

Departure FCFS scheduler

Packet dropped Buffer empty

Buffer full

(b) Figure 3.1

First come first serve.

Use of a single queue and FCFS scheduling to serve packets from a queue has major limitations for QoS support. First of all there is no flow isolation. Without flow isolation it is very difficult to guarantee delay bound or bandwidth guarantee to specific flows. If different service is required for different flows, multiple queues are needed to separate the flows. Nagle [2] proposed a scheme that separates the flows using their source and destination IP address pair into different queues and then serving these queues in round robin order. However, the scheme may not work well when packets are of variable size. Several advanced scheduling techniques discussed in the following sections use multiple queues. 3.2.2 Priority Queuing One simple way to provide differential treatment to flows is to use multiple queues with associated priorities. Multiple queues with different priority levels, 0 to , are maintained as shown in Figure 3.4. The number of priorities to be used will depend on the number of priority levels supported by a particular protocol. For

2FDO

54

Engineering Internet QoS

1.6 Flow 1 Flow 2 1.4

Throughput (Mbps)

1.2

1

0.8

0.6

0.4

0.2

0 0

10

20

30

40

50

60

Time

Figure 3.2

Throughput achieved with First come first serve.

example, the IPv4 header supports a field called type of service (ToS). Details of the ToS field will be discussed in Chapter 7. The source can use this field to request preferential treatment from the network. If there are packets queued in both higher and lower priority queues, the scheduler serves packets from the higher priority queue before it attends to the lower priority queue. For example, priority 0 is always serviced first. The highest priority has the least delay, highest throughput, and lowest loss. Priority is serviced only if 0 through are empty. This scheme has the potential of starvation of lower priority classes (i.e., the server will be unable to serve the lower class because it is always busy serving the higher class). However, priority queuing is simple from an implementation point of view, as it needs to maintain only a few states per queue. It is important to note that packets from a given priority queue are usually served FCFS. Therefore, FCFS is a useful and simple scheduling technique and it may be used in conjunction with other advanced scheduling techniques.

&

&œCO

3.2.3 Generalized Processor Sharing Generalized processor sharing (GPS) is an ideal work-conserving scheme that is capable of achieving max-min fair share [3, 4]. In simple terms, GPS assumes that

Scheduling for QoS Management

55

1.8 Flow 1 Flow 2 1.6

1.4

Throughput (Mbps)

1.2

1

0.8

0.6

0.4

0.2

0 0

10

20

30

40

50

60

Time

Figure 3.3

Throughputs achieved with Stochastic fairness queuing.

each flow is kept in a separate logical queue. It serves an infinitesimal amount of data from each queue such that in a finite time interval it visits every nonempty queue. Each queue can have associated weight and can be served in proportion of its weight. If we assume that there are active flows, then each flow gets of a share of max-min resource. (Remember that the GPS server serves an infinitesimal chunk of data from each flow.) If a queue is empty (because the flow needs less than its max-min fair share), the residual resource gets evenly distributed among competing flows. GPS is capable of achieving max-min weighted fair share as well. In GPS terminology, a connection is called backlogged when it has data present in the queue. Let us assume that there are flows to be served by a server implementing GPS with weights . The service rate for th flow in interval is represented as . For any backlogged flow in interval and for another flow , the following equation holds:



¢ £ Q\$4¤

H

  YcfO0e¡Qf Yc)£ SRe/QWlVlWl¡Qf Ycse ¥c`&TQ Q}$\e

 c8&Q ££ \Q $\e Y  c8&fe ¥ ¥cH=Q }Q $\e>¦  Ync H!e

&

O1~1ž8Ÿ

&

¢ £ Q\$4¤

(3.3)

Equation 3.3 achieves the max-min fair share by allocating the residual resource (unused resource) such that it gets shared by the backlogged connection

56

Engineering Internet QoS

Priority 0

Arrival Priority scheduler

Priority

Figure 3.4

Departure

§

Priority scheduling server.

in proportion of its weight. However, GPS is an ideal scheme, since serving an infinitesimal amount of data is not implementable. We discuss some variations of the GPS that can be implemented in a real system next. 3.2.4 Round Robin A simple implementation of GPS is the round robin (RR) scheduling whereby one packet replaces infinitesimal data. To address the fairness problem of a single FCFS queue, the round robin scheduler maintains one queue for each flow. Each incoming packet is placed in an appropriate queue. The queues are served in a round robin fashion, taking one packet from each nonempty queue in turn. Empty queues are skipped over. This scheme is fair in that each busy flow gets to send exactly one packet per cycle. Further, this is a load balancing among the various flows. Note that there is no advantage to being greedy. A greedy flow finds that its queue becomes long, increasing its delay, whereas other flows are unaffected by this behavior. If the packet sizes are fixed, such as in ATM networks, round robin provides a fair allocation of link bandwidth. If packet sizes are variable, which is the case in

Scheduling for QoS Management

57

the Internet, there is a fairness problem. Consider a queue with very large packets and several other queues with very small packets. With round robin, the scheduler will come back to the large-packet queue quickly and spend long times there. On average, the large-packet queue will get the lion’s share of the link bandwidth. Another problem with round robin is that it tries to allocate fair bandwidth to all queues and hence differential treatment, or any specific allocation of bandwidth to specific queues, is not achieved.

3.2.5 Weighted Round Robin

Weighted round robin (WRR) is a simple modification to round robin. Instead of serving a single packet from a queue per turn, it serves packets. Here is adjusted to allocate a specific fraction of link bandwidth to that queue. Each flow is given a weight that corresponds to the fraction of link bandwidth it is going to receive. The number of packets to serve in one turn is calculated from this weight and the link capacity. Assume three ATM sources (same cell size) with weights of 0.75, 1.0, and 1.5, respectively. If these weights are normalized to integer values, then the three sources will be served 3, 4, and 6 ATM cells in each round. The WRR works fine with fixed size packets, such as in ATM networks. However, WRR has difficulty in maintaining bandwidth guarantees with variable size packets (the Internet). The problem with a variable size packet is that flows with large packets will receive more than the allocated weight. In order to overcome this problem, the WRR server needs to know the mean packet size of sources a priori. Now assume that a serial link (MTU 500 bytes), an Ethernet (MTU 1,500 bytes), and an FDDI ring network (MTU 4,500 bytes), share a high-speed outgoing link. Each of these links are assigned weights of 0.33, 0.66, and 1.0. Using weights normalized to their respective packet sizes, the scheduler will need to serve 6 packets from the serial link (3,000 bytes), 4 packets from the Ethernet (6,000 bytes), and 2 packets from the FDDI (9,000 bytes). Short-term fairness is another problem encountered by WRR. On a small time scale, WRR does not meet the fairness criteria, since some flows may transmit more than others. In the previous example, while FDDI packets of 9,000 bytes are sent, other links will not get the chance to transmit. This would mean that WRR is not fair on a time scale of less than 9,000 byte transmission time (at 100 Mbps, it would take around 72 s to send 9,000 bytes).

¨

2

2

58

Engineering Internet QoS

3.2.6 Deficit Round Robin Deficit round robin (DRR) improves WRR by being able to serve variable length packets without knowing the mean packet size of connections a priori. The algorithms work as follows: Initially a variable quantum is initialized to represent the number of bits to be served from each queue. The scheduler starts serving each queue that has a packet to be served. If the packet size is less than or equal to the quantum, the packet is served. However, if the packet is bigger than the quantum size, the packet has to wait for another round. In this case another counter, called a deficit counter, is initialized for this queue. If a packet can’t be served in a round, its deficit counter is incremented by the size of the quantum. The following pseudo code adapted from Shreedhar and Varghese [5] describes the DRR scheme. 1 0

#define TRUE #define FALSE

©

void DeficitRoundRobin() /*initialize the deficit counter*/ for(conn=1; conn = N; conn++) deficitCounter[conn] = 0; quantum = q;/* quantum for each queue*/ while (TRUE)

ª

©

/* get the queue id for active connection if (Activelist.Isempty() == TRUE)

©

conn = Activelist.getconnid(); /* add quantum to deficit*/ deficitCounter[conn]+= q; while ((headofQueue[conn].Isempty())== FALSE) && deficitCounter[conn] 0))

«

©

packetSize = headofQueue[conn].packetSize; if (packetSize = deficitCounter[conn])

«

©

Dequeue(headofQueue[conn]); deficitCounter[conn] = packetSize;

¬

­ ©

else conn++; break;

Scheduling for QoS Management

59

­ /* stop accumulation of deficit counter*/ if (headofQueue[conn].Isempty())== TRUE) deficitCounter[conn]= 0; else

­ ­

­

Activelist.Setflag(conn);

Let’s look at an example to understand the working of the DRR scheme. Figure 3.5 shows four queues, q1 to q4. It is assumed that the deficit counter of all queues has been initialized to 0. The queues have the following status initially:

® ®

q1 has two packets of size 500 and 700 bytes.

®

q3 has two packets of size 200 and 500 bytes.

q2 is empty.

®

q4 has one packet of size 400 bytes.

Assume that the quantum is set to 500 bytes for all queues. It is possible to configure different quantum for various queues. Figure 3.5 shows the snapshot of the first round and the deficit counter values are shown at the beginning and the end of processing a queue. For q1, the start value is 500 and the first packet of size 500 gets served from this queue, resulting in 0 value at the end of this round. The q2 has both start and end value of deficit counter as 0, as it is not active. The third queue, q3, gets its first packet of size 200 served, resulting in a deficit counter value of 300, as it has another outstanding packet of size 500 in the queue. The q4 gets its first packet of size 400 served. However, its deficit counter will be reset to zero. This ensures that credits cannot be accumulated for a long period of time and fairness can be maintained. In round 2 (Figure 3.6), the q1 has a packet of size 700 at the start of the queue. It cannot be served, as it gets a 500 quantum at the beginning, which is not sufficient for a 700-byte packet. However, at the end of this round the deficit counter of 500 gets accumulated for the next round. The q3 has a packet of size 500 at the front of the queue as well as a newly arrived packet of size 400. The deficit counter is at the beginning of the round. A packet gets served from this queue resulting in a carry-over of 300 in its deficit counter. Finally in round 3 (Figure 3.7), the first packet of 700 bytes from q1 gets served, as its deficit counter is 1000 at the start of this round. The q3 works exactly the same way, serving its last

¯=°R°L±³²°R°

60

Engineering Internet QoS

packet of 400 bytes. The deficit counter is reset to zero for the queues q1 and q3, as they do not have a packet waiting in the queue. Deficit counter

Round 1 q1

700

500

q2

Empty queue

q3

500

q4

Figure 3.5

200

400

Packet sent

Start

End

500

0

0

0

500

300

q2

500

0

q4

q1

DRR scheduling round 1.

DRR should set the quantum (bits to be served) to at least one packet from each connection. This would require one to set the quantum to MTU of the link. For example, if the link consists of Ethernet packets, it should be set to 1,500 bytes. DRR is not fair at time scales shorter than a packet time. However, ease of implementation makes it an attractive scheduler. 3.2.7 Weighted Fair Queuing For variable size packets (Internet), a complex scheduler such as weighted fair queue (WFQ) is used. Another identical scheme called packet-by-packet generalized processor sharing (PGPS) was invented at the same time as WFQ. For our purposes, discussion is restricted to WFQ. Each packet is tagged on the ingress with a value identifying, theoretically, the time the last bit of the packet should be transmitted. Basically this tag value (or finish time) of the packet is the time a packet would have been transmitted if GPS scheduler was used (as we have discussed earlier, GPS is not an implementable scheme). Each time the link is available to send a packet, the packet with the lowest tag value is selected.

Scheduling for QoS Management

Deficit counter

Round 2 q1

q2

q3

q4

Figure 3.6

700

Empty queue

400

500

Empty queue

q1

Figure 3.7

End

500

500

0

0

800

300

0

0

Deficit counter Start

700

Empty queue

400

q3

q4

Start

Packet sent

q2

DRR scheduling round 2.

Round 3

q2

61

Empty queue

DRR scheduling round 3.

End

1000

0

0

0

800

0

0

0

Packet sent q1

q2

62

Engineering Internet QoS

Finish Time Calculation The following equation is used to calculate the virtual finish time would have finished sending the packet on connection ):

· ¸ ´ ¹ µ ¶{ºy» ·+¼½J¾8´ ¶Aµ ¿3ÀÁ} `¾ Ã\Ä}ÄL±Å ¶ µ Æ0Ç ¾¸VÄ

´N¶ µ

(the router

(3.4)

 ¾`Ã\Ä

where is called a round number. This is the number a bit-by-bit round robin scheduler (in place of GPS’s nonimplementable infinitesimal data) has completed at a given time. The round number is a variable that depends on the number of active queues to be served (inversely proportional to the active queue number). The more queues to serve, the longer a round will take to complete. is the time required to transmit packet from connection, and is the weight of connection .

·+É8Ê

Ç ¾8¸VÄ

¸0É8Ê

Åȶ µ

¸

Example of Finish Time Calculation The following example demonstrates how the WFQ scheme works. It is assumed that there are three equally weighted connections [i.e., equals one for all connections] , , and and the link service rate is 1 unit/s. Packet names such as one, two, three, etc., are used to simplify understanding of concepts. Following are the packet details used in our example:

Ë Ì

®

Ç ¾8¸VÄ

Í

Ë

®

one: arrive at time 0 on connection of size 2 units;

®

three: arrive at time 2 on connection of size 3 units;

®

five: arrive at time 3 on connection

Ì

®

two: arrive at time 1 on connection of size 2 units;

®

four: arrive at time 2 on connection of size 1 units;

Ë

Í

Ì

Ë

of size 4 units;

six: arrive at time 4 on connection of size 1 units.

Figure 3.8 shows this scheme. At time 0, counters such as round number and finish time for connections , , and are initialized to zero. Calculations of finish times of packets are shown below:

Ë Ì

®

®

one: ;

Ì

Ë

two: ;

Í

´À Î » ·+¼½J¾8° Á °–Ï °ÄL±|Ð » Ð , where  ¾8°Ä » ° , first packet on connection ´-À Ñ » ·+¼=½K¾8° ÁVÒ Ï °=Äb±|Ð » ¯ , where  ¾ Ò Ä » Ò , first packet on connection

Scheduling for QoS Management

®

63

´ Ó Î » ·+¼½J¾)Ð ÁVÒ Ï ²=Äb±D¯ » ² , where  ¾)ÐRÄ » Ò Ï ² and ´À Î » Ð ; ® four: ´Ó Ñ » ·+¼½J¾¯ ÁVÒ Ï ²=Ä3± Ò »Ô , where  ¾Ð=Ä » Ò Ï ² and ´•À Ñ » ¯ ; ® five: ´À Õ » ·+¼½J¾° Á ÐmÏ °ÄW± ԕ»Ö , where  ¾¯=Ä » Ð@?#A