Multimedia networking
Upcoming SlideShare
Loading in...5
×
 

Multimedia networking

on

  • 509 views

A clear description of multimedia networking

A clear description of multimedia networking

Statistics

Views

Total Views
509
Views on SlideShare
509
Embed Views
0

Actions

Likes
0
Downloads
35
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Insight 3: While providing isolation among classes or flows, it is desirable to use resources (for example, link bandwidth and buffers) as efficiently as possible. <br />

Multimedia networking Multimedia networking Presentation Transcript

  • MULTIMEDIA NETWORKING Presenters 1. NANKYA MARIAM 2013/HD05/496U 2. ASINGIRWE BARBARA KABWIGA 2013/HD05/475U 3. KYOMUHENDO SAMANTHA 2013/HD05/488U 4. THEMBO JIMMY 2013/HD05/467U
  • OVERVIEW Introduction Multimedia Networking Applications Streaming Stored Video Voice-Over-IP Protocols for real-time Conversational Applications Network Support for Multimedia MULTIMEDIA NETWORKING 2
  • INTRODUCTION Multimedia-Technology that enables humans to use computers capable of processing textual data, audio and video, still pictures, and animation. Today, people not only use the internet to watch movies but also to upload videos ( YouTube), make internet calls (Skype and Google talk). By the end of the decade and with emerging technologies like 4G and Wi-Fi access, Internet will not only provide phone service for less money, but will also provide numerous value-added services, such as video conferencing, online directory services, and voice messaging MULTIMEDIA NETWORKING 3
  • Multimedia Networking Applications Multimedia network application is any network application that employs audio or video. To Understand Internet Multimedia applications, first we look at the characteristics (Properties) of video & audio. Properties of Video  Video has high bit rate (100Kbps for low-quality video conferencing to 3Mps HD Movies)  Video can be compressed, Compression can be used to create different versions of a video with each having different video quality so users can choose whichever version they can watch according to their available bandwidth. MULTIMEDIA NETWORKING 4
  • Properties of Audio Basic encoding technique of converting analog audio into digital audio is called pulse code modulation (PCM) Examples of Sampling Rates  Speech encoding (uses PCM) ;8000 samples per second and 8 bits per sample  Audio compact disk (also uses PCM) ; 44,100 samples per second and 16 bits per sample PCM encoded speech not commonly used on the internet so compression techniques are used to lower bit rates of audio streams  MP3 is a compression technique and the encoders can compress rates most commonly to 128 kbps Note that digital audio has lower bandwidth compared to video although users are more sensitive to audio malfunctions than video. MULTIMEDIA NETWORKING 5
  • TYPES OF MULTIMEDIA NETWORK APPLICATIONS Multimedia applications are classified into three broad categories: Streaming Stored Video/Audio ◦Underlying medium is prerecorded video, such as a movie or a prerecorded user generated video (on YouTube). ◦These are stored on servers, and users send requests to the servers to view the videos Features of stored streaming video  Streaming  Interactivity  Continuous Playout MULTIMEDIA NETWORKING 6
  • Conversational Voice/Video Over IP Real-time conversational voice over the Internet commonly known as internet telephony (VoIP) Video conversational systems allow users to create conferences with three or more participants. Conversational voice and video are widely used in the Internet today, Skype, QQ, and Google Talk Two Important Application service requirement for CVVOIP  Timing Considerations Audio and video conversational applications are highly delay-sensitive  Tolerance of Data loss Conversational multimedia applications are loss-tolerant occasional loss only causes occasional glitches in audio/video playback, and these losses can often be partially or fully concealed MULTIMEDIA NETWORKING 7
  • Streaming Live Audio & Video Similar to traditional broadcast radio and television, except that transmission takes place over the Internet such as a live sporting event or news Because the event is live, delay can also be an issue, although the timing constraints are much less stringent than those for conversational voice Delays of up to ten seconds or so from when the user chooses to view a live transmission to when playout begins can be tolerated MULTIMEDIA NETWORKING 8
  • Streaming Stored Video For streaming video applications, prerecorded videos are placed on servers, and users send requests to these servers to view the videos on demand. User may watch the video from beginning to end without interruption, may stop watching the video well before it ends, or interact with the video by pausing or repositioning to a future or past scene Streaming systems can be categorized as:  UDP Streaming  HTTP Streaming  Adaptive HTTP Streaming MULTIMEDIA NETWORKING 9
  • Cumulative data Streaming Stored Video 1. video recorded (e.g., 30 frames/sec) 2. video sent network delay (fixed in this example) 3. video received, played out at client (30 frames/sec) time streaming: at this time, client playing out early part of video, while server still sending later part of video MULTIMEDIA NETWORKING 10
  • Streaming Stored Video: Challenges   Continuous Playout constraint: once client Playout begins, playback must match original timing  … but network delays are variable (jitter), so will need client-side buffer to match Playout requirements Other challenges:  Client interactivity: pause, fast-forward, rewind, jump through video  Video packets may be lost, retransmitted MULTIMEDIA NETWORKING 11
  • Client-side Buffering, Playout Buffer fill level, Q(t) Playout rate, e.g., CBR r Variable fill rate, x(t) Client application buffer, size B Video Server Client 1. Initial fill of buffer until Playout begins 2. Playout begins a 3. Buffer fill level varies over time as fill rate x(t) varies and playout rate r is constant MULTIMEDIA NETWORKING 12
  • Client-side Buffering, Playout buffer fill level, Q(t) playout rate, e.g., CBR r variable fill rate, x(t) client application buffer, size B video server Playout buffering: average fill rate (x), playout rate (r): x < r: buffer eventually empties (causing freezing of video playout until buffer again fills) x > r: buffer will not empty, provided initial playout delay is large enough to absorb variability in x(t)  Initial playout delay tradeoff: buffer starvation less likely with larger delay, but larger delay until user begins watching MULTIMEDIA NETWORKING 13
  • Advantages of client-Side Buffering Client side buffering can absorb variations in server-to-client delays; particular piece of video data is delayed, as long as it arrives before the reserve of received-but-not yet played video is exhausted, this long delay will not be noticed. If the server-to-client bandwidth briefly drops below the video consumption rate, a user can continue to enjoy continuous playback, as long as the client application buffer does not become completely drained. MULTIMEDIA NETWORKING 14
  • UDP Streaming UDP streaming, ..Server transmits video at a rate that matches the client’s video consumption rate by clocking out the video chunks over UDP at a steady rate. Drawbacks of UDP Streaming Its unpredictable and varying amount of available bandwidth between server and client, constant-rate UDP streaming can fail to provide continuous playout It requires a media control server, such as an RTSP server, to process client-toserver interactivity requests and to track client state  Third drawback is that many firewalls are configured to block UDP traffic, preventing the users behind these firewalls from receiving UDP video MULTIMEDIA NETWORKING 15
  • Streaming Multimedia: HTTP Multimedia file retrieved via HTTP GET Send at maximum possible rate under TCP variable rate, x(t) Video file TCP send buffer TCP receive buffer Server Application playout buffer Client Fill rate fluctuates due to TCP congestion control, retransmissions (in-order delivery) Larger playout delay: smooth TCP delivery rate HTTP/TCP passes more easily through firewalls and NATS MULTIMEDIA NETWORKING 16
  • Streaming Multimedia: DASH DASH: Dynamic, Adaptive Streaming over HTTP Server:  Divides video file into multiple chunks  Each chunk stored, encoded at different rates  Manifest file: provides URLs for different chunks Client:  Periodically measures server-to-client bandwidth  Consulting manifest, requests one chunk at a time ◦Chooses maximum coding rate sustainable given current bandwidth ◦Can choose different coding rates at different points in time (depending on available bandwidth at time) MULTIMEDIA NETWORKING 17
  • DASH Cont.…………… DASH: Dynamic, Adaptive Streaming over HTTP “intelligence” at client: client determines ◦When to request chunk (so that buffer starvation, or overflow does not occur) ◦What encoding rate to request (higher quality when more bandwidth available) ◦Where to request chunk (can request from URL server that is “close” to client or has high available bandwidth) MULTIMEDIA NETWORKING 18
  • Content Distribution Networks (CDN) Challenge: How to stream content (selected from millions of videos) to hundreds of thousands of simultaneous and distributed users? Option 1: Build single, large “Mega-Server” Drawbacks ◦Single point of failure ◦Point of network congestion ◦Long path to distant clients ◦Multiple copies of video sent over outgoing link This solution: Use of Content Distribution Networks (CDNs) MULTIMEDIA NETWORKING 18
  • Content Distribution Networks Challenge: How to stream content (selected from millions of videos) to hundreds of thousands of simultaneous users? Option 2: Store/Serve multiple copies of videos at multiple geographically distributed sites (CDN) Enter deep: Push CDN servers deep into many access networks ◦Close to users ◦Used by Akamai, 1700 locations Bring home: smaller number (10’s) of larger clusters in POPs near (but not within) access networks ◦Used by Limelight MULTIMEDIA NETWORKING 20
  • CDN Cont.…………… CDN manages servers in multiple geographically distributed locations. Stores copies of the videos (and other types of Web content, documents, images, and audio).  Direct each user request to a CDN location that will provide the best user experience. MULTIMEDIA NETWORKING 21
  • CDN: Simple Operation Bob (client) requests video http://netcinema.com/6Y7B23V Video stored in CDN at http://KingCDN.com/NetC6y&B23V 1. Bob gets URL for for video http://netcinema.com/6Y7B23V from netcinema.com web page 2 1 6. request video from KINGCDN server, streamed via HTTP netcinema.com netcinema’s authorative DNS 2. resolve http://netcinema.com/6Y7B23V via Bob’s local DNS 5 3. netcinema’s DNS returns URL http://KingCDN.com/NetC6y&B23V 3 4 4&5. Resolve http://KingCDN.com/NetC6y&B23 via KingCDN’s authoritative DNS, which returns IP address of KIingCDN server with video KingCDN authoritative DNS KingCDN.com MULTIMEDIA NETWORKING
  • CDN Cluster Selection Strategy Challenge: how does CDN DNS select “good” CDN node to stream to client ◦Pick CDN node geographically closest to client ◦Pick CDN node with shortest delay (or min # hops) to client (CDN nodes periodically ping access ISPs, reporting results to CDN DNS) ◦IP anycast Alternative: Let client decide - give client a list of several CDN servers ◦Client pings servers, picks “best” ◦Netflix approach MULTIMEDIA NETWORKING 23
  • Case study: Netflix 30% downstream US traffic in 2011 owns very little infrastructure, uses 3rd party services:  own registration, payment servers  Amazon (3rd party) cloud services: ◦Netflix uploads studio master to Amazon cloud ◦create multiple version of movie (different endodings) in cloud ◦Upload versions from cloud to CDNs ◦Cloud hosts Netflix web pages for user browsing  Three 3rd party CDNs host/stream Netflix content: Akamai, Limelight, Level-3 MULTIMEDIA NETWORKING 24
  • Case Study: Netflix upload copies of multiple versions of video to CDNs Amazon cloud Netflix registration, accounting servers 2. Bob browses Netflix video 2 3. Manifest file returned for requested video Akamai CDN Limelight CDN 3 1 1. Bob manages account Netflix 4. DASH streaming MULTIMEDIA NETWORKING Level-3 CDN 25
  • Voice-Over-IP Involves taking analog audio signals and converting them into digital data which can be transmitted over the Internet.  Voice telephony over the internet Example: the sender generates bytes at a rate of 8,000 bytes per second; every 20 msecs the sender gathers these bytes into a chunk. A chunk and a special header are encapsulated in a UDP segment.  UDP segment is sent every 20 msecs. When each packet manages to get to the receiver with a continuous end-to-end delay, then packets arrive at the receiver occasionally every 20 msecs.  Receiver plays back each chunk as it is received Problem: some packets get lost and don’t have the same end-to-end delay MULTIMEDIA NETWORKING 26
  • LIMITATIONS OF VoIP: PACKET LOSS The UDP segment is encapsulated in an IP datagram. While datagram moves through network, it goes through router buffers as it waits for transmission on outbound links.  Problem: One or more of the buffers in the path from sender to receiver may be full therefore arriving IP datagram may be discarded (not arrive to receiver) This loss can be removed by using TCP rather than UDP  Problem: This retransmission increases end-to-end delay  Upside: Loss of packets between 1 and 20 can be tolerated depending on how loss is obscured at receiver and voice encoding MULTIMEDIA NETWORKING 27
  • END-TO-END DELAY Accumulation of transmission, processing, and queuing delays in routers; propagation delays in links; and end-system processing delays. For real-time conversational applications, end-to-end delays;  Under 150 msecs are not known to a human listener (good)  Between 150 and 400 msecs can be acceptable though not good (bad)  Above 400 msecs can be problematic in voice conversations. (really bad) Packets delayed for a very long time may be effectively lost by receiver MULTIMEDIA NETWORKING 28
  • PACKET JITTER During end-to-end delays there are varying queuing delays that a packet faces in the network’s routers. As a result of these delays, the time between sending and receiving a packet can fluctuate from packet to packet which is referred to as packet jitter. Difference between the two consecutive packets may be more or less than 20msec Once jitters are ignored by receivers and chunks are played out as they come, then the audio quality can become meaningless to the receiver.  Upside: jitters can be removed by using sequence numbers, timestamps, and a playout delay MULTIMEDIA NETWORKING 29
  • REMOVING JITTERS: FIXED PLAYOUT DELAY Receiver attempts to play out each chunk exactly q msecs after the chunk is generated. Chunk is timestamped at the sender at time t Receiver plays out the chunk at time t + q, if chunk has arrived by stipulated time. Packets that arrive late are lost. Variation of q  Large q: less packet loss  Small q: Better conversational experience  q much smaller than 400msec: high packet loss MULTIMEDIA NETWORKING 30
  • ADAPTIVE PLAYOUT DELAY With large initial playout delays, most packets will make their deadlines hence there will be slight loss;  Problem: in conversational services such as VoIP, long delays may become annoying and intolerable so playout delay should be minimized so as to decrease the loss percentage. So as to address the above problem, there should be an estimate of the network delay and the variance of the network delay. Sender’s silent periods should be condensed and elongated So as to estimate the network delay; the algorithm below is used by the receiver di = (1 – u) di–1 + u (ri – ti) Average network delay after ith packet fixed constant, e.g. 0.1 time received time sent (timestamp) end-to-end delay of ith packet MULTIMEDIA NETWORKING 31
  • RECOVERING FROM PACKET LOSS Retransmitting lost packets may not be practical in a real-time conversational application such as VoIP and may not easily be accomplished on time for the conversation to remain understandable. VoIP applications use forward error correction (FEC) and interleaving to anticipate loss. FEC  Add redundant information to original packet stream which is used to reconstruct exact or approximate version of lost packet. Simple FEC  when a group on n chunks are sent, add redundant encoded chunk by exclusive OR-ing the n original chunks If a packet from a group of n + 1 packets is lost, the receiver is able reconstruct the lost packet.  Problem: If two or more packets in a group are lost, the receiver cannot reconstruct the lost packets. Transmission rate will be increased by a factor of 1/n if n + 1 group size is small. Play out delay increased because receiver has to wait for the whole group of packets to begin play out MULTIMEDIA NETWORKING 32
  • RECOVERING FROM PACKET LOSS Another mechanism under FEC  send a lower-resolution audio stream as the redundant information. For example  Stream PCM encoding at 64 kbps (nominal stream) with low resolution audio, a GSM encoding at 13kbps) sender creates the nth packet when it takes nth chunk from the nominal stream and appends it to the (n – 1)st redundant chunk (low bit rate) Receiver conceals loss by playing out low bit rate chunk if nonconsecutive packet loss occurs. Low bit rate chunks give less quality than nominal chunks. MULTIMEDIA NETWORKING 33
  • RECOVERING FROM PACKET LOSS Interleaving Before transmission, sender breaks down the audio parts and separates packets by a certain distance in stream.  This lowers the effects of packet loss because loss of packet results in smaller gaps in the reconstructed stream compared to if the gaps is large Error concealment  Produce replacement for lost packet that is similar to the original  Works because audio signals are usually almost the same in short term.  Works for small loss rates (less than 15 percent) and for small packets (4–40 msecs). Packet repetition can also be used for recovery from packet loss where lost packets are replaced with copies that arrive immediately before loss. MULTIMEDIA NETWORKING 34
  • VoIP APPLICATION: SKYPE It’s a proprietary application  control and media packets are encrypted Sends audio and video packets over UDP but control packets are sent over TCP as well as media packets once UDP streams are blocked by firewalls. Uses FEC for packet loss recovery (voice and video streams) sent over UDP. Uses P2P where peers communicate with each other in real time.  Important for also determining user location Peers are organized into a hierarchical overlay network (super peer or an ordinary peer). Keeps an index that maps Skype usernames to current IP addresses (and port numbers)  Index is distributed over the super peers. MULTIMEDIA NETWORKING 35
  • MULTIMEDIA NETWORKING PROTOCOLS There are some protocols that are used to support real time traffic over the internet. The following named protocols will be discussed: RTP (Real Time Protocol) RTCP (Real Time Control Protocol) SIP (Session Initiation protocol) RTSP (Real Time Streaming Protocol) MULTIMEDIA NETWORKING 36
  • RTP This protocol is used for real time data transport, in this case video and audio. It specifies a standard packet format for delivering audio and video over IP networks. The Audio-Video Transport Working Group of the Internet Engineering Task Force (IETF) developed RTP and was first published in 1996 as RFC 1889 but this was later superseded by RFC 3550 in 2003. MULTIMEDIA NETWORKING 37
  • RTP PROTOCOL COMPONENTS The following information is needed to send streaming data:  Timestamps (for synchronization),  Sequence numbers (for packet loss and reordering detection)  The payload format which indicates the encoded format of the data.  Frame Indication (this marks the beginning and end of each frame).  Source identification (identifies the originator of the frame) MULTIMEDIA NETWORKING 38
  • RTP runs on UDP Cont’d MULTIMEDIA NETWORKING 39
  • RTP Header Fields (Optional) MULTIMEDIA NETWORKING 40
  • RTP – Time Stamp, Sequence Number and Source Identifier Sequence number field.  The sequence number field is 16 bits long. The sequence number increments by one for each RTP packet sent, and may be used by the Timestamp field.  The timestamp field is 32 bits long. It reflects the sampling instant of the first byte in the RTP data packet.  Timestamp clock rate for video is 90,000 Hz and the timestamp clock rate for audio 8000 Hz.  Synchronization source identifier (SSRC).  The SSRC field is 32 bits long. It identifies the source of the RTP stream. Typically, each stream in an RTP session has a distinct SSRC. MULTIMEDIA NETWORKING 41
  • Why RTP can not use TCP TCP forces the receiver application to wait for retransmission(s) in case of packet loss, which causes large delays. TCP cannot support multicast.  TCP headers are larger than a UDP header (40 bytes for TCP compared to 8 bytes for UDP). TCP doesn’t contain the necessary timestamp and encoding information needed by the receiving application. MULTIMEDIA NETWORKING 42
  • RTCP – Real Time Control Protocol RTP is a protocol that provides basic transport layer for real time applications but does not provide any mechanism for error and flow control, congestion control, quality feedback and synchronization. For that purpose the RTCP is added as a companion to RTP to provide end-to-end monitoring and data delivery, and QoS. RTCP is responsible for three main functions:  Feedback on performance of the application and the network  Correlation and synchronization of different media streams generated by the same sender (e.g. combined audio and video)  The way to convey the identity of sender for display on a user interface MULTIMEDIA NETWORKING 43
  • RTCP Components  Quality of service (QoS)  Feedback: Includes the numbers of lost packets, round-trip time, and jitter, so that the sources can adjust their data rates accordingly; Session control: uses the RTCP BYE packet to allow participants to indicate that they are leaving a session; Identification, which includes a participant's name, e-mail address, and telephone number for the information of other participants; I Intermedia synchronization, which enables the synchronization of separately transmitted audio and video streams. MULTIMEDIA NETWORKING 44
  • SIP – Session Initiation Protocol SIP is a text-based transaction protocol similar to HTTP. It uses commands (called methods) and responses. This lightweight protocol provides mechanisms that make it possible to make calls over an IP network. Peer-to-peer application protocol transported via UDP or TCP Designed to establish, modify and terminate stateful multimedia communication sessions/conferences/instant messaging …) MULTIMEDIA NETWORKING 45
  • SIP Commands SIP Responses MULTIMEDIA NETWORKING 46
  • Setting up a call to a known IP Address MULTIMEDIA NETWORKING 47
  • SIP Cont’d User Agent  User agent client (end-device, calling party)  User agent server (end-device, called party) SIP Proxy Server  An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted user. SIP Registrar  Maintains user’s whereabouts in location database (location service). It is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles. MULTIMEDIA NETWORKING 48
  • RTSP – Real Time Streaming Protocol This is protocol is used to enhance control in streaming media servers in the entertainment and communications industry. It provides “network remote control”. RTSP messages are sent out of band over port 544 Works with unicast and multicast RTSP doesn’t mandate encapsulation. Can be proprietary over UDP or TCP, or RTP (preferred) Clients of media servers issue VCR-like commands, such as play and pause, to facilitate real-time control of playback of media files from the server. MULTIMEDIA NETWORKING 49
  • RTSP – Cont’d MULTIMEDIA NETWORKING 50
  • Network Support for Multimedia Observed how application-level mechanisms are used by multimedia applications to improve multimedia performance. Also learned how content distribution networks and P2P overlay networks provide a system-level approach for delivering multimedia content. Such techniques and approaches are all designed to be used in today’s besteffort Internet. Internet provides only a single, best-effort class of service. MULTIMEDIA NETWORKING 51
  • Network Support for Multimedia There are three approaches  Making the best of best-effort service.  Differentiated service.  Per-connection Quality-of-Service (QoS) Guarantees. MULTIMEDIA NETWORKING 52
  • Dimensioning Best-Effort Networks Approaches to improving the quality of networked multimedia Provide enough link capacity throughout the network  Such that network congestion, and its consequent packet delay and loss never occur  No queuing delay or loss. Drawbacks:  Bandwidth Provisioning. o How much capacity to provide at network links  Network Dimensioning o How to design a network topology MULTIMEDIA NETWORKING 53
  • Providing Enough Capacity Issues to be addressed in order to predict application-level performance between two network end points;  Models of traffic demand between network end points.  Well-defined performance requirements.  Models to predict end-to-end performance for a given workload model, and techniques to find a minimal cost bandwidth allocation that will result in all user requirements being met. MULTIMEDIA NETWORKING 54
  • Providing Multiple Classes of Service Simplest development to the one-size-fits-all best-effort service model is;  To divide traffic into classes,  Provide different levels of service to these different classes of traffic. motivating scenarios. H1 H2 H3 R1 R1 output interface queue R2 1.5 Mbps link MULTIMEDIA NETWORKING H4 55
  • Scenario 1: mixed HTTP and VoIP Example: 1Mbps VoIP, HTTP share 1.5 Mbps link.  HTTP bursts can congest router, cause audio loss  In the best-effort Internet-transmitted in a first-in-first-out (FIFO) order  How should we solve this potential problem?  want to give priority to audio over HTTP R1 R2 Insight 1: Packet marking allows a router to distinguish among packets belonging to different classes of traffic . MULTIMEDIA NETWORKING 56
  • Scenario 1: Mixed HTTP and VoIP Suppose: Router is configured to give priority to packets marked as belonging to the 1 Mbps audio application. What happens if the audio application starts sending packets at a rate of 1.5 Mbps or higher? Similarly; If multiple applications (for example, multiple audio calls), were sharing the link’s bandwidth; they too could collectively starve the FTP session. Ideally; Need a degree of isolation among classes of traffic so that one class of traffic can be protected from the other. Insight 2: It is desirable to provide a degree of traffic isolation among classes so that one class is not adversely affected by another class of traffic that misbehaves. MULTIMEDIA NETWORKING 57
  • Traffic isolation Mechanisms Traffic policing  Policing mechanism ensures that these criteria are indeed observed.  Policed application misbehaves-policing mechanism takes some action.  Traffic entering the network conforms to the criteria. Marking & Policing - network edge 1 Mbps phone R1 R2 1.5 Mbps link packet marking and policing MULTIMEDIA NETWORKING 58
  • Traffic isolation Mechanisms; Cont. Link-level packet-scheduling  Explicitly allocate a fixed amount of link bandwidth to each class A class only uses the amount of bandwidth that has been allocated Wastes bandwidth 1 Mbps phone 1 Mbps logical link R1 R2 1.5 Mbps link 0.5 Mbps logical link Insight 3: While providing isolation among classes or flows, it is desirable to use resources (for example, link bandwidth and buffers) as efficiently as possible. MULTIMEDIA NETWORKING 59
  • Scheduling Mechanisms Link-scheduling discipline is the manner in which queued packets are selected for transmission on the link. First-In-First-Out (FIFO) o Packets are send in order of arrival to queue.  Packet-discarding policy:  If there is not space for the arriving packets, determines whether; o the packet will be dropped (lost) - tail drop o other packets will be removed from the queue to make space for the arriving packet ◦ priority: drop/remove on priority basis ◦ random: drop/remove randomly packet arrivals queue (waiting area) link (server) MULTIMEDIA NETWORKING packet departures 60
  • Scheduling Mechanisms: cont. Priority Queuing  Packets arriving at the output link are classified into priority classes at the output queue.  Packet’s priority depends: o Explicit marking ,destination IP address or destination port number.  Each priority class typically has its own queue.  Choosing a packet to transmit, from the highest priority class  The choice among packets in the same priority class is typically done in a FIFO manner 2 high priority queue (waiting area) 1 5 4 3 arrivals arrivals departures packet in service classify low priority queue (waiting area) link (server) 1 4 2 3 5 departures 1 MULTIMEDIA NETWORKING 3 2 4 5 61
  • Scheduling Mechanisms: Cont. Round Robin  Packets are sorted into classes as with priority queuing.  Round Robin scheduler alternates service among the classes.  A work-conserving queuing discipline will never allow the link to remain idle whenever there are packets (of any class) queued for transmission. 2 1 5 4 3 arrivals packet in service 1 2 3 4 5 departures 1 3 3 4 MULTIMEDIA NETWORKING 5 62
  • Scheduling Mechanisms: cont. MULTIMEDIA NETWORKING 63
  • Policing Mechanisms -The Leaky Bucket MULTIMEDIA NETWORKING 64
  • The Leaky Bucket - Implementation Before a packet is transmitted into the network, it must first remove a token from the token bucket. If the token bucket is empty, the packet must wait for a token. The maximum burst size for a leaky-bucket policed flow is b packets. The token generation rate is r The maximum number of packets that can enter the network of any interval of time of length t is rt + b. MULTIMEDIA NETWORKING 65
  • Diffserv Provides service differentiation The ability to handle different classes of traffic in different ways within the Internet in a scalable manner. Need for scalability arises from:  The fact that millions of simultaneous source-destination traffic flows may be present at a backbone router. The Diffserv architecture consists of two sets of functional elements: Edge functions: packet classification and traffic conditioning. At the incoming edge of the network arriving packets are marked. Marks packets as in-profile and out-profile Core function: forwarding. DS-marked packet arrives at a Diffserv MULTIMEDIA NETWORKING capable router, 66
  • Diffserv Architecture  The packet is forwarded onto its next hop according to the per-hop behavior (PHB) associated with that packet’s class.  Buffering and scheduling based on marking at edge.  Preference given to in-profile packets over out-of-profile packets MULTIMEDIA NETWORKING 67
  • PHB - Per-Hop Behavior Key component of the Diffserv architecture PHB is a description of the externally observable forwarding behavior of a Diffserv node applied to a particular Diffserv behavior aggregate” Important considerations embedded within:  A PHB can result in different classes of traffic receiving different performance/behaviors  It does not mandate any particular mechanism for achieving these behaviors.  Differences in performance must be observable and hence measurable. Two PHBs have been defined: Expedited forwarding • PHB specifies that the departure rate of a class of traffic from a router must equal or exceed a configured rate. Assured forwarding • Divides traffic into four classes, where each AF class is guaranteed to be provided with some minimum amount of bandwidth and buffering. MULTIMEDIA NETWORKING 68
  • Per-Connection (QoS) Guarantees 1 Mbps phone 1 Mbps phone R1 R2 1.5 Mbps link MULTIMEDIA NETWORKING 69
  • Per-Connection (QoS) Guarantees: Cont. If a call is to be guaranteed a given quality of service once it begins, The Network mechanisms and protocols needed are: Resource reservation. Process to guarantee that a call will have the resources (link bandwidth, buffers) needed to meet its desired QoS is to explicitly allocate those resources to the call. Call admission. If resources are to be reserved, then the network must have a mechanism for calls to request and reserve resources. Call setup signaling. The call admission process described requires that a call be able to reserve sufficient resources at each and every network router on its sourceto-destination path to ensure that its end-to-end QoS requirement is met. MULTIMEDIA NETWORKING 70
  • The End THANK YOU FOR LISTENING MULTIMEDIA NETWORKING 71