《计算机网络英文课件：Chapter_7 Multimedia Networking》由会员分享，可在线阅读，更多相关《计算机网络英文课件：Chapter_7 Multimedia Networking（89页珍藏版）》请在金锄头文库上搜索。
1、Chapter 7Multimedia NetworkingComputer Networking: A Top Down Approach 6th edition Jim Kurose, Keith RossAddison-WesleyMarch 2012A 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 see the animations; a
2、nd can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:vIf you use these slides (e.g., in a class) that you mention their source (after all, wed like people to u
3、se our book!)vIf you post any slides on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.Thanks and enjoy! JFK/KWR All material copyright 1996-2012 J.F Kurose and K.W. Ross, All Rights ReservedMultmedia Networking7-1Mu
4、ltimedia networking: outline7.1 multimedia networking applications7.2 streaming stored video7.3 voice-over-IP7.4 protocols for real-time conversational applications7.5 network support for multimediaMultmedia Networking7-2Multimedia networking: outline7.1 multimedia networking applications7.2 streami
5、ng stored video7.3 voice-over-IP7.4 protocols for real-time conversational applications7.5 network support for multimediaMultmedia Networking7-3Multimedia: audioMultmedia Networking7-4vanalog audio signal sampled at constant ratetelephone: 8,000 samples/secCD music: 44,100 samples/secveach sample qu
6、antized, i.e., roundede.g., 28=256 possible quantized valueseach quantized value represented by bits, e.g., 8 bits for 256 valuestimeaudio signal amplitudeanalogsignalquantized value ofanalog valuequantization errorsampling rate(N sample/sec)Multimedia: audioMultmedia Networking7-5vexample: 8,000 sa
7、mples/sec, 256 quantized values: 64,000 bpsvreceiver converts bits back to analog signal:some quality reductionvexample ratesvCD: 1.411 MbpsvMP3: 96, 128, 160 kbpsvInternet telephony: 5.3 kbps and uptimeaudio signal amplitudeanalogsignalquantized value ofanalog valuequantization errorsampling rate(N
8、 sample/sec)vvideo: sequence of images displayed at constant ratee.g. 24 images/secvdigital image: array of pixelseach pixel represented by bitsvcoding: use redundancy within and between images to decrease # bits used to encode imagespatial (within image)temporal (from one image to next)Multmedia Ne
9、tworking7-6Multimedia: video.spatial coding example: instead of sending N values of same color (all purple), send only two values: color value (purple) and number of repeated values (N).frame iframe i+1temporal coding example: instead of sending complete frame at i+1, send only differences from fram
10、e iMultmedia Networking7-7Multimedia: video.spatial coding example: instead of sending N values of same color (all purple), send only two values: color value (purple) and number of repeated values (N).frame iframe i+1temporal coding example: instead of sending complete frame at i+1, send only differ
11、ences from frame ivCBR: (constant bit rate): video encoding rate fixedvVBR: (variable bit rate): video encoding rate changes as amount of spatial, temporal coding changes vexamples:MPEG 1 (CD-ROM) 1.5 MbpsMPEG2 (DVD) 3-6 MbpsMPEG4 (often used in Internet, 1 Mbps)Multimedia networking: 3 application
12、typesMultmedia Networking7-8vstreaming, stored audio, videostreaming: can begin playout before downloading entire filestored (at server): can transmit faster than audio/video will be rendered (implies storing/buffering at client)e.g., YouTube, Netflix, Huluvconversational voice/video over IP interac
13、tive nature of human-to-human conversation limits delay tolerancee.g., Skypevstreaming live audio, videoe.g., live sporting event (futbol)Multimedia networking: outline7.1 multimedia networking applications7.2 streaming stored video7.3 voice-over-IP7.4 protocols for real-time conversational applicat
14、ions7.5 network support for multimediaMultmedia Networking7-9Streaming stored video: 1.videorecorded (e.g., 30 frames/sec)2. videosentCumulative datastreaming: at this time, client playing out early part of video, while server still sending laterpart of videonetwork delay(fixed in this example)timeM
15、ultmedia Networking 7-103. video received,played out at client(30 frames/sec)Streaming stored video: challengesvcontinuous 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 re
16、quirementsvother challenges:client interactivity: pause, fast-forward, rewind, jump through videovideo packets may be lost, retransmittedMultmedia Networking 7-11 constant bit rate videotransmissionCumulative datatimevariablenetworkdelayclient videoreception constant bit rate video playout at client
17、client playoutdelaybufferedvideovclient-side buffering and playout delay: compensate for network-added delay, delay jitterMultmedia Networking 7-12Streaming stored video: revistedClient-side buffering, playoutMultmedia Networking 7-13variable fill rate, x(t)client application buffer, size Bplayout r
18、ate,e.g., CBR rbuffer fill level, Q(t)video serverclientClient-side buffering, playoutMultmedia Networking 7-14variable fill rate, x(t)client application buffer, size Bplayout rate,e.g., CBR rbuffer fill level, Q(t)video serverclient1. Initial fill of buffer until playout begins at tp2. playout begi
19、ns at tp, 3. buffer fill level varies over time as fill rate x(t) varies and playout rate r is constantplayout buffering: average fill rate (x), playout rate (r):vx r: buffer will not empty, provided initial playout delay is large enough to absorb variability in x(t)initial playout delay tradeoff: b
20、uffer starvation less likely with larger delay, but larger delay until user begins watchingMultmedia Networking 7-15variable fill rate, x(t)client application buffer, size Bplayout rate,e.g., CBR rbuffer fill level, Q(t)video serverClient-side buffering, playoutStreaming multimedia: UDPvserver sends
21、 at rate appropriate for client often: send rate = encoding rate = constant ratetransmission rate can be oblivious to congestion levelsvshort playout delay (2-5 seconds) to remove network jitterverror recovery: application-level, timeipermittingvRTP RFC 2326: multimedia payload typesvUDP may not go
22、through firewallsMultmedia Networking 7-16Streaming multimedia: HTTPvmultimedia file retrieved via HTTP GETvsend at maximum possible rate under TCPvfill rate fluctuates due to TCP congestion control, retransmissions (in-order delivery)vlarger playout delay: smooth TCP delivery ratevHTTP/TCP passes m
23、ore easily through firewallsMultmedia Networking 7-17variable rate, x(t)TCP send buffervideofileTCP receive bufferapplication playout bufferserverclientStreaming multimedia: DASHvDASH: Dynamic, Adaptive Streaming over HTTPvserver:divides video file into multiple chunkseach chunk stored, encoded at d
24、ifferent rates manifest file: provides URLs for different chunksvclient:periodically measures server-to-client bandwidthconsulting manifest, requests one chunk at a time chooses maximum coding rate sustainable given current bandwidthcan choose different coding rates at different points in time (depe
25、nding on available bandwidth at time)Multmedia Networking 7-18Streaming multimedia: DASHvDASH: Dynamic, Adaptive Streaming over HTTPv“intelligence” at client: client determineswhen to request chunk (so that buffer starvation, or overflow does not occur)what encoding rate to request (higher quality w
26、hen more bandwidth available) where to request chunk (can request from URL server that is “close” to client or has high available bandwidth) Multmedia Networking 7-19Content distribution networksvchallenge: how to stream content (selected from millions of videos) to hundreds of thousands of simultan
27、eous users?voption 1: single, large “mega-server”single point of failurepoint of network congestionlong path to distant clientsmultiple copies of video sent over outgoing link.quite simply: this solution doesnt scaleMultmedia Networking 7-20Content distribution networksvchallenge: how to stream cont
28、ent (selected from millions of videos) to hundreds of thousands of simultaneous users?voption 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 usersused by Akamai, 1700 locationsbring home:
29、 smaller number (10s) of larger clusters in POPs near (but not within) access networksused by LimelightMultmedia Networking 7-21CDN: “simple” content access scenarioMultmedia Networking 7-22Bob (client) requests video http:/ stored in CDN at http:/KingCDN.com/NetC6y&B23VKingCDN.com11. Bob gets URL f
30、or for video http:/ web page22. resolve http:/ Bobs local DNSnetcinemasauthorative DNS33. netcinemas DNS returns URL http:/KingCDN.com/NetC6y&B23V44&5. Resolve http:/KingCDN.com/NetC6y&B23via KingCDNs authoritative DNS, which returns IP address of KIingCDN server with video56. request video fromKIN
31、GCDN server,streamed via HTTPKingCDNauthoritative DNSCDN cluster selection strategyvchallenge: how does CDN DNS select “good” CDN node to stream to clientpick CDN node geographically closest to clientpick CDN node with shortest delay (or min # hops) to client (CDN nodes periodically ping access ISPs
32、, reporting results to CDN DNS)IP anycastvalternative: let client decide - give client a list of several CDN serversclient pings servers, picks “best”Netflix approach Multmedia Networking 7-23Case study: Netflixv30% downstream US traffic in 2011vowns very little infrastructure, uses 3rd party servic
33、es:own registration, payment serversAmazon (3rd party) cloud services:Netflix uploads studio master to Amazon cloudcreate multiple version of movie (different endodings) in cloudupload versions from cloud to CDNsCloud hosts Netflix web pages for user browsingthree 3rd party CDNs host/stream Netflix
34、content: Akamai, Limelight, Level-3Multmedia Networking 7-24Case study: NetflixMultmedia Networking 7-2511. Bob manages Netflix accountNetflix registration,accounting serversAmazon cloudAkamai CDN Limelight CDN Level-3 CDN 22. Bob browsesNetflix video33. Manifest filereturned for requested video4. D
35、ASH streamingupload copies of multiple versions of video to CDNsMultimedia networking: outline7.1 multimedia networking applications7.2 streaming stored video7.3 voice-over-IP7.4 protocols for real-time conversational applications7.5 network support for multimediaMultmedia Networking 7-26Voice-over-
36、IP (VoIP)Multmedia Networking 7-27vVoIP end-end-delay requirement: needed to maintain “conversational” aspecthigher delays noticeable, impair interactivity 400 msec badincludes application-level (packetization,playout), network delaysvsession initialization: how does callee advertise IP address, por
37、t number, encoding algorithms?vvalue-added services: call forwarding, screening, recordingvemergency services: 911 VoIP characteristicsvspeakers audio: alternating talk spurts, silent periods.64 kbps during talk spurtpkts generated only during talk spurts20 msec chunks at 8 Kbytes/sec: 160 bytes of
38、datavapplication-layer header added to each chunkvchunk+header encapsulated into UDP or TCP segmentvapplication sends segment into socket every 20 msec during talkspurtMultmedia Networking 7-28VoIP: packet loss, delayvnetwork loss: IP datagram lost due to network congestion (router buffer overflow)v
39、delay loss: IP datagram arrives too late for playout at receiverdelays: processing, queueing in network; end-system (sender, receiver) delaystypical maximum tolerable delay: 400 msvloss tolerance: depending on voice encoding, loss concealment, packet loss rates between 1% and 10% can be toleratedMul
40、tmedia Networking 7-29 constant bit ratetransmissionCumulative datatimevariablenetworkdelay(jitter)clientreception constant bit rate playout at clientclient playoutdelaybuffereddataDelay jittervend-to-end delays of two consecutive packets: difference can be more or less than 20 msec (transmission ti
41、me difference)Multmedia Networking 7-30VoIP: fixed playout delayvreceiver attempts to playout each chunk exactly q msecs after chunk was generated.chunk has time stamp t: play out chunk at t+q chunk arrives after t+q: data arrives too late for playout: data “lost”vtradeoff in choosing q:large q: les
42、s packet losssmall q: better interactive experienceMultmedia Networking 7-31 sender generates packets every 20 msec during talk spurt. first packet received at time r first playout schedule: begins at p second playout schedule: begins at pMultmedia Networking 5-32VoIP: fixed playout delayAdaptive pl
43、ayout delay (1)vgoal: low playout delay, low late loss ratevapproach: adaptive playout delay adjustment:estimate network delay, adjust playout delay at beginning of each talk spurtsilent periods compressed and elongatedchunks still played out every 20 msec during talk spurtvadaptively estimate packe
44、t delay: (EWMA - exponentially weighted moving average, recall TCP RTT estimate):Multmedia Networking 7-33di = (1-a)di-1 + a (ri ti)delay estimate after ith packetsmall constant, e.g. 0.1time received - time sent (timestamp)measured delay of ith packetv also useful to estimate average deviation of d
45、elay, vi :vestimates di, vi calculated for every received packet, but used only at start of talk spurtv for first packet in talk spurt, playout time is: remaining packets in talkspurt are played out periodicallyMultmedia Networking 5-34vi = (1-b)vi-1 + b |ri ti di|playout-timei = ti + di + Kvi Adapt
46、ive playout delay (2)Q: How does receiver determine whether packet is first in a talkspurt?vif no loss, receiver looks at successive timestampsdifference of successive stamps 20 msec -talk spurt begins.vwith loss possible, receiver must look at both time stamps and sequence numbersdifference of succ
47、essive stamps 20 msec and sequence numbers without gaps - talk spurt begins.Multmedia Networking 7-35Adaptive playout delay (3)VoiP: recovery from packet loss (1)Challenge: recover from packet loss given small tolerable delay between original transmission and playoutveach ACK/NAK takes one RTTvalter
48、native: Forward Error Correction (FEC)send enough bits to allow recovery without retransmission (recall two-dimensional parity in Ch. 5)simple FECvfor every group of n chunks, create redundant chunk by exclusive OR-ing n original chunksvsend n+1 chunks, increasing bandwidth by factor 1/nvcan reconst
49、ruct original n chunks if at most one lost chunk from n+1 chunks, with playout delayMultmedia Networking 7-36another FEC scheme:v“piggyback lower quality stream” vsend lower resolutionaudio stream as redundant informationve.g., nominal stream PCM at 64 kbpsand redundant streamGSM at 13 kbpsvnon-cons
50、ecutive loss: receiver can conceal loss vgeneralization: can also append (n-1)st and (n-2)nd low-bit ratechunkMultmedia Networking 7-37VoiP: recovery from packet loss (2)interleaving to conceal loss:vaudio chunks divided into smaller units, e.g. four 5 msec units per 20 msec audio chunkvpacket conta
51、ins small units from different chunksvif packet lost, still have most of every original chunkvno redundancy overhead, but increases playout delayMultmedia Networking 7-38VoiP: recovery from packet loss (3)Application Layer 2-39supernode overlay networkVoice-over-IP: Skypevproprietary application-lay
52、er protocol (inferred via reverse engineering) encrypted msgsvP2P components:Skype clients (SC)clients: skype peers connect directly to each other for VoIP callsuper nodes (SN): skype peers with special functionsoverlay network: among SNs to locate SCslogin serverSkype login serversupernode (SN)Appl
53、ication Layer 2-40P2P voice-over-IP: skypeskype client operation:1. joins skype network by contacting SN (IP address cached) using TCP2. logs-in (usename, password) to centralized skype login server3. obtains IP address for callee from SN, SN overlayor client buddy list4. initiate call directly to c
54、alleeSkype login serverApplication Layer 2-41vproblem: both Alice, Bob are behind “NATs” NAT prevents outside peer from initiating connection to insider peerinside peer can initiate connection to outside vrelay solution: Alice, Bob maintain open connection to their SNsAlice signals her SN to connect
55、 to BobAlices SN connects to Bobs SNBobs SN connects to Bob over open connection Bob initially initiated to his SNSkype: peers as relaysMultimedia networking: outline7.1 multimedia networking applications7.2 streaming stored video7.3 voice-over-IP7.4 protocols for real-time conversational applicatio
56、ns: RTP, SIP7.5 network support for multimediaMultmedia Networking 7-42Real-Time Protocol (RTP)vRTP specifies packet structure for packets carrying audio, video datavRFC 3550vRTP packet provides payload type identificationpacket sequence numberingtime stampingvRTP runs in end systemsvRTP packets enc
57、apsulated in UDP segmentsvinteroperability: if two VoIP applications run RTP, they may be able to work togetherMultmedia Networking 7-43RTP runs on top of UDPRTP libraries provide transport-layer interface that extends UDP: port numbers, IP addresses payload type identification packet sequence numbe
58、ring time-stampingMultmedia Networking 5-44RTP exampleexample: sending 64 kbps PCM-encoded voice over RTPvapplication collects encoded data in chunks, e.g., every 20 msec = 160 bytes in a chunkvaudio chunk + RTP header form RTP packet, which is encapsulated in UDP segment vRTP header indicates type
59、of audio encoding in each packetsender can change encoding during conference vRTP header also contains sequence numbers, timestampsMultmedia Networking 7-45RTP and QoSvRTP does not provide any mechanism to ensure timely data delivery or other QoS guaranteesvRTP encapsulation only seen at end systems
60、 (not by intermediate routers)routers provide best-effort service, making no special effort to ensure that RTP packets arrive at destination in timely matterMultmedia Networking 7-46RTP headerpayload type (7 bits): indicates type of encoding currently being used. If sender changes encoding during ca
61、ll, sender informs receiver via payload type fieldPayload 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 # (16 bits): increment by one for each RTP packet sentvdetect packet lo
62、ss, restore packet sequenceMultmedia Networking 5-47payload typesequence number typetime stampSynchronizationSource IDMiscellaneous fieldsvtimestamp field (32 bits long): sampling instant of first byte in this RTP data packetfor audio, timestamp clock increments by one for each sampling period (e.g.
63、, each 125 usecs for 8 KHz sampling clock) if application generates chunks of 160 encoded samples, timestamp increases by 160 for each RTP packet when source is active. Timestamp clock continues to increase at constant rate when source is inactive.vSSRC field (32 bits long): identifies source of RTP
64、 stream. Each stream in RTP session has distinct SSRCMultmedia Networking 7-48RTP headerpayload typesequence number typetime stampSynchronizationSource IDMiscellaneous fieldsRTSP/RTP programming assignmentvbuild a server that encapsulates stored video frames into RTP packetsgrab video frame, add RTP
65、 headers, create UDP segments, send segments to UDP socketinclude seq numbers and time stampsclient RTP provided for youvalso write client side of RTSPissue play/pause commandsserver RTSP provided for youMultmedia Networking 7-49Real-Time Control Protocol (RTCP)vworks in conjunction with RTPveach pa
66、rticipant in RTP session periodically sends RTCP control packets to all other participantsveach RTCP packet contains sender and/or receiver reportsreport statistics useful to application: # packets sent, # packets lost, interarrival jittervfeedback used to control performancesender may modify its tr
67、ansmissions based on feedbackMultmedia Networking 7-50RTCP: multiple multicast sendersveach RTP session: typically a single multicast address; all RTP /RTCP packets belonging to session use multicast addressvRTP, RTCP packets distinguished from each other via distinct port numbersvto limit traffic,
68、each participant reduces RTCP traffic as number of conference participants increases Multmedia Networking 5-51RTCPRTPRTCPRTCPsenderreceiversRTCP: packet typesreceiver report packets:v fraction of packets lost, last sequence number, average interarrival jittersender report packets: vSSRC of RTP strea
69、m, current time, number of packets sent, number of bytes sent source description packets: ve-mail address of sender, senders name, SSRC of associated RTP stream vprovide mapping between the SSRC and the user/host nameMultmedia Networking 7-52RTCP: stream synchronizationvRTCP can synchronize differen
70、t media streams within a RTP session ve.g., videoconferencing app: each sender generates one RTP stream for video, one for audio. vtimestamps in RTP packets tied to the video, audio sampling clocksnot tied to wall-clock timeveach RTCP sender-report packet contains (for most recently generated packet
71、 in associated RTP stream):timestamp of RTP packet wall-clock time for when packet was createdvreceivers uses association to synchronize playout of audio, video Multmedia Networking 7-53RTCP: bandwidth scalingRTCP attempts to limit its traffic to 5% of session bandwidthexample : one sender, sending
72、video at 2 MbpsvRTCP attempts to limit RTCP traffic to 100 KbpsvRTCP gives 75% of rate to receivers; remaining 25% to senderv75 kbps is equally shared among receivers: with R receivers, each receiver gets to send RTCP traffic at 75/R kbps. vsender gets to send RTCP traffic at 25 kbps. vparticipant d
73、etermines RTCP packet transmission period by calculating avg RTCP packet size (across entire session) and dividing by allocated rate Multmedia Networking 7-54SIP: Session Initiation Protocol RFC 3261long-term vision:vall telephone calls, video conference calls take place over Internetvpeople identif
74、ied by names or e-mail addresses, rather than by phone numbersvcan reach callee (if callee so desires), no matter where callee roams, no matter what IP device callee is currently usingMultmedia Networking 7-55SIP servicesvSIP provides mechanisms for call setup:for caller to let callee know she wants
75、 to establish a callso caller, callee can agree on media type, encodingto end callvdetermine current IP address of callee:maps mnemonic identifier to current IP addressvcall management:add new media streams during callchange encoding during callinvite others transfer, hold callsMultmedia Networking
76、7-56Example: setting up call to known IP addressv Alices SIP invite message indicates her port number, IP address, encoding she prefers to receive (PCM mlaw)v Bobs 200 OK message indicates his port number, IP address, preferred encoding (GSM)v SIP messages can be sent over TCP or UDP; here sent over
77、 RTP/UDP v default SIP port number is 5060Multmedia Networking 5-57Setting up a call (more)vcodec negotiation:suppose Bob doesnt have PCM mlaw encoder Bob will instead reply with 606 Not Acceptable Reply, listing his encoders. Alice can then send new INVITE message, advertising different encodervrej
78、ecting a callBob can reject with replies “busy,” “gone,” “payment required,” “forbidden”vmedia can be sent over RTP or some other protocolMultmedia Networking 7-58Example of SIP messageINVITE sip: SIP/2.0Via: SIP/2.0/UDP 167.180.112.24From: sip:To: sip: Call-ID: Content-Type: application/sdpContent-
79、Length: 885c=IN IP4 167.180.112.24m=audio 38060 RTP/AVP 0Notes:vHTTP message syntaxvsdp = session description protocolvCall-ID is unique for every callv Here we dont know Bobs IP addressintermediate SIPservers neededv Alice sends, receives SIP messages using SIP default port 506v Alice specifies in
80、header that SIP client sends, receives SIP messages over UDPMultmedia Networking 7-59Name translation, user locationvcaller wants to call callee, but only has callees name or e-mail address.vneed to get IP address of callees current host:user moves aroundDHCP protocoluser has different IP devices (P
81、C, smartphone, car device)vresult can be based on: time of day (work, home)caller (dont want boss to call you at home)status of callee (calls sent to voicemail when callee is already talking to someone)Multmedia Networking 7-60SIP registrarREGISTER sip: SIP/2.0Via: SIP/2.0/UDP 193.64.210.89 From: si
82、p:To: sip:Expires: 3600vone function of SIP server: registrarvwhen Bob starts SIP client, client sends SIP REGISTER message to Bobs registrar serverregister message:Multmedia Networking 7-61SIP proxyvanother function of SIP server: proxyvAlice sends invite message to her proxy servercontains address
83、 sip:proxy responsible for routing SIP messages to callee, possibly through multiple proxiesvBob sends response back through same set of SIP proxiesvproxy returns Bobs SIP response message to Alice contains Bobs IP addressvSIP proxy analogous to local DNS server plus TCP setupMultmedia Networking 7-
84、62SIP example: jimumass.edu calls keithpoly.eduMultmedia Networking 7-6311. Jim sends INVITEmessage to UMass SIP proxy. 2. UMass proxy forwards request to Poly registrar server23. Poly server returns redirect response,indicating that it should try keitheurecom.fr35. eurecom registrar forwards INVITE
85、 to 197.87.54.21, which is running keiths SIP client544. Umass proxy forwards request to Eurecom registrar server8676-8. SIP response returned to Jim99. Data flows between clientsUMass SIP proxyPoly SIPregistrarEurecom SIPregistrar197.87.54.21128.119.40.186Comparison with H.323vH.323: another signal
86、ing protocol for real-time, interactive multimediavH.323: complete, vertically integrated suite of protocols for multimedia conferencing: signaling, registration, admission control, transport, codecsvSIP: single component. Works with RTP, but does not mandate it. Can be combined with other protocols
87、, servicesvH.323 comes from the ITU (telephony)vSIP comes from IETF: borrows much of its concepts from HTTPSIP has Web flavor; H.323 has telephony flavorvSIP uses KISS principle: Keep It Simple StupidMultmedia Networking 7-64Multimedia networking: outline7.1 multimedia networking applications7.2 str
88、eaming stored video7.3 voice-over-IP7.4 protocols for real-time conversational applications7.5 network support for multimediaMultmedia Networking 7-65Network support for multimediaMultmedia Networking 7-66Dimensioning best effort networksvapproach: deploy enough link capacity so that congestion does
89、nt occur, multimedia traffic flows without delay or losslow complexity of network mechanisms (use current “best effort” network)high bandwidth costsvchallenges:network dimensioning: how much bandwidth is “enough?”estimating network traffic demand: needed to determine how much bandwidth is “enough” (
90、for that much traffic)Multmedia Networking 7-67Providing multiple classes of servicevthus far: making the best of best effort serviceone-size fits all service modelvalternative: multiple classes of servicepartition traffic into classesnetwork treats different classes of traffic differently (analogy:
91、 VIP service versus regular service)0111vgranularity: differential service among multiple classes, not among individual connectionsvhistory: ToS bitsMultmedia Networking 7-68Multiple classes of service: scenarioR1R2H1H2H3H41.5 Mbps linkR1 output interface queueMultmedia Networking 7-69Scenario 1: mi
92、xed HTTP and VoIPvexample: 1Mbps VoIP, HTTP share 1.5 Mbps link. HTTP bursts can congest router, cause audio losswant to give priority to audio over HTTPpacket marking needed for router to distinguish between different classes; and new router policy to treat packets accordinglyPrinciple 1R1R2Multmed
93、ia Networking 7-70Principles for QOS guarantees (more)vwhat if applications misbehave (VoIP sends higher than declared rate)policing: force source adherence to bandwidth allocationsvmarking, policing at network edgeprovide protection (isolation) for one class from othersPrinciple 2R1R21.5 Mbps link1
94、 Mbps phonepacket marking and policingMultmedia Networking 7-71vallocating fixed (non-sharable) 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 p
95、hone1 Mbps logical link0.5 Mbps logical linkMultmedia Networking 7-72Principles for QOS guarantees (more)Scheduling and policing mechanismsvscheduling: choose next packet to send on linkvFIFO (first in first out) scheduling: send in order of arrival to queuereal-world example?discard policy: if pack
96、et arrives to full queue: who to discard?tail drop: drop arriving packetpriority: drop/remove on priority basisrandom: drop/remove randomlyMultmedia Networking 7-73queue(waiting area)packetarrivalspacketdepartureslink (server)Scheduling policies: prioritypriority scheduling: send highest priority qu
97、eued packet vmultiple classes, with different prioritiesclass may depend on marking or other header info, e.g. IP source/dest, port numbers, etc.real world example? Multmedia Networking 7-74high priority queue(waiting area)low priority queue(waiting area)arrivalsclassifydepartureslink (server)132455
98、522113344arrivalsdeparturespacket in serviceScheduling policies: still moreRound Robin (RR) scheduling:vmultiple classesvcyclically scan class queues, sending one complete packet from each class (if available)vreal world example?Multmedia Networking 7-75123455523113344arrivalsdeparturespacket in ser
99、viceWeighted Fair Queuing (WFQ): vgeneralized Round Robinveach class gets weighted amount of service in each cyclevreal-world example?Multmedia Networking 7-76Scheduling policies: still morePolicing mechanismsgoal: limit traffic to not exceed declared parametersThree common-used criteria: v(long ter
100、m) average rate: how many pkts can be sent per unit time (in the long run)crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average!vpeak rate: e.g., 6000 pkts per min (ppm) avg.; 1500 ppm peak ratev(max.) burst size: max number of pkts sent consecu
101、tively (with no intervening idle)Multmedia Networking 7-77Policing mechanisms: implementationtoken bucket: limit input to specified burst size and average rate vbucket can hold b tokensvtokens generated at rate r token/sec unless bucket fullvover interval of length t: number of packets admitted less
102、 than or equal to (r t + b)Multmedia Networking 7-78Policing and QoS guaranteesvtoken bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee!WFQ token rate, rbucket size, bper-flowrate, RD = b/RmaxarrivingtrafficMultmedia Networking 7-79arrivingtrafficDifferentiated serv
103、icesvwant “qualitative” service classes“behaves like a wire”relative service distinction: Platinum, Gold, Silvervscalability: simple functions in network core, relatively complex functions at edge routers (or hosts)signaling, maintaining per-flow router state difficult with large number of flows vdo
104、nt define define service classes, provide functional components to build service classesMultmedia Networking 7-80edge router:vper-flow traffic managementvmarks packets as in-profile and out-profile core router:vper class traffic managementvbuffering and scheduling based on marking at edgevpreference
105、 given to in-profile packets over out-of-profile packetsDiffserv architectureMultmedia Networking 7-81rbmarkingscheduling.Edge-router packet marking vclass-based marking: packets of different classes marked differentlyvintra-class marking: conforming portion of flow marked differently than non-confo
106、rming onevprofile: pre-negotiated rate r, bucket size bvpacket marking at edge based on per-flow profilepossible use of marking:user packetsrate rbMultmedia Networking 5-82Diffserv packet marking: detailsvpacket is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6v6 bits used fo
107、r Differentiated Service Code Point (DSCP)determine PHB that the packet will receive2 bits currently unusedMultmedia Networking 7-83DSCPunusedClassification, conditioningmay be desirable to limit traffic injection rate of some class:vuser declares traffic profile (e.g., rate, burst size)vtraffic met
108、ered, shaped if non-conforming Multmedia Networking 7-84Forwarding Per-hop Behavior (PHB)vPHB result in a different observable (measurable) forwarding performance behaviorvPHB does not specify what mechanisms to use to ensure required PHB performance behaviorvexamples: class A gets x% of outgoing li
109、nk bandwidth over time intervals of a specified lengthclass A packets leave first before packets from class BMultmedia Networking 7-85Forwarding PHBPHBs proposed:vexpedited forwarding: pkt departure rate of a class equals or exceeds specified rate logical link with a minimum guaranteed ratevassured
110、forwarding: 4 classes of trafficeach guaranteed minimum amount of bandwidtheach with three drop preference partitionsMultmedia Networking 7-86Per-connection QOS guarantees vbasic fact of life: can not support traffic demands beyond link capacitycall admission: flow declares its needs, network may bl
111、ock call (e.g., busy signal) if it cannot meet needsPrinciple 4R1R21.5 Mbps link1 Mbps phone1 Mbps phoneMultmedia Networking 7-87QoS guarantee scenariovresource reservationcall setup, signaling (RSVP)traffic, QoS declarationper-element admission controlQoS-sensitive scheduling (e.g., WFQ)request/replyMultmedia Networking 7-88Multimedia networking: outline7.1 multimedia networking applications7.2 streaming stored video7.3 voice-over-IP7.4 protocols for real-time conversational applications7.5 network support for multimediaMultmedia Networking 7-89
