1、Computer Networking:A Top Down Approach A note on the use of these Powerpoint slides:Were making these slides freely available to all(faculty,students,readers).Theyre in PowerPoint form so you see the animations;and can add,modify,and delete slides (including this one)and slide content to suit your
2、needs.They obviously represent a lot of work on our part.In return for use,we only ask the following:If you use these slides(e.g.,in a class)that you mention their source(after all,wed like people to use our book!)If you post any slides on a www site,that you note that they are adapted from(or perha
3、ps identical to)our slides,and note our copyright of this material.Thanks and enjoy!JFK/KWR All material copyright 1996-2016 J.F Kurose and K.W.Ross,All Rights Reserved7th edition Jim Kurose,Keith RossPearson/Addison WesleyApril 2016Chapter 9Multimedia Networking9-1Multimedia NetworkingMultimedia ne
4、tworking:outline9.1 multimedia networking applications9.2 streaming stored video9.3 voice-over-IP9.4 protocols for real-time conversational applications9.5 network support for multimedia9-2Multimedia NetworkingMultimedia:audio analog audio signal sampled at constant rate telephone:8,000 samples/sec
5、CD music:44,100 samples/sec each sample quantized,i.e.,rounded e.g.,28=256 possible quantized values each quantized value represented by bits,e.g.,8 bits for 256 valuestimeaudio signal amplitudeanalogsignalquantized value ofanalog valuequantization errorsampling rate(N sample/sec)9-3Multimedia Netwo
6、rkingMultimedia:audio example:8,000 samples/sec,256 quantized values:64,000 bps receiver converts bits back to analog signal:some quality reductionexample rates CD:1.411 Mbps MP3:96,128,160 kbps Internet telephony:5.3 kbps and uptimeaudio signal amplitudeanalogsignalquantized value ofanalog valuequa
7、ntization errorsampling rate(N sample/sec)9-4Multimedia Networking video:sequence of images displayed at constant rate e.g.,24 images/sec digital image:array of pixels each pixel represented by bits coding:use redundancy within and between images to decrease#bits used to encode image spatial(within
8、image)temporal(from one image to next)Multimedia: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 diff
9、erences from frame i9-5Multimedia NetworkingMultimedia: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 onl
10、y differences from frame i CBR:(constant bit rate):video encoding rate fixed VBR:(variable bit rate):video encoding rate changes as amount of spatial,temporal coding changes examples:MPEG 1(CD-ROM)1.5 Mbps MPEG2(DVD)3-6 Mbps MPEG4(often used in Internet,1 Mbps)9-6Multimedia NetworkingMultimedia netw
11、orking:3 application typesstreaming,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,Huluconversational voice/video over IP interactive nature o
12、f human-to-human conversation limits delay tolerance e.g.,Skypestreaming live audio,video e.g.,live sporting event(futbol)9-7Multimedia NetworkingMultimedia networking:outline9.1 multimedia networking applications9.2 streaming stored video9.3 voice-over-IP9.4 protocols for real-time conversational a
13、pplications9.5 network support for multimedia9-8Multimedia NetworkingStreaming 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)time
14、3.video received,played out at client(30 frames/sec)9-9Multimedia NetworkingStreaming 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 requirem
15、ents other challenges:client interactivity:pause,fast-forward,rewind,jump through video video packets may be lost,retransmitted9-10Multimedia Networking constant bit rate videotransmissionCumulative datatimevariablenetworkdelayclient videoreception constant bit rate video playout at clientclient pla
16、youtdelaybufferedvideoclient-side buffering and playout delay:compensate for network-added delay,delay jitterStreaming stored video:revisited9-11Multimedia NetworkingClient-side buffering,playoutvariable fill rate,x(t)client application buffer,size Bplayout rate,e.g.,CBR rbuffer fill level,Q(t)video
17、 serverclient9-12Multimedia NetworkingClient-side buffering,playoutvariable 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 begins at tp,3.buffer fill level varies over time as f
18、ill rate x(t)varies and playout rate r is constant9-13Multimedia Networkingplayout buffering:average fill rate(x),playout rate(r):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 la
19、rger delay,but larger delay until user begins watchingvariable fill rate,x(t)client application buffer,size Bplayout rate,e.g.,CBR rbuffer fill level,Q(t)video serverClient-side buffering,playout9-14Multimedia NetworkingStreaming multimedia:UDP server sends at rate appropriate for client often:send
20、rate=encoding rate=constant rate transmission rate can be oblivious to congestion levels short playout delay(2-5 seconds)to remove network jitter error recovery:application-level,time permitting RTP RFC 2326:multimedia payload types UDP may not go through firewalls9-15Multimedia NetworkingStreaming
21、multimedia:HTTP multimedia file retrieved via HTTP GET send at maximum possible rate under TCP 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 firewallsvariable rate,x(t)TCP send bu
22、ffervideofileTCP receive bufferapplication playout bufferserverclient9-16Multimedia NetworkingMultimedia networking:outline9.1 multimedia networking applications9.2 streaming stored video9.3 voice-over-IP9.4 protocols for real-time conversational applications9.5 network support for multimedia9-17Mul
23、timedia NetworkingVoice-over-IP(VoIP)VoIP end-end-delay requirement:needed to maintain“conversational”aspect higher delays noticeable,impair interactivity 400 msec bad includes application-level(packetization,playout),network delayssession initialization:how does callee advertise IP address,port num
24、ber,encoding algorithms?value-added services:call forwarding,screening,recordingemergency services:911 9-18Multimedia NetworkingVoIP characteristics speakers audio:alternating talk spurts,silent periods.64 kbps during talk spurt pkts generated only during talk spurts 20 msec chunks at 8 Kbytes/sec:1
25、60 bytes of data application-layer header added to each chunk chunk+header encapsulated into UDP or TCP segment application sends segment into socket every 20 msec during talkspurt9-19Multimedia NetworkingVoIP:packet loss,delaynetwork loss:IP datagram lost due to network congestion(router buffer ove
26、rflow)delay loss:IP datagram arrives too late for playout at receiver delays:processing,queueing in network;end-system(sender,receiver)delays typical maximum tolerable delay:400 msloss tolerance:depending on voice encoding,loss concealment,packet loss rates between 1%and 10%can be tolerated9-20Multi
27、media Networking constant bit ratetransmissionCumulative datatimevariablenetworkdelay(jitter)clientreception constant bit rate playout at clientclient playoutdelaybuffereddataDelay jitter end-to-end delays of two consecutive packets:difference can be more or less than 20 msec(transmission time diffe
28、rence)9-21Multimedia NetworkingVoIP:fixed playout delay receiver 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”tradeoff in choosing q:large q:less packet losssm
29、all q:better interactive experience9-22Multimedia Networkingpacketstimepacketsgeneratedpacketsreceivedlossrppplayout schedulep-rplayout schedulep-r sender generates packets every 20 msec during talk spurt.first packet received at time r first playout schedule:begins at p second playout schedule:begi
30、ns at pVoIP:fixed playout delay9-23Multimedia NetworkingAdaptive playout delay(1)goal:low playout delay,low late loss rateapproach:adaptive playout delay adjustment:estimate network delay,adjust playout delay at beginning of each talk spurt silent periods compressed and elongated chunks still played
31、 out every 20 msec during talk spurt adaptively estimate packet delay:(EWMA-exponentially weighted moving average,recall TCP RTT estimate):di=(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 packet9-24Multimedia Networkin
32、g also useful to estimate average deviation of delay,vi:estimates di,vi calculated for every received packet,but used only at start of talk spurt for first packet in talk spurt,playout time is:remaining packets in talkspurt are played out periodicallyvi=(1-b)vi-1+b|ri ti di|playout-timei=ti+di+Kvi A
33、daptive playout delay(2)9-25Multimedia NetworkingQ:How does receiver determine whether packet is first in a talkspurt?if no loss,receiver looks at successive timestamps difference of successive stamps 20 msec-talk spurt begins.with loss possible,receiver must look at both time stamps and sequence nu
34、mbers difference of successive stamps 20 msec and sequence numbers without gaps-talk spurt begins.Adaptive playout delay(3)9-26Multimedia NetworkingVoiP:recovery from packet loss(1)Challenge:recover from packet loss given small tolerable delay between original transmission and playout each ACK/NAK t
35、akes one RTT alternative:Forward Error Correction(FEC)send enough bits to allow recovery without retransmission(recall two-dimensional parity in Ch.5)simple FEC for every group of n chunks,create redundant chunk by exclusive OR-ing n original chunks send n+1 chunks,increasing bandwidth by factor 1/n
36、 can reconstruct original n chunks if at most one lost chunk from n+1 chunks,with playout delay9-27Multimedia Networkinganother FEC scheme:“piggyback lower quality stream”send lower resolutionaudio stream as redundant information e.g.,nominal stream PCM at 64 kbpsand redundant streamGSM at 13 kbps n
37、on-consecutive loss:receiver can conceal loss generalization:can also append(n-1)st and(n-2)nd low-bit ratechunkVoiP:recovery from packet loss(2)9-28Multimedia Networkinginterleaving to conceal loss:audio chunks divided into smaller units,e.g.four 5 msec units per 20 msec audio chunk packet contains
38、 small units from different chunks if packet lost,still have most of every original chunk no redundancy overhead,but increases playout delayVoiP:recovery from packet loss(3)9-29Multimedia Networkingsupernode overlay networkVoice-over-IP:Skype proprietary application-layer protocol(inferred via rever
39、se engineering)encrypted msgs P2P components:Skype clients(SC)clients:Skype peers connect directly to each other for VoIP call super nodes(SN):Skype peers with special functions overlay network:among SNs to locate SCs login serverSkype login serversupernode(SN)9-30Multimedia NetworkingP2P voice-over
40、-IP:SkypeSkype client operation:1.joins Skype network by contacting SN(IP address cached)using TCP2.logs-in(username,password)to centralized Skype login server3.obtains IP address for callee from SN,SN overlayor client buddy list4.initiate call directly to calleeSkype login server9-31Multimedia Netw
41、orkingproblem:both Alice,Bob are behind“NATs”NAT prevents outside peer from initiating connection to insider peer inside peer can initiate connection to outside relay solution:Alice,Bob maintain open connection to their SNsAlice signals her SN to connect to BobAlices SN connects to Bobs SNBobs SN co
42、nnects to Bob over open connection Bob initially initiated to his SNSkype:peers as relays9-32Multimedia NetworkingMultimedia networking:outline9.1 multimedia networking applications9.2 streaming stored video9.3 voice-over-IP9.4 protocols for real-time conversational applications:RTP,SIP9.5 network s
43、upport for multimedia9-33Multimedia NetworkingReal-Time Protocol(RTP)RTP specifies packet structure for packets carrying audio,video data RFC 3550 RTP packet provides payload type identification packet sequence numbering time stamping RTP runs in end systems RTP packets encapsulated in UDP segments
44、interoperability:if two VoIP applications run RTP,they may be able to work together9-34Multimedia 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-stamping9-35Multimed
45、ia NetworkingRTP exampleexample:sending 64 kbps PCM-encoded voice over RTP application collects encoded data in chunks,e.g.,every 20 msec=160 bytes in a chunk audio chunk+RTP header form RTP packet,which is encapsulated in UDP segment RTP header indicates type of audio encoding in each packet sender
46、 can change encoding during conference RTP header also contains sequence numbers,timestamps9-36Multimedia NetworkingRTP and QoS RTP does not provide any mechanism to ensure timely data delivery or other QoS guarantees RTP encapsulation only seen at end systems(not by intermediate routers)routers pro
47、vide best-effort service,making no special effort to ensure that RTP packets arrive at destination in timely matter9-37Multimedia NetworkingRTP headerpayload type(7 bits):indicates type of encoding currently being used.If sender changes encoding during call,sender informs receiver via payload type f
48、ieldPayload 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 loss,restore packet sequencepayload typesequence number type
49、time stampSynchronizationSource IDMiscellaneous fields9-38Multimedia Networkingtimestamp field(32 bits long):sampling instant of first byte in this RTP data packet for audio,timestamp clock increments by one for each sampling period(e.g.,each 125 usecs for 8 KHz sampling clock)if application generat
50、es 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.SSRC field(32 bits long):identifies source of RTP stream.Each stream in RTP session has distinct SSRCRTP headerpayload
