《计算机网络课件：Chapter7 Multimedia Networking》由会员分享，可在线阅读，更多相关《计算机网络课件：Chapter7 Multimedia Networking（102页珍藏版）》请在金锄头文库上搜索。
1、Chapter 7Multimedia NetworkingA note on the use of these ppt slides:Were making these slides freely available to all (faculty, students, readers). Theyre in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a
2、 lot of work on our part. In return for use, we only ask the following:q If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, wed like people to use our book!)q If you post any slides in substantially unaltered form on a www site, that
3、 you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.Thanks and enjoy! JFK / KWRAll material copyright 1996-2007J.F Kurose and K.W. Ross, All Rights ReservedComputer Networking: A Top Down Approach 4th edition. Jim Kurose, Keith RossAddis
4、on-Wesley, July 2007. 17: Multimedia NetworkingMultimedia and Quality of Service: What is it?multimedia applications: network audio and video(“continuous media”)network provides application with level of performance needed for application to function.QoS27: Multimedia NetworkingChapter 7: goalsPrinc
5、iplesrclassify multimedia applicationsridentify network services applications needrmaking best of the best effort serviceProtocols and Architectures rspecific protocols for best-effortrmechanisms for providing QoSrarchitectures for QoS37: Multimedia NetworkingChapter 7 outline7.1 multimedia networki
6、ng applications7.2 streaming stored audio and video7.3 making the best out of best effort service7.4 protocols for real-time interactive applications RTP,RTCP,SIP7.5 providing multiple classes of service7.6 providing QoS guarantees 47: Multimedia NetworkingMM Networking Applications Fundamental char
7、acteristics:rtypically delay sensitivemend-to-end delaymdelay jitter rloss tolerant: infrequent losses cause minor glitches rantithesis of data, which are loss intolerant but delay tolerant.Classes of MM applications:1) stored streaming2) live streaming3) interactive, real-timeJitter is the variabil
8、ity of packet delays within the same packet stream57: Multimedia NetworkingStreaming Stored Multimedia Stored streaming: rmedia stored at sourcertransmitted to clientrstreaming: client playout begins before all data has arrivedrtiming constraint for still-to-be transmitted data: in time for playout6
9、7: Multimedia NetworkingStreaming Stored Multimedia: What is it?1. videorecorded2. videosent3. video received,played out at clientCumulative datastreaming: at this time, client playing out early part of video, while server still sending laterpart of videonetworkdelaytime77: Multimedia NetworkingStre
10、aming Stored Multimedia: InteractivityrVCR-like functionality: client can pause, rewind, FF, push slider barm10 sec initial delay OKm1-2 sec until command effect OKrtiming constraint for still-to-be transmitted data: in time for playout87: Multimedia NetworkingStreaming Live MultimediaExamples:rInte
11、rnet radio talk showrlive sporting eventStreaming (as with streaming stored multimedia)rplayback bufferrplayback can lag tens of seconds after transmissionrstill have timing constraintInteractivityrfast forward impossiblerrewind, pause possible!97: Multimedia NetworkingReal-Time Interactive Multimed
12、ia rend-end delay requirements:maudio: 150 msec good, 64,000 bpsrreceiver converts bits back to analog signal:msome quality reductionExample ratesrCD: 1.411 MbpsrMP3: 96, 128, 160 kbpsrInternet telephony: 5.3 kbps and up137: Multimedia NetworkingA few words about video compressionrvideo: sequence of
13、 images displayed at constant rateme.g. 24 images/secrdigital image: array of pixelsmeach pixel represented by bitsrredundancymspatial (within image)mtemporal (from one image to next)Examples:rMPEG 1 (CD-ROM) 1.5 MbpsrMPEG2 (DVD) 3-6 MbpsrMPEG4 (often used in Internet, 1 Mbps)Research:rlayered (scal
14、able) videomadapt layers to available bandwidth147: Multimedia NetworkingChapter 7 outline7.1 multimedia networking applications7.2 streaming stored audio and video7.3 making the best out of best effort service7.4 protocols for real-time interactive applications RTP,RTCP,SIP7.5 providing multiple cl
15、asses of service7.6 providing QoS guarantees 157: Multimedia NetworkingStreaming Stored Multimediaapplication-level streaming techniques for making the best out of best effort service:m client-side bufferingm use of UDP versus TCPm multiple encodings of multimedia rjitter removalrdecompressionrerror
16、 concealmentrgraphical user interface w/ controls for interactivityMedia Player167: Multimedia NetworkingInternet multimedia: simplest approachaudio, video not streamed:r no, “pipelining,” long delays until playout!raudio or video stored in filerfiles transferred as HTTP objectmreceived in entirety
17、at clientmthen passed to player177: Multimedia NetworkingInternet multimedia: streaming approachrbrowser GETs metafilerbrowser launches player, passing metafilerplayer contacts serverrserver streams audio/video to player 187: Multimedia NetworkingStreaming from a streaming serverrallows for non-HTTP
18、 protocol between server, media playerrUDP or TCP for step (3), more shortly197: Multimedia Networking constant bit rate videotransmissionCumulative datatimevariablenetworkdelayclient videoreception constant bit rate video playout at clientclient playoutdelaybufferedvideoStreaming Multimedia: Client
19、 Bufferingrclient-side buffering, playout delay compensate for network-added delay, delay jitter207: Multimedia NetworkingStreaming Multimedia: Client Bufferingrclient-side buffering, playout delay compensate for network-added delay, delay jitterbufferedvideovariable fillrate, x(t)constant drainrate
20、, d217: Multimedia NetworkingStreaming Multimedia: UDP or TCP?UDP rserver sends at rate appropriate for client (oblivious to network congestion !)moften send rate = encoding rate = constant ratemthen, fill rate = constant rate - packet lossrshort playout delay (2-5 seconds) to remove network jitterr
21、error recover: time permittingTCPrsend at maximum possible rate under TCPrfill rate fluctuates due to TCP congestion controlrlarger playout delay: smooth TCP delivery raterHTTP/TCP passes more easily through firewalls227: Multimedia NetworkingStreaming Multimedia: client rate(s)Q: how to handle diff
22、erent client receive rate capabilities?m28.8 Kbps dialupm100 Mbps EthernetA: server stores, transmits multiple copies of video, encoded at different rates1.5 Mbps encoding28.8 Kbps encoding237: Multimedia NetworkingUser Control of Streaming Media: RTSP HTTPrdoes not target multimedia contentrno comm
23、ands for fast forward, etc.RTSP: RFC 2326rclient-server application layer protocolruser control: rewind, fast forward, pause, resume, repositioning, etcWhat it doesnt do:rdoesnt define how audio/video is encapsulated for streaming over networkrdoesnt restrict how streamed media is transported (UDP o
24、r TCP possible)rdoesnt specify how media player buffers audio/video247: Multimedia NetworkingRTSP: out of band controlFTP uses an “out-of-band” control channel:rfile transferred over one TCP connection.rcontrol info (directory changes, file deletion, rename) sent over separate TCP connectionr “out-o
25、f-band”, “in-band” channels use different port numbersRTSP messages also sent out-of-band:r RTSP control messages use different port numbers than media stream: out-of-band.mport 554rmedia stream is considered “in-band”.257: Multimedia NetworkingRTSP ExampleScenario:rmetafile communicated to web brow
26、serrbrowser launches playerrplayer sets up an RTSP control connection, data connection to streaming server267: Multimedia NetworkingMetafile ExampleTwister 277: Multimedia NetworkingRTSP Operation287: Multimedia NetworkingRTSP Exchange Example C: SETUP rtsp:/ RTSP/1.0 Transport: rtp/udp; compression
27、; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp:/ RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp:/ RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp:/ RTSP/1.0 Session: 4231 S: 200 3 OK297: Multimedia NetworkingChapter 7 outline7.1 multimedia networking applications7.2
28、streaming stored audio and video7.3 making the best out of best effort service7.4 protocols for real-time interactive applications RTP,RTCP,SIP7.5 providing multiple classes of service7.6 providing QoS guarantees 307: Multimedia NetworkingReal-time interactive applicationsrPC-2-PC phonemSkyperPC-2-p
29、honemDialpadmNet2phonemSkypervideoconference with webcamsmSkypemPolycom Going to now look at a PC-2-PC Internet phone example in detail317: Multimedia NetworkingInteractive Multimedia: Internet PhoneIntroduce Internet Phone by way of an example rspeakers audio: alternating talk spurts, silent period
30、s.m64 kbps during talk spurtmpkts generated only during talk spurtsm20 msec chunks at 8 Kbytes/sec: 160 bytes datarapplication-layer header added to each chunk.rchunk+header encapsulated into UDP segment.rapplication sends UDP segment into socket every 20 msec during talkspurt327: Multimedia Network
31、ingInternet Phone: Packet Loss and Delayrnetwork loss: IP datagram lost due to network congestion (router buffer overflow)rdelay loss: IP datagram arrives too late for playout at receivermdelays: processing, queueing in network; end-system (sender, receiver) delaysmtypical maximum tolerable delay: 4
32、00 msrloss tolerance: depending on voice encoding, losses concealed, packet loss rates between 1% and 10% can be tolerated.337: Multimedia Networking constant bit ratetransmissionCumulative datatimevariablenetworkdelay(jitter)clientreception constant bit rate playout at clientclient playoutdelaybuff
33、ereddataDelay Jitterrconsider end-to-end delays of two consecutive packets: difference can be more or less than 20 msec (transmission time difference)347: Multimedia NetworkingInternet Phone: Fixed Playout Delayrreceiver attempts to playout each chunk exactly q msecs after chunk was generated.mchunk
34、 has time stamp t: play out chunk at t+q .mchunk arrives after t+q: data arrives too late for playout, data “lost”rtradeoff in choosing q:mlarge q: less packet lossmsmall q: better interactive experience357: Multimedia NetworkingFixed Playout Delay sender generates packets every 20 msec during talk
35、spurt. first packet received at time r first playout schedule: begins at p second playout schedule: begins at p367: Multimedia NetworkingAdaptive Playout Delay (1)dynamic estimate of average delay at receiver:where u is a fixed constant (e.g., u = .01).rGoal: minimize playout delay, keeping late los
36、s rate lowrApproach: adaptive playout delay adjustment:mestimate network delay, adjust playout delay at beginning of each talk spurt. msilent periods compressed and elongated.mchunks still played out every 20 msec during talk spurt.377: Multimedia NetworkingAdaptive playout delay (2)q also useful to
37、 estimate average deviation of delay, vi :q estimates di , vi calculated for every received packet (but used only at start of talk spurtq for first packet in talk spurt, playout time is: where K is positive constantq remaining packets in talkspurt are played out periodically387: Multimedia Networkin
38、gAdaptive Playout (3)Q: How does receiver determine whether packet is first in a talkspurt?rif no loss, receiver looks at successive timestamps.mdifference of successive stamps 20 msec -talk spurt begins.rwith loss possible, receiver must look at both time stamps and sequence numbers.mdifference of
39、successive stamps 20 msec and sequence numbers without gaps - talk spurt begins.397: Multimedia NetworkingRecovery from packet loss (1)Forward Error Correction (FEC): simple schemerfor every group of n chunks create redundant chunk by exclusive OR-ing n original chunksrsend out n+1 chunks, increasin
40、g bandwidth by factor 1/n.rcan reconstruct original n chunks if at most one lost chunk from n+1 chunksrplayout delay: enough time to receive all n+1 packetsrtradeoff: mincrease n, less bandwidth wastemincrease n, longer playout delaymincrease n, higher probability that 2 or more chunks will be lost4
41、07: Multimedia NetworkingRecovery from packet loss (2)2nd FEC schemeq “piggyback lower quality stream” q send lower resolutionaudio stream as redundant informationq e.g., nominal stream PCM at 64 kbpsand redundant streamGSM at 13 kbps.q whenever there is non-consecutive loss, receiver can conceal th
42、e loss. q can also append (n-1)st and (n-2)nd low-bit rate chunk417: Multimedia NetworkingRecovery from packet loss (3)Interleavingrchunks divided into smaller unitsrfor example, four 5 msec units per chunkrpacket contains small units from different chunksrif packet lost, still have most of every ch
43、unkrno redundancy overhead, but increases playout delay427: Multimedia NetworkingContent distribution networks (CDNs)Content replicationrchallenging to stream large files (e.g., video) from single origin server in real timersolution: replicate content at hundreds of servers throughout Internetmconte
44、nt downloaded to CDN servers ahead of timemplacing content “close” to user avoids impairments (loss, delay) of sending content over long pathsmCDN server typically in edge/access networkorigin server in North AmericaCDN distribution nodeCDN serverin S. AmericaCDN serverin EuropeCDN serverin Asia437:
45、 Multimedia NetworkingContent distribution networks (CDNs)Content replicationrCDN (e.g., Akamai) customer is the content provider (e.g., CNN)rCDN replicates customers content in CDN servers. rwhen provider updates content, CDN updates serversorigin server in North AmericaCDN distribution nodeCDN ser
46、verin S. AmericaCDN serverin EuropeCDN serverin Asia447: Multimedia NetworkingCDN exampleorigin server ()rdistributes HTMLrreplaces: http:/ with http:/ request for query for HTTP request for serverCDNs authoritative DNS server CDN server near clientCDN company ()rdistributes gif filesruses its aut
47、horitative DNS server to route redirect requestsclient457: Multimedia NetworkingMore about CDNsrouting requestsrCDN creates a “map”, indicating distances from leaf ISPs and CDN nodesrwhen query arrives at authoritative DNS server:mserver determines ISP from which query originatesmuses “map” to deter
48、mine best CDN serverrCDN nodes create application-layer overlay network467: Multimedia NetworkingSummary: Internet Multimedia: bag of tricksruse UDP to avoid TCP congestion control (delays) for time-sensitive trafficrclient-side adaptive playout delay: to compensate for delayrserver side matches str
49、eam bandwidth to available client-to-server path bandwidthmchose among pre-encoded stream ratesmdynamic server encoding ratererror recovery (on top of UDP)mFEC, interleaving, error concealmentmretransmissions, time permittingrCDN: bring content closer to clients477: Multimedia NetworkingChapter 7 ou
50、tline7.1 multimedia networking applications7.2 streaming stored audio and video7.3 making the best out of best effort service7.4 protocols for real-time interactive applications RTP, RTCP, SIP7.5 providing multiple classes of service7.6 providing QoS guarantees 487: Multimedia NetworkingReal-Time Pr
51、otocol (RTP)rRTP specifies packet structure for packets carrying audio, video datarRFC 3550rRTP packet provides mpayload type identificationmpacket sequence numberingmtime stampingrRTP runs in end systemsrRTP packets encapsulated in UDP segmentsrinteroperability: if two Internet phone applications r
52、un RTP, then they may be able to work together497: Multimedia NetworkingRTP runs on top of UDPRTP libraries provide transport-layer interface that extends UDP: port numbers, IP addresses payload type identification packet sequence numbering time-stamping507: Multimedia NetworkingRTP Examplerconsider
53、 sending 64 kbps PCM-encoded voice over RTP. rapplication collects encoded data in chunks, e.g., every 20 msec = 160 bytes in a chunk. raudio chunk + RTP header form RTP packet, which is encapsulated in UDP segment rRTP header indicates type of audio encoding in each packetm sender can change encodi
54、ng during conference. rRTP header also contains sequence numbers, timestamps.517: Multimedia NetworkingRTP and QoSrRTP does not provide any mechanism to ensure timely data delivery or other QoS guarantees. rRTP encapsulation is only seen at end systems (not) by intermediate routers. mrouters providi
55、ng best-effort service, making no special effort to ensure that RTP packets arrive at destination in timely matter. 527: Multimedia NetworkingRTP HeaderPayload Type (7 bits): Indicates type of encoding currently being used. If sender changes encoding in middle of conference, sender informs receiver
56、via payload type field. Payload type 0: PCM mu-law, 64 kbpsPayload type 3, GSM, 13 kbpsPayload type 7, LPC, 2.4 kbpsPayload type 26, Motion JPEGPayload type 31. H.261Payload type 33, MPEG2 videoSequence Number (16 bits): Increments by one for each RTP packet sent, and may be used to detect packet lo
57、ss and to restore packet sequence.537: Multimedia NetworkingRTP Header (2)rTimestamp field (32 bytes long): sampling instant of first byte in this RTP data packetmfor audio, timestamp clock typically increments by one for each sampling period (for example, each 125 usecs for 8 KHz sampling clock) mi
58、f application generates chunks of 160 encoded samples, then timestamp increases by 160 for each RTP packet when source is active. Timestamp clock continues to increase at constant rate when source is inactive.rSSRC field (32 bits long): identifies source of t RTP stream. Each stream in RTP session s
59、hould have distinct SSRC. 547: Multimedia NetworkingRTSP/RTP Programming Assignmentrbuild a server that encapsulates stored video frames into RTP packetsmgrab video frame, add RTP headers, create UDP segments, send segments to UDP socketminclude seq numbers and time stampsmclient RTP provided for yo
60、uralso write client side of RTSPmissue play/pause commandsmserver RTSP provided for you557: Multimedia NetworkingReal-Time Control Protocol (RTCP)rworks in conjunction with RTP. reach participant in RTP session periodically transmits RTCP control packets to all other participants. reach RTCP packet
61、contains sender and/or receiver reportsmreport statistics useful to application: # packets sent, # packets lost, interarrival jitter, etc.rfeedback can be used to control performancemsender may modify its transmissions based on feedback567: Multimedia NetworkingRTCP - Continuedq each RTP session: ty
62、pically a single multicast address; all RTP /RTCP packets belonging to session use multicast address.q RTP, RTCP packets distinguished from each other via distinct port numbers. q to limit traffic, each participant reduces RTCP traffic as number of conference participants increases 577: Multimedia N
63、etworkingRTCP PacketsReceiver report packets:r fraction of packets lost, last sequence number, average interarrival jitterSender report packets: rSSRC of RTP stream, current time, number of packets sent, number of bytes sent Source description packets: re-mail address of sender, senders name, SSRC o
64、f associated RTP stream rprovide mapping between the SSRC and the user/host name587: Multimedia NetworkingSynchronization of StreamsrRTCP can synchronize different media streams within a RTP session rconsider videoconferencing app for which each sender generates one RTP stream for video, one for aud
65、io. rtimestamps in RTP packets tied to the video, audio sampling clocksmnot tied to wall-clock timereach RTCP sender-report packet contains (for most recently generated packet in associated RTP stream):mtimestamp of RTP packet mwall-clock time for when packet was created. rreceivers uses association
66、 to synchronize playout of audio, video 597: Multimedia NetworkingRTCP Bandwidth ScalingrRTCP attempts to limit its traffic to 5% of session bandwidth.Example rSuppose one sender, sending video at 2 Mbps. Then RTCP attempts to limit its traffic to 100 Kbps. rRTCP gives 75% of rate to receivers; rema
67、ining 25% to senderr75 kbps is equally shared among receivers: mwith R receivers, each receiver gets to send RTCP traffic at 75/R kbps. rsender gets to send RTCP traffic at 25 kbps. rparticipant determines RTCP packet transmission period by calculating avg RTCP packet size (across entire session) an
68、d dividing by allocated rate 607: Multimedia NetworkingSIP: Session Initiation Protocol RFC 3261SIP long-term vision:rall telephone calls, video conference calls take place over Internetrpeople are identified by names or e-mail addresses, rather than by phone numbersryou can reach callee, no matter
69、where callee roams, no matter what IP device callee is currently using617: Multimedia NetworkingSIP ServicesrSetting up a call, SIP provides mechanisms .mfor caller to let callee know she wants to establish a callmso caller, callee can agree on media type, encodingmto end callrdetermine current IP a
70、ddress of callee:mmaps mnemonic identifier to current IP addressrcall management:madd new media streams during callmchange encoding during callminvite others mtransfer, hold calls627: Multimedia NetworkingSetting up a call to known IP addressq Alices SIP invite message indicates her port number, IP
71、address, encoding she prefers to receive (PCM ulaw)q Bobs 200 OK message indicates his port number, IP address, preferred encoding (GSM)q SIP messages can be sent over TCP or UDP; here sent over RTP/UDP. qdefault SIP port number is 5060.637: Multimedia NetworkingSetting up a call (more)rcodec negoti
72、ation:msuppose Bob doesnt have PCM ulaw encoder. mBob will instead reply with 606 Not Acceptable Reply, listing his encoders Alice can then send new INVITE message, advertising different encoderrrejecting a callmBob can reject with replies “busy,” “gone,” “payment required,” “forbidden”rmedia can be
73、 sent over RTP or some other protocol647: Multimedia NetworkingExample of SIP messageINVITE sip: SIP/2.0Via: SIP/2.0/UDP 167.180.112.24From: sip:To: sip: Call-ID: Content-Type: application/sdpContent-Length: 885c=IN IP4 167.180.112.24m=audio 38060 RTP/AVP 0Notes:rHTTP message syntaxrsdp = session de
74、scription protocolrCall-ID is unique for every call.q Here we dont know Bobs IP address. Intermediate SIPservers needed. q Alice sends, receives SIP messages using SIP default port 506q Alice specifies in Via:header that SIP client sends, receives SIP messages over UDP657: Multimedia NetworkingName
75、translation and user locataionrcaller wants to call callee, but only has callees name or e-mail address.rneed to get IP address of callees current host:muser moves aroundmDHCP protocolmuser has different IP devices (PC, PDA, car device)rresult can be based on:m time of day (work, home)mcaller (dont
76、want boss to call you at home)mstatus of callee (calls sent to voicemail when callee is already talking to someone)Service provided by SIP servers:rSIP registrar serverrSIP proxy server667: Multimedia NetworkingSIP RegistrarREGISTER sip: SIP/2.0Via: SIP/2.0/UDP 193.64.210.89 From: sip:To: sip:Expire
77、s: 3600rwhen Bob starts SIP client, client sends SIP REGISTER message to Bobs registrar server (similar function needed by Instant Messaging)Register Message:677: Multimedia NetworkingSIP ProxyrAlice sends invite message to her proxy servermcontains address sip:rproxy responsible for routing SIP mes
78、sages to calleempossibly through multiple proxies.rcallee sends response back through the same set of proxies.rproxy returns SIP response message to Alice mcontains Bobs IP addressrproxy analogous to local DNS server687: Multimedia NetworkingExampleCaller jimumass.edu with places a call to keithupen
79、n.edu (1) Jim sends INVITEmessage to umass SIPproxy. (2) Proxy forwardsrequest to upenn registrar server. (3) upenn server returnsredirect response,indicating that it should try keitheurecom.fr(4) umass proxy sends INVITE to eurecom registrar. (5) eurecom registrar forwards INVITE to 197.87.54.21, w
80、hich is running keiths SIP client. (6-8) SIP response sent back (9) media sent directly between clients. Note: also a SIP ack message, which is not shown.697: Multimedia NetworkingComparison with H.323rH.323 is another signaling protocol for real-time, interactiverH.323 is a complete, vertically int
81、egrated suite of protocols for multimedia conferencing: signaling, registration, admission control, transport, codecsrSIP is a single component. Works with RTP, but does not mandate it. Can be combined with other protocols, servicesrH.323 comes from the ITU (telephony).rSIP comes from IETF: Borrows
82、much of its concepts from HTTPmSIP has Web flavor, whereas H.323 has telephony flavor. rSIP uses the KISS principle: Keep it simple stupid.707: Multimedia NetworkingChapter 7 outline7.1 multimedia networking applications7.2 streaming stored audio and video7.3 making the best out of best effort servi
83、ce7.4 protocols for real-time interactive applications RTP, RTCP, SIP7.5 providing multiple classes of service7.6 providing QoS guarantees 717: Multimedia NetworkingProviding Multiple Classes of Servicerthus far: making the best of best effort servicemone-size fits all service modelralternative: mul
84、tiple classes of servicempartition traffic into classesmnetwork treats different classes of traffic differently (analogy: VIP service vs regular service)0111rgranularity: differential service among multiple classes, not among individual connectionsrhistory: ToS bits727: Multimedia NetworkingMultiple
85、 classes of service: scenarioR1R2H1H2H3H41.5 Mbps linkR1 output interface queue737: Multimedia NetworkingScenario 1: mixed FTP and audiorExample: 1Mbps IP phone, FTP share 1.5 Mbps link. mbursts of FTP can congest router, cause audio lossmwant to give priority to audio over FTPpacket marking needed
86、for router to distinguish between different classes; and new router policy to treat packets accordinglyPrinciple 1R1R2747: Multimedia NetworkingPrinciples for QOS Guarantees (more)rwhat if applications misbehave (audio sends higher than declared rate)mpolicing: force source adherence to bandwidth al
87、locationsrmarking and policing at network edge:msimilar to ATM UNI (User Network Interface)provide protection (isolation) for one class from othersPrinciple 2R1R21.5 Mbps link1 Mbps phonepacket marking and policing757: Multimedia NetworkingPrinciples for QoS Guarantees (more)rAllocating fixed (non-s
88、harable) bandwidth to flow: inefficient use of bandwidth if flows doesnt use its allocationWhile providing isolation, it is desirable to use resources as efficiently as possiblePrinciple 3R1R21.5 Mbps link1 Mbps phone1 Mbps logical link0.5 Mbps logical link767: Multimedia NetworkingScheduling And Po
89、licing Mechanismsrscheduling: choose next packet to send on linkrFIFO (first in first out) scheduling: send in order of arrival to queuemreal-world example?mdiscard policy: if packet arrives to full queue: who to discard?Tail drop: drop arriving packetpriority: drop/remove on priority basisrandom: d
90、rop/remove randomly777: Multimedia NetworkingScheduling Policies: morePriority scheduling: transmit highest priority queued packet rmultiple classes, with different prioritiesmclass may depend on marking or other header info, e.g. IP source/dest, port numbers, etc.mReal world example? 787: Multimedi
91、a NetworkingScheduling Policies: still moreround robin scheduling:rmultiple classesrcyclically scan class queues, serving one from each class (if available)rreal world example?797: Multimedia NetworkingScheduling Policies: still moreWeighted Fair Queuing: rgeneralized Round Robinreach class gets wei
92、ghted amount of service in each cyclerreal-world example?807: Multimedia NetworkingPolicing MechanismsGoal: limit traffic to not exceed declared parametersThree common-used criteria: r(Long term) Average Rate: how many pkts can be sent per unit time (in the long run)mcrucial question: what is the in
93、terval length: 100 packets per sec or 6000 packets per min have same average!rPeak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rater(Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle)817: Multimedia NetworkingPolicing MechanismsToken Bucket: limit input
94、to specified Burst Size and Average Rate. rbucket can hold b tokensrtokens generated at rate r token/sec unless bucket fullrover interval of length t: number of packets admitted less than or equal to (r t + b).827: Multimedia NetworkingPolicing Mechanisms (more)rtoken bucket, WFQ combine to provide
95、guaranteed upper bound on delay, i.e., QoS guarantee!WFQ token rate, rbucket size, bper-flowrate, RD = b/Rmaxarrivingtraffic837: Multimedia NetworkingIETF Differentiated Servicesrwant “qualitative” service classesm“behaves like a wire”mrelative service distinction: Platinum, Gold, Silverrscalability
96、: simple functions in network core, relatively complex functions at edge routers (or hosts)msignaling, maintaining per-flow router state difficult with large number of flows rdont define define service classes, provide functional components to build service classes847: Multimedia NetworkingEdge rout
97、er:qper-flow traffic managementqmarks packets as in-profile and out-profile Core router:qper class traffic managementq buffering and scheduling based on marking at edgeq preference given to in-profile packetsDiffserv Architecturescheduling.rbmarking857: Multimedia NetworkingEdge-router Packet Markin
98、g rclass-based marking: packets of different classes marked differentlyrintra-class marking: conforming portion of flow marked differently than non-conforming onerprofile: pre-negotiated rate A, bucket size Brpacket marking at edge based on per-flow profilePossible usage of marking:User packetsRate
99、AB867: Multimedia NetworkingClassification and ConditioningrPacket is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6r6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receiver2 bits are currently unused877: Multimedia NetworkingCl
100、assification and Conditioningmay be desirable to limit traffic injection rate of some class:ruser declares traffic profile (e.g., rate, burst size)rtraffic metered, shaped if non-conforming 887: Multimedia NetworkingForwarding (PHB)rPHB result in a different observable (measurable) forwarding perfor
101、mance behaviorrPHB does not specify what mechanisms to use to ensure required PHB performance behaviorrExamples: mClass A gets x% of outgoing link bandwidth over time intervals of a specified lengthmClass A packets leave first before packets from class B897: Multimedia NetworkingForwarding (PHB)PHBs
102、 being developed:rExpedited Forwarding: pkt departure rate of a class equals or exceeds specified rate mlogical link with a minimum guaranteed raterAssured Forwarding: 4 classes of trafficmeach guaranteed minimum amount of bandwidthmeach with three drop preference partitions907: Multimedia Networkin
103、gChapter 7 outline7.1 multimedia networking applications7.2 streaming stored audio and video7.3 making the best out of best effort service7.4 protocols for real-time interactive applications RTP, RTCP, SIP7.5 providing multiple classes of service7.6 providing QoS guarantees 917: Multimedia Networkin
104、gChapter 7 outliner7.1 Multimedia Networking Applicationsr7.2 Streaming stored audio and videor7.3 Real-time Multimedia: Internet Phone studyr7.4 Protocols for Real-Time Interactive Applications mRTP,RTCP,SIPr7.5 Distributing Multimedia: content distribution networksr7.6 Beyond Best Effortr7.7 Sched
105、uling and Policing Mechanisms r7.8 Integrated Services and Differentiated Servicesr7.9 RSVP927: Multimedia NetworkingPrinciples for QoS Guarantees (more)rBasic fact of life: can not support traffic demands beyond link capacityCall Admission: flow declares its needs, network may block call (e.g., bus
106、y signal) if it cannot meet needsPrinciple 4R1R21.5 Mbps link1 Mbps phone1 Mbps phone937: Multimedia NetworkingQoS guarantee scenariorResource reservationmcall setup, signaling (RSVP)mtraffic, QoS declarationmper-element admission controlmQoS-sensitive scheduling (e.g., WFQ)request/reply947: Multime
107、dia NetworkingIETF Integrated Servicesrarchitecture for providing QOS guarantees in IP networks for individual application sessionsrresource reservation: routers maintain state info (a la VC) of allocated resources, QoS reqsradmit/deny new call setup requests:Question: can newly arriving flow be adm
108、itted with performance guarantees while not violated QoS guarantees made to already admitted flows?957: Multimedia NetworkingCall AdmissionArriving session must :rdeclare its QOS requirementmR-spec: defines the QOS being requestedrcharacterize traffic it will send into network mT-spec: defines traff
109、ic characteristicsrsignaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required)mRSVP967: Multimedia NetworkingIntserv QoS: Service models rfc2211, rfc 2212Guaranteed service:rworst case traffic arrival: leaky-bucket-policed source rsimple (mathematically provable)
110、 bound on delay Parekh 1992, Cruz 1988Controlled load service:ra quality of service closely approximating the QoS that same flow would receive from an unloaded network element.WFQ token rate, rbucket size, bper-flowrate, RD = b/Rmaxarrivingtraffic977: Multimedia NetworkingSignaling in the Internetco
111、nnectionless (stateless) forwarding by IP routersbest effort serviceno network signaling protocols in initial IP design+=rNew requirement: reserve resources along end-to-end path (end system, routers) for QoS for multimedia applicationsrRSVP: Resource Reservation Protocol RFC 2205m“ allow users to c
112、ommunicate requirements to network in robust and efficient way.” i.e., signaling !rearlier Internet Signaling protocol: ST-II RFC 1819987: Multimedia NetworkingRSVP Design Goals1.accommodate heterogeneous receivers (different bandwidth along paths)2.accommodate different applications with different
113、resource requirements3.make multicast a first class service, with adaptation to multicast group membership4.leverage existing multicast/unicast routing, with adaptation to changes in underlying unicast, multicast routes5.control protocol overhead to grow (at worst) linear in # receivers6.modular des
114、ign for heterogeneous underlying technologies997: Multimedia NetworkingRSVP: does notrspecify how resources are to be reservedrrather: a mechanism for communicating needsrdetermine routes packets will takerthats the job of routing protocolsrsignaling decoupled from routingrinteract with forwarding o
115、f packetsrseparation of control (signaling) and data (forwarding) planes1007: Multimedia NetworkingRSVP: overview of operationrsenders, receiver join a multicast groupmdone outside of RSVPmsenders need not join grouprsender-to-network signalingmpath message: make sender presence known to routersmpat
116、h teardown: delete senders path state from routersrreceiver-to-network signalingmreservation message: reserve resources from sender(s) to receivermreservation teardown: remove receiver reservationsrnetwork-to-end-system signalingmpath errormreservation error1017: Multimedia NetworkingChapter 7: Summ
117、aryPrinciplesrclassify multimedia applicationsridentify network services applications needrmaking the best of best effort serviceProtocols and Architectures rspecific protocols for best-effortrmechanisms for providing QoSrarchitectures for QoSmmultiple classes of servicemQoS guarantees, admission control1027: Multimedia Networking
