Internet Voice, Video and Telepresence Harvard University, CSCI E-139. Lecture #6

Internet Voice, Video and Telepresence Harvard University, CSCI E-139 Lecture #6 Instructor: Len Evenchik len_evenchik@harvard.edu sip:len.evenchik@harvard.edu Harvard Bridge, 1923 L. Evenchik 2013 Lecture Agenda Welcome Course Logistics Q&A and Topics from Last Week Quality of Service DiffServ Network Monitoring and Testing One Minute Wrap-Up (please complete online) L. Evenchik 2013 (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 1

Course Logistics L. Evenchik 2013 Course Logistics Project Proposals are due on today, March 11 th. Please contact me asap if you have not submitted a proposal. I ll review the proposals by Wednesday. There are three parts to the project: Written report (10 to 15 pages) One page project summary (or a few slides) and a recorded video. This will be shared with your classmates. In-class project presentation and discussion (via video) Next week is Harvard s spring break so there is no lecture next Monday March 18 th. Please complete a One-Minute Wrap Up each week! L. Evenchik 2013 (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 2

Quality of Service Chicago Traffic Jam 1911 Harvard Bridge (Mass Ave Bridge) 1923 Photo of Harvard Bridge Source: Boston Public Library, Leslie Jones collection Photo of Chicago Source:http://www.autolife.umd.umich.edu/Environment/E_Casestudy L. Evenchik 2012, SK2012AE-2 RTP Packet Flow for Video Call (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 4

Network QoS Quality of Service (QoS) Every network application has a basic set of requirements that the network must meet in the delivery of the traffic generated by the application. This is not a new problem, it goes back to remote data entry on the first mainframe computers. The requirements center on bandwidth, delay, jitter and error rate. These parameters define the Quality of Service (QoS) and the specific goals for them are called a Service Level Agreement (SLA) Compared to best effort delivery implementing QoS enhances the network s ability to provide the characteristics required by a specific application. (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 5

7 Day Traffic Query for Sprint New York NAP Measured on Dec 15, 1997 at 10am Source and copyright (if applicable) to http://www.nlanr.net/nap/ Why QOS? The IP network does not guarantee QOS or even delivery Resource conflicts with data traffic increase the risk that Audio / Video packets or other high priority packets will be delayed or lost Audio/Video quality deteriorates quickly when packets are lost or delayed With QoS, the system implements priority treatment for some types of user traffic, giving them preferential treatment at each store-and-forward device QoS can then improve a packet s chance of successful, timely delivery As you know, a voice (or video) packet that is delivered late is comparable to it never showing up. (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 6

QOS - How Do You Define and Specify Quality Bandwidth Error Rate Delay Jitter Drop Probability Characteristics Availability, System Reliability plus many other choices Intuitive Approach to Queueing and Delay Which Packet Goes Next? One (1) Output Port Two (2) input ports each carrying three different types of data (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 7

Delay Components Time required to put all of the bits on the wire. This is dependent upon the length of the frame and the clock rate of the wire. Plus, the time required for the first bit to reach the far end of the wire. This is dependent upon the distance to the far end and of course, the speed of light. Plus, the time required to get all of the bits off the wire. Plus processing delays in the device. Delay Components Putting the Bits on the Wire Time required to put all of the bits on the wire. Assume a frame is 1,250 bytes long: Delay for a 56 kbps link: Delay for a T1 (1.5 Mbps) link: Delay for a 10 mbps link: Delay for a 100 mbps link: (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 8

Network Delay in the Real World Packet delay is determined by the three network components we have described. These factors are of course present for each and every device along the path. Delay is cumulative. Plus of course, the processing time (CPU cycles) and buffering (queuing) required within each device along the path must also be added into the equation. Intuitive Approach to Queueing and Delay Which Packet Goes Next? One (1) Output Port Two (2) input ports each carrying three different types of data (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 9

Internet Jitter and Delay Video source Video (audio) packets sent into the network every 20 msec Internet Cloud The received packet stream has jitter due to the network Queue Delay, Jitter and Packet Loss Packets pass through queues in routers, firewalls, B2BUAs, clients, etc. The depth of the queue affects delay Insufficient bandwidth on the output causes increased delay and packet loss (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 10

Jitter Queue Tradeoff Jitter queues are used in clients to provide for the consistent playback of the media. Jitter queues help mittigate the network jitter that is present in all networks. But the jitter queue adds delay to the stream Delay and jitter must be managed to improve interactive audio/video. A variable length jitter buffer is better than a fixed length jitter buffer. Note that delay can be very long for streaming audio/video since jitter is not important in this case Measuring the Error Rate Radio, fiber optic, and other engineers that work on communication circuits worry about the Bit Error Rate (BER), but it is much more common today to talk about the packet error rate for a link or a network. Packet error rates, or packet loss rates are measured as a percentage, such as 0.5 percent packet loss. Error rates must be measured over a short period of time. For video systems this should be a few minutes, or even less when the network is being proactively tested. Network availability is different than network error rate. Availability of 99.99 percent per year means about one hour of outage per year. (99.9 percent is almost 9 hours.) Five nines was the norm for POTS. (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 11

Approaches to Managing QoS Have a lot of bandwidth available! Allocate bandwidth to particular conversations or users just before it is needed, and then keep track of the reservations and allocations (this is Int-Serv and RSVP) Mark the packets using some specific criteria and then treat the packets differently in the network using the marking as a guide (DiffServ) Try to ignore that there is a problem Or as a friend in the telephone business said to me, Use circuit switching instead of packet switching. Increase Bandwidth If a videoconference shares a lightly loaded network, QoS is not necessary When bandwidth is restricted, or the network is heavily loaded, QoS is needed to make sure that there the video/audio traffic is being given preferential treatment versus the data traffic (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 13

Increase Bandwidth Increasing bandwidth always helps video and audio quality when no QoS is present Increasing bandwidth in the LAN is relatively inexpensive and solves most, but not all of the problems. However increasing bandwidth over the WAN can be prohibitively expensive or simply impossible Note that increasing the bandwidth in wireless networks is not the same as improving the error rate. QoS via the RSVP Protocol RSVP Protocol reserves router/network resources Soft state - reservations must be refreshed Defines Flexible Class of Service (Guaranteed or Controlled Load) The problem with RSVP is seen as one of scaling, but there is still limited real-world experience with RSVP in large networks (and not much activity that I know of.) (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 14

QoS with RSVP Resource reservation Protocol Reserve 1 Mbps BW on this line Router This app needs 1 Mbps BW and 100 msec delay I need 1 Mbps BW and 100 msec delay Router Reserve 1 Mbps BW on this line Router Differentiated Service, DiffServ Diffserv was defined by the IETF about a dozen years ago and it has been a very active area of work since thern. Diffserv can be applied both to the Internet and private networks. Almost all implementations are in private networks today (MPLS, private IP, etc.) Approach provides for "the overall treatment of a defined subset of a customer's traffic within a DS-domain" The approach is to mark high priority packets in some special way, and then to give preferential treatment to these specially marked packets. Diffserv is not implemented in the general Internet. Why not? (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 15

Packet Marking vs Packet Treatment At a minimum, there are two distinct parts to handling QoS using the DiffServ approach: packet marking and then treatment of the marked packets in all parts of the network. Lets think about the difference between there two parts by looking at an overnight deliver service. Differentiated Service, DSCP Diffserv re-uses the high order six bits of the former IP TOS (Type of Service) field. End systems or some other edge device mark the DS field of each packet with a specific value. These values then specify in some way how the packet is treated within the network. Packets can be remarked at a later time by other devices Once marked each device in the network treats the packets differently depending on the Diffserv marking. This DS field specifies a DSCP (DS Code Point) which identifies a Per Hop Behavior (PHB.) In case you are confused, the above is anything but obvious. (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 16

Differentiated Service, Codepoints Codepoint = 000000 Best effort Codepoint = xxx000 Provides for compatibility with IP precedence Codepoint = 101110 Expedited Forwarding (EF) strict low latency queue Codepoint = 001010, 001100, plus 10 more Assured Forwarding (AF) 4 queues with 3 levels of drop preferences (probabilities) in each queue Differentiated Services Field Codepoints http://www.iana.org/assignments/dscp-registry/ Name Space Reference --------- ------- -------- CS0 000000 [RFC2474] CS1 001000 [RFC2474] CS2 010000 [RFC2474] CS3 011000 [RFC2474] CS4 100000 [RFC2474] CS5 101000 [RFC2474] CS6 110000 [RFC2474] CS7 111000 [RFC2474] AF11 001010 [RFC2597] AF12 001100 [RFC2597] AF13 001110 [RFC2597] AF21 010010 [RFC2597] AF22 010100 [RFC2597] AF23 010110 [RFC2597] AF31 011010 [RFC2597] AF32 011100 [RFC2597] AF33 011110 [RFC2597] AF41 100010 [RFC2597] AF42 100100 [RFC2597] AF43 100110 [RFC2597] EF PHB 101110 [RFC3246] (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 17

Sample Code Point Assignment Type Bronze Default Silver HTTP HTTPS Gold Video and other low delay traffic Platinum VoIP, Video IP Prec 0 1 2 3 4 6 7 5 DSCP 0 - Default 2 4 6 8 CS1 10 AF11 12 AF12 14 AF13 16 CS2 18 AF21 20 AF22 22 AF23 24 CS3 26 AF31 28 AF32 30 AF33 32 CS4 34 AF41 36 AF42 38 AF43 48 CS6 50 52 54 56 CS7 58 60 62 40 CS5 42 44 46 - EF Best Effort Low Latency DiffServ Block Diagram +-------+! -------------------+! +-----> Meter! --+! +-------+! V V! +------------+ +--------+ +---------+! Shaper/! packets =====> Classifier =====> Marker =====> Dropper =====>!! +------------+ +--------+ +---------+! Fig. 1: Logical View of a Packet Classifier and Traffic Conditioner Source RFC 2475 (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 18

Real World Network Test Results Packet Loss with/without QoS Traffic w/o QoS Showed Packet Loss Traffic with QoS, no loss The traffic sent without QoS showed consistent packet loss, while the traffic with QoS marked showed almost no loss. Each stream was 5 Mbps from San Diego to Paris via private MPLS network. Network Testing and Evaluation for Video and VoIP (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 19

Network Testing and Monitoring The terms network monitoring, network analysis, network testing, network assessment, protocol analysis (Wireshark), etc. are all used in the industry. These terms are ill-defined and ambiguous. There are dozens if not hundreds of tools and systems available for network testing and monitoring. Lets define network testing (for this course) as what we do to debug or analyze a specific network problem or system at a specific point in time. There are of course many different types of network tests: throughput, error rate, jitter, etc. Lets define network monitoring (for this course) as the ongoing long-term analysis of network performance. Specific pieces of network equipment also have unique test requirements. Lets look at some tools and test results and see what we can learn. Network Speed Tests (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 20

Problems for VoIP and Video when an Ethernet Link is Incorrectly Configured (FDX versus HDX) 100BaseT ethernet is implemented with switches and links that can be configures as auto, full-duplex or half-duplex ethernet There is a significant error rate and performance problem when the switch port and the end station are not configured exactly the same way. Why do you think this is the case, and how could you figure it out? This continues to be a problem today. Fortunately, GigEthernet does not have the problem. LAN Performance Problem Caused by FDX/HDX Mismatch (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 22

Network Load Testing Real World Network Test Results Packet Loss with/without QoS Traffic w/o QoS Showed Packet Loss Traffic with QoS, no loss The traffic sent without QoS showed consistent packet loss, while the traffic with QoS marked showed almost no loss. Each stream was 5 Mbps from San Diego to Paris via private MPLS network. This is a report from a network testing tool called Ixia Chariot. (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 23

Real World Network Test Results Throughput with/without QoS Consistent throughput when QoS marked Traffic w/o QoS This is a report from a network testing tool called Ixia Chariot. Real World Network Test Results Jitter with/without QoS There is increased jitter when QoS is not marked. Jitter w/o QoS Jitter with QoS This is a report from a network testing tool called Ixia Chariot. (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 24

Network Performance, Cambridge to London, 24 Hour Period This is a report from a network testing tool called AppNeta Pathviewcloud Network Performance from Cambridge, MA to London (2) This is a report from a network testing tool called AppNeta Pathviewcloud (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 26

Network Performance, Cambridge, MA to London, Route Changes This is a report from a network testing tool called AppNeta Pathviewcloud Network Performance, Cambridge, MA to London, 48 Hours This is a report from a network testing tool called AppNeta Pathviewcloud (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 27

Network Performance, Cambridge, MA to London, 14 Days (1 of 2) This is a report from a network testing tool called AppNeta Pathviewcloud Network Performance, Cambridge, MA to London, 14 Days (2 of 2) This is a report from a network testing tool called AppNeta Pathviewcloud (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 28

Network and Device Testing VoIP PBX Testing Across the Campus Network VPN Resets Caused VoIP Disconnects This is a report from a network testing tool called AppNeta Pathviewcloud (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 29

Firewall Performance Problem Firewall at WAN edge dropped packets Tests before firewall upgrade showed 0.2 percent packet loss. These tests were run at 768 Kbps Tests after firewall upgrade showed no packet loss. These tests were run at 5 Mbps This is a report from a network testing tool called AppNeta Pathviewcloud Router QoS Queuing Problem (Blue is Best Effort traffic, Orange is AF41 traffic) Error Rate 8 Mbps Error Rate 10 Mbps No packet loss, orange line hidden under blue line Jitter Jitter Significant packet loss for AF41 traffic. Each test stream (AF41 and Best Effort) was 8 Mbps of traffic from New York City to Paris. Each test stream (AF41 and Best Effort) was 10 Mbps of traffic from New York City to Paris. This is a report from a network testing tool called AppNeta Pathviewcloud (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 30

QoS Objective for Video and VoIP Throughput: Error rate: Delay/Latency: Jitter: Availability: One Minute Wrap-Up Please do this Wrap-Up at the end of each lecture. There is a form for this on the course website. The Wrap- Up can be anonymous. Please answer three questions: What is your grand Aha for today s class? What concept did you find most confusing in today s class? What questions should I address next time L. Evenchik 2013 (c) 2013 Len Evenchik (evenchik@fas.harvard.edu) Page 31