06 Chapter6 Wireless and Mobile Networks.pptx

第1页：第7章多媒体网络 封面

第7章多媒体网络 封面

Chapter 7 Multimedia Networking

第2页：多媒体和服务质量什么

多媒体和服务质量什么

Multimedia and Quality of Service: What is it?multimedia applications:network audio and video(“continuous media”)network provides application withlevel ofperformance needed forapplication to function. Qo S

第3页：第7章：目标原理

第7章：目标原理

• classify multimedia applications
• identify network services applications need
• making the best of best effort service Protocols and Architectures
• specific protocols for best-effort
• mechanisms for providing Qo S
• architectures for Qo S

第4页：第7章路线图

第7章路线图

Chapter 7 outline 7.1 multimedia networking applications 7.2 streaming stored audioand video 7.3 making the best out ofbest effort service 7.4 protocols for real-time interactive applications RTP, RTCP, SIP7.5 providing multiple classes of service 7.6 providing Qo Sguarantees

第5页：MM Networking Applications Fundamental

MM Networking Applications Fundamental

• typically delay sensitive
  • end-to-end delay
  • delay jitter
• loss tolerant: infrequentlosses cause minor glitches
• antithesis of data, whichare lossintolerantbutdelaytolerant. Classes of MM applications:1) stored streaming 2) live streaming 3) interactive, real-time Jitteris the variabilityof packet delays withinthe same packet stream

第6页：Streaming Stored Multimedia Stored

Streaming Stored Multimedia Stored

• media stored at source
• transmitted to client
• streaming:client playout begins beforeall data has arrived
• timing constraint for still-to-betransmitted data: in time for playout

第7页：流式 Stored 多媒体

流式 Stored 多媒体

Streaming Stored Multimedia:What is it?1. video recorded 2. videosent 3. video received,played out at client Cumulative datastreaming:at this time, clientplaying out early part of video,while server still sending laterpart of video network delaytime

第8页：Streaming Stored Multimedia

Streaming Stored Multimedia

• VCR-like functionality:client canpause, rewind, FF, push slider bar
  • 10 sec initial delay OK
  • 1-2 sec until command effect OK
• timing constraint for still-to-betransmitted data: in time for playout

第9页：流式 Live 多媒体示例

流式 Live 多媒体示例

• Internet radio talk show
• live sporting event Streaming(as with streaming stored multimedia)
• playback buffer
• playback can lag tens of seconds aftertransmission
• still have timing constraint Interactivity
• fast forward impossible
• rewind, pause possible!

第10页：实时交互应用

实时交互应用

• end-end delay requirements:
  • audio: < 150 msec good, < 400 msec OK
• includes application-level (packetization) and network delays
• higher delays noticeable, impair interactivity
• session initialization
  • how does callee advertise its IP address, portnumber, encoding algorithms?
• applications:IP telephony,video conference, distributed interactive worlds

第11页：Multimedia Over Today’s Internet TCP

Multimedia Over Today’s Internet TCP

• noguarantees on delay, loss Today’s Internet multimedia applicationsuse application-level techniques to mitigate(as best possible) effects of delay, loss But you said multimedia apps requires Qo S and level of performance to beeffective!???????????

第12页：如何应因特网 evolve

如何应因特网 evolve

• fundamental changes in Internet so that apps canreserve end-to-endbandwidth
• requires new, complex software in hosts & routers Laissez-faire
• no major changes
• more bandwidth whenneeded
• content distribution,application-layer multicast
  • application layer Differentiated services philosophy:
• fewer changes to Internet infrastructure, yet provide 1 st and 2 nd class service What’s your opinion?

第13页：few words about audio compression

few words about audio compression

• analog signal sampledat constant rate
  • telephone: 8,000 samples/sec
  • 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
  • 8 bits for 256 values
• example: 8,000 samples/sec, 256 quantized values-->64,000 bps
• receiver converts bitsback to analog signal:
  • some quality reduction Example rates
• CD: 1.411 Mbps
• MP3: 96, 128, 160 kbps
• Internet telephony:5.3 kbps and up

第14页：few words about video compression

few words about video compression

• video: sequence ofimages displayed atconstant rate
  • e.g. 24 images/sec
• digital image: array ofpixels
  • each pixel representedby bits
• redundancy
  • spatial (within image)
  • temporal (from one imageto next)Examples:
• MPEG 1 (CD-ROM) 1.5 Mbps
• MPEG2 (DVD) 3-6 Mbps
• MPEG4 (often used in Internet, < 1 Mbps)Research:
• layered (scalable) video
  • adapt layers to available bandwidth

第15页：第7章路线图

第7章路线图

Chapter 7 outline 7.1 multimedia networking applications 7.2 streaming stored audioand video 7.3 making the best out ofbest effort service 7.4 protocols for real-time interactive applications RTP, RTCP, SIP7.5 providing multiple classes of service 7.6 providing Qo Sguarantees

第16页：Streaming Stored Multimedia

Streaming Stored Multimedia

• client-side buffering
• use of UDP versus TCP
• multiple encodings ofmultimedia
• jitter removal
• decompression
• error concealment
• graphical user interfacew/ controls forinter activity Media Player

第17页：因特网多媒体最简单方法音频

因特网多媒体最简单方法音频

• no, “pipelining,” long delays until playout!
• audio or video stored in file
• files transferred as HTTP object
  • received in entirety at client
  • then passed to player

第18页：因特网多媒体流式方法

因特网多媒体流式方法

• browser GETsmetafile
• browser launches player, passing metafile
• player contacts server
• server stream saudio/video to player

第19页：流式从流式 server

流式从流式 server

• allows for non-HTTP protocol between server, media player
• UDP or TCP for step (3), more shortly

第20页：constant bitrate video transmission

constant bitrate video transmission

• client-side buffering, playout delay compensatefor network-added delay, delay jitter

第21页：流式多媒体 Client 缓存

流式多媒体 Client 缓存

• client-side buffering, playout delay compensatefor network-added delay, delay jitter buffered video variable fillrate, x(t)constant drainrate, d

第22页：Streaming Multimedia: UDP or TCP?UDP

Streaming Multimedia: UDP or TCP?UDP

• server sends at rate appropriate for client (oblivious tonetwork congestion !)
  • often send rate = encoding rate=constant rate
  • then, fill rate = constant rate-packet loss
• short playout delay (2-5 seconds) to remove network jitter
• error recover: time permitting TCP
• send at maximum possible rate under TCP
• fill rate fluctuates due to TCP congestion control
• larger playout delay: smooth TCP delivery rate
• HTTP/TCP passes more easily through firewalls

第23页：Streaming Multimedia:client rate(s)

Streaming Multimedia:client rate(s)

• 28.8 Kbps dialup
• 100 Mbps Ethernet A:server stores, transmits multiple copiesof video, encoded at different rates 1.5 Mbps encoding 28.8 Kbps encoding

第24页：用户控制的流式 Media:RTS

用户控制的流式 Media:RTS

• does not target multimedia content
• no commands for fastforward, etc. RTSP: RFC 2326
• client-server application layer protocol
• user control: rewind,fast forward, pause,resume, repositioning,etc…What it doesn’t do:
• doesn’t define howaudio/video isencapsulated forstreaming over network
• doesn’t restrict howstreamed media istrans ported (UDP or TCP possible)
• doesn’t specify howmedia player buffer saudio/video

第25页：RTSP: out band control FTP

RTSP: out band control FTP

• file transferred overone TCP connection.
• control info (directory changes, file deletion,rename) sent overseparate TCPconnection
• “out-of-band”, “in-band” channels usedifferent portnumbers RTSP messages also sentout-of-band:
• RTSP control messages usedifferent portnumbers than media stream: out-of-band.
  • port 554
• media stream isconsidered “in-band”.

第26页：RTSP 示例场景

RTSP 示例场景

• metafile communicated to web browser
• browser launches player
• player sets up an RTSP control connection, dataconnection to streaming server

第27页：元文件示例

元文件示例

Metafile Example<title>Twister</title><session><group language=en lipsync><switch><track type=audioe="PCMU/8000/1"src = "rtsp://audio.example.com/twister/audio.en/lofi"><track type=audioe="DVI4/16000/2" pt="90 DVI4/8000/1"src="rtsp://audio.example.com/twister/audio.en/hifi"></switch><track type="video/jpeg"src="rtsp://video.example.com/twister/video"></group></session>

第28页：RTSP Operation

RTSP Operation

RTSP Operation

第29页：RTSP Exchange Example C: SETUP rtsp

RTSP Exchange Example C: SETUP rtsp

RTSP Exchange Example C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAYS: RTSP/1.0 200 1 OKSession 4231C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0-C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231S: 200 3 OK

第30页：第7章路线图

第7章路线图

Chapter 7 outline 7.1 multimedia networking applications 7.2 streaming stored audioand video 7.3 making the best out ofbest effort service 7.4 protocols for real-time interactive applications RTP, RTCP, SIP7.5 providing multiple classes of service 7.6 providing Qo Sguarantees

第31页：实时交互应用

实时交互应用

• PC-2-PC phone
  • Skype
• PC-2-phone
  • Dialpad
  • Net 2 phone
  • Skype
• video conference withwebcams
  • Skype
  • Polycom Going to now look ata PC-2-PC Internet phone example indetail

第32页：Interactive Multimedia: Internet Phone

Interactive Multimedia: Internet Phone

• speaker’s audio: alternating talk spurts, silent periods.
  • 64 kbps during talk spurt
  • pkts generated only during talk spurts
  • 20 msec chunks at 8 Kbytes/sec: 160 bytesdata
• application-layer header added to each chunk.
• chunk+header encapsulated into UDP segment.
• application sends UDP segment into socket every 20 msec during talkspurt

第33页：因特网 Phone：分组丢失和时延

因特网 Phone：分组丢失和时延

• network loss:IP datagram lost due to network congestion (router buffer overflow)
• delay loss:IP datagram arrives too late forplayout at receiver
  • delays: processing, queueing in network; end-system (sender, receiver) delays
  • typical maximum tolerable delay: 400 ms
• loss tolerance: depending on voice encoding, lossesconcealed, packet loss rates between 1% and 10%can be tolerated.

第34页：恒定比特率传输与抖动（示意图）

恒定比特率传输与抖动（示意图）

• consider end-to-end delays of two consecutive packets: difference can be more or less than 20 msec (transmission time difference)

第35页：Internet Phone: Fixed Playout Delay

Internet Phone: Fixed Playout Delay

• receiver attempts to playout each chunk exactly qmsecs after chunk was generated.
  • chunk has time stamp t: play out chunk at t+q .
  • chunk arrives after t+q: data arrives too latefor playout, data “lost”
• tradeoff in choosing q:
  • large q:less packet loss
  • small q:better interactive experience

第36页：Fixed Playout Delay

Fixed Playout Delay

• 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 p’

第37页：Adaptive Playout Delay (1)dynamic

Adaptive Playout Delay (1)dynamic

• Goal:minimize playout delay, keeping late loss rate low
• Approach:adaptive playout delay adjustment:
  • estimate network delay, adjust playout delay at beginning ofeach talk spurt.
  • silent periods compressed and elongated.
  • chunks still played out every 20 msec during talk spurt.

第38页：Adaptive playout delay (2)

Adaptive playout delay (2)

• also useful to estimate average deviation of delay,vi:
• estimatesdi,vicalculated for every received packet(but used only at start of talk spurt
• for first packet in talk spurt, playout time is:where K is positive constant
• remaining packets in talkspurt are played out periodically

第39页：Adaptive Playout (3)Q:How does receiver

Adaptive Playout (3)Q:How does receiver

• 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 timestamps and sequence numbers.
  • difference of successive stamps > 20 msecandsequencenumbers without gaps--> talk spurt begins.

第40页：恢复从分组丢失 (1)Forward 差错

恢复从分组丢失 (1)Forward 差错

• for every group ofnchunks create redundant chunk by exclusive OR-ingnoriginal chunks
• send outn+1 chunks,increasing bandwidth byfactor 1/n.
• can reconstruct originaln chunks if at most one lostchunk fromn+1 chunks
• playout delay: enoughtime to receive all n+1 packets
• tradeoff:
  • increase n, lessbandwidth waste
  • increase n, longer playout delay
  • increase n, higherprobability that 2 ormore chunks will belost

第41页：恢复从分组丢失 (2)2 nd

恢复从分组丢失 (2)2 nd

• “piggyback lower quality stream”
• send lower resolutionaudio stream asredundant information
• e.g., nominal stream PCM at 64 kbpsand redundant stream GSM at 13 kbps.
• whenever there is non-consecutive loss,receiver can conceal the loss.
• can also append (n-1)st and (n-2)nd low-bit ratechunk

第42页：Recovery from packet loss

Recovery from packet loss

• chunks divided into smallerunits
• for example, four 5 msecunits per chunk
• packet contains small unitsfrom different chunks
• if packet lost, still have mostof every chunk
• no redundancy overhead, butincreases playout delay

第43页：Content distribution networks

Content distribution networks

• challenging to stream largefiles (e.g., video) from single origin server in real time
• solution:replicate content athundreds of servers throughout Internet
  • content downloaded to CDNservers ahead of time
  • placing content “close” touser avoids impairments(loss, delay) of sending content over long paths
  • CDN server typically inedge/access network origin serverin North America CDN distribution node CDN serverin S. America CDN serverin Europe CDN serverin Asia

第44页：Content distribution networks

Content distribution networks

• CDN (e.g., Akamai)customer is the content provider (e.g., CNN)
• CDN replicates customers’ content in CDN servers.
• when provider updates content, CDN updates servers origin serverin North America CDN distribution node CDN serverin S. America CDN serverin Europe CDN serverin Asia

第45页：CDN example origin server

CDN example origin server

• distributes HTML
• replaces: request forwww.foo.com/sports/sports.html DNS query for www.cdn.com HTTP request forwww.cdn.com/www.foo.com/sports/ruth.gif 123 origin server CDN’s authoritative DNS server CDN server near client CDN company (cdn.com)
• distributes gif files
• uses its authoritative DNS server to routere direct requests client

第46页：More about CDN

More about CDN

• CDN creates a “map”, indicating distances fromleaf ISPs and CDN nodes
• when query arrives at authoritative DNS server:
  • server determines ISP from which query originates
  • uses “map” to determine best CDN server
• CDN nodes create application-layer overlay network

第47页：本章小结

本章小结

• use UDPto avoid TCP congestion control (delays)for time-sensitive traffic
• client-sideadaptive playout delay: to compensatefor delay
• server sidematches stream bandwidthto available client-to-server path bandwidth
  • chose among pre-encoded stream rates
  • dynamic server encoding rate
• error recovery (on top of UDP)
  • FEC, interleaving, error concealment
  • retransmissions, time permitting
• CDN: bring content closer to clients

第48页：第7章路线图

第7章路线图

Chapter 7 outline 7.1 multimedia networking applications 7.2 streaming stored audioand video 7.3 making the best out ofbest effort service 7.4 protocols for real-time interactive applications RTP, RTCP, SIP7.5 providing multiple classes of service 7.6 providing Qo Sguarantees

第49页：实时传输协议RTP

实时传输协议RTP

• RTP specifies packet structure for packets carrying audio, videodata
• RFC 3550
• RTP packet provides
  • payload type identification
  • packet sequence numbering
  • time stamping
• RTP runs in end systems
• RTP packets encapsulated in UDPsegments
• interoperability: if two Internet phone applications run RTP,then they may be ableto work together

第50页：RTP runs top UDPRTP

RTP runs top UDPRTP

• port numbers, IP addresses
• payload type identification
• packet sequence numbering
• time-stamping

第51页：RTP Example

RTP Example

• consider sending 64 kbps PCM-encoded voice over RTP.
• application collects encoded data inchunks, e.g., every 20 msec = 160 bytes in achunk.
• audio chunk + RTPheader form RTPpacket, which isencapsulated in UDPsegment
• RTP header indica testype of audio encodingin each packet
  • sender can change encoding during conference.
• RTP header alsocontains sequence numbers, timestamps.

第52页：RTP与QoS

RTP与QoS

• RTP doesnotprovide any mechanism to ensure timely data delivery or other Qo S guarantees.
• RTP encapsulation is only seen at end systems(not) by intermediate routers.
  • routers providing best-effort service, makingno special effort to ensure that RTP packets arrive at destination in timely matter.

第53页：RTP 首部有效载荷类型 (7

RTP 首部有效载荷类型 (7

• Payload type 0: PCM mu-law, 64 kbps
• Payload type 3, GSM, 13 kbps
• Payload type 7, LPC, 2.4 kbps
• Payload type 26, Motion JPEG
• Payload type 31. H.261
• Payload type 33, MPEG2 video Sequence Number (16 bits):Increments by one for each RTP packetsent, and may be used to detect packet loss and to restore packet sequence.

第54页：RTP Header (2)

RTP Header (2)

• Timestamp field (32 bytes long):sampling instantof first byte in this RTP data packet
  • for audio, timestamp clock typically increments by onefor each sampling period (for example, each 125 usecsfor 8 KHz sampling clock)
  • if application generates chunks of 160 encoded samples,then timestamp increases by 160 for each RTP packetwhen source is active. Timestamp clock continues toincrease at constant rate when source is inactive.
• SSRC field (32 bits long):identifies source of t RTPstream. Each stream in RTP session should have distinct SSRC.

第55页：RTSP/RTP Programming Assignment

RTSP/RTP Programming Assignment

• build a server that encapsulates stored video frames into RTP packets
  • grab video frame, add RTP headers, create UDPsegments, send segments to UDP socket
  • include seq numbers and time stamps
  • client RTP provided for you
• also write client side of RTSP
  • issue play/pause commands
  • server RTSP provided for you

第56页：实时控制协议RTCP

实时控制协议RTCP

• works in conjunctionwith RTP.
• each participant in RTPsession periodically transmits RTCP control packets to all other participants.
• each RTCP packet contains sender and/orreceiver reports
  • report statistics useful toapplication: # packetssent, # packets lost,inter arrival jitter, etc.
• feedback can be usedto control performance
  • sender may modify itstransmissions based onfeedback

第57页：RTP、RTCP与SIP（示意图）

RTP、RTCP与SIP（示意图）

• each RTP session: typically a single multicast address; all RTP /RTCP packets belonging to session use multicast address.
• RTP, RTCP packets distinguished from each other via distinct port numbers.
• to limit traffic, each participant reduces RTCP traffic as number ofconference participants increases

第58页：RTCP Packets Receiver report packets

RTCP Packets Receiver report packets

• fraction of packetslost, last sequence number, average inter arrival jitter Sender report packets:
• SSRC of RTP stream,current time, number ofpackets sent, number ofbytes sent Source description packets:
• e-mail address ofsender, sender's name, SSRC of associated RTP stream
• provide mapping between the SSRC andthe user/host name

第59页：Synchronization Streams

Synchronization Streams

• RTCP can synchronize different media streams within a RTP session
• consider videoconferencingapp for which each sender generates one RTP streamfor video, one for audio.
• timestamps in RTP packetstied to the video, audio sampling clocks
  • nottied to wall-clocktime
• each RTCP sender-report packet contains (for mostrecently generated packetin associated RTP stream):
  • timestamp of RTP packet
  • wall-clock time for whenpacket was created.
• receivers uses associationto synchronize playout ofaudio, video

第60页：RTCP 带宽扩展性

RTCP 带宽扩展性

• RTCP attempts to limit itstraffic to 5% of session bandwidth. Example
• Suppose one sender,sending video at 2 Mbps. Then RTCP attempts tolimit its traffic to 100 Kbps.
• RTCP gives 75% of rate toreceivers; remaining 25%to sender
• 75 kbps is equally shared among receivers:
  • with R receivers, eachreceiver gets to send RTCPtraffic at 75/R kbps.
• sender gets to send RTCPtraffic at 25 kbps.
• participant determines RTCPpacket transmission period bycalculating avg RTCP packetsize (across entire session)and dividing by allocated rate

第61页：SIP: Session Initiation Protocol[RFC

SIP: Session Initiation Protocol[RFC

• all telephone calls, video conference calls takeplace over Internet
• people are identified by names or e-mailaddresses, rather than by phone numbers
• you can reach callee, no matter where calleeroams, no matter what IP device callee is currentlyusing

第62页：SIP Services

SIP Services

• Setting up a call, SIPprovides mechanisms ..
  • for caller to letcallee know shewants to establish acall
  • so caller, callee canagree on media type,encoding
  • to end call
• determine current IPaddress of callee:
  • maps mnemonicidentifier to current IPaddress
• call management:
  • add new media streams during call
  • change encoding duringcall
  • invite others
  • transfer, hold calls

第63页：Setting up call known

Setting up call known

• Alice’s SIP invite message indicates herport number, IP address,encoding she prefers toreceive (PCM ulaw)
• Bob’s 200 OK message indicates his port number, IP address, preferred encoding (GSM)
• SIP messages can besent over TCP or UDP;here sent over RTP/UDP.
• default SIP port numberis 5060.

第64页：Setting up call (more)

Setting up call (more)

• codec negotiation:
  • suppose Bob doesn’thave PCM ulawencoder.
  • Bob will instead replywith 606 Not Acceptable Reply,listing his encoders Alice can then sendnew INVITE message, advertising different encoder
• rejecting a call
  • Bob can reject withreplies “busy,”“gone,” “payment required,”“forbidden”
• media can be sent over RTP or some other protocol

第65页：Example SIP message INVITE

Example SIP message INVITE

• HTTP message syntax
• sdp = session description protocol
• Call-ID is unique for every call.
• Here we don’t know Bob’s IP address. Intermediate SIPservers needed.
• Alice sends, receives SIP messages using SIP default port 506
• Alice specifies in Via:header that SIP clientsends, receives SIPmessages over UDP

第66页：名字转换和用户

名字转换和用户

• caller wants to callcallee, but only hascallee’s name or e-mailaddress.
• need to get IP addressof callee’s currenthost:
  • user moves around
  • DHCP protocol
  • user has different IPdevices (PC, PDA, cardevice)
• result can be based on:
  • time of day (work, home)
  • caller (don’t want boss tocall you at home)
  • status of callee (calls sentto voicemail when callee isalready talking tosomeone)Service provided by SIPservers:
• SIP registrar server
• SIP proxy server

第67页：SIP Registrar REGISTER

SIP Registrar REGISTER

• when Bob starts SIP client, client sends SIPREGISTER message to Bob’s registrar server(similar function needed by Instant Messaging)Register Message:

第68页：SIP Proxy

SIP Proxy

• Alice sends invite message to her proxy server
  • contains address sip:bob@domain.com
• proxy responsible for routing SIP messages tocallee
  • possibly through multiple proxies.
• callee sends response back through the same setof proxies.
• proxy returns SIP response message to Alice
  • contains Bob’s IP address
• proxy analogous to local DNS server

第69页：Example Caller

Example Caller

Example Caller jim@umass.eduwith places acall to keith@upenn.edu(1) Jim sends INVITE message to umass SIPproxy. (2) Proxy forwardsre quest to upennregistrar server.(3) upenn server returnsredirect response,indicating that it shouldtry keith@eurecom.fr(4) umass proxy sends INVITE to eurecom registrar. (5) eurecomregistrar forwards INVITE to 197.87.54.21, which is running keith’s SIPclient. (6-8) SIP response sent back (9) media sent directly between clients. Note:also a SIP ack message, which is not shown.

第70页：Comparison with H.323

Comparison with H.323

• H.323 is another signaling protocol for real-time,interactive
• H.323 is a complete,vertically integrated suiteof protocols for multimedia conferencing: signaling,registration, admission control, transport, codecs
• SIP is a single component. Works with RTP, but doesnot mandate it. Can becombined with other protocols, services
• H.323 comes from the ITU(telephony).
• SIP comes from IETF:Borrows much of itsconcepts from HTTP
  • SIP has Web flavor,whereas H.323 hastele phony flavor.
• SIP uses the KISSprinciple: Keep it simple stupid.

第71页：第7章路线图

第7章路线图

Chapter 7 outline 7.1 multimedia networking applications 7.2 streaming stored audioand video 7.3 making the best out ofbest effort service 7.4 protocols for real-time interactive applications RTP, RTCP, SIP7.5 providing multiple classes of service 7.6 providing Qo Sguarantees

第72页：提供多等级服务

提供多等级服务

• thus far: making the best of best effort service
  • one-size fits all service model
• alternative: multiple classes of service
  • partition traffic into classes
  • network treats different classes of traffic differently (analogy: VIP service vs regular service)0111
• granularity:differential service among multiple classes, not among individual connections
• history: To S bits

第73页：多 classes 的服务场景

多 classes 的服务场景

Multiple classes of service: scenario R1R2H1H2H3H41.5 Mbps link R1 output interface queue

第74页：Scenario 1: mixed FTP and audio

Scenario 1: mixed FTP and audio

• Example: 1 Mbps IP phone, FTP share 1.5 Mbps link.
  • bursts of FTP can congest router, cause audio loss
  • want to give priority to audio over FTPpacket marking needed for router to distinguish between different classes; and new router policyto treat packets accordingly Principle 1R1R2

第75页：原理面向 QoS 保证补充

原理面向 QoS 保证补充

• what if applications misbehave (audio sends higherthan declared rate)
  • policing: force source adherence to bandwidth allocations
• marking and policing at network edge:
  • similar to ATM UNI (User Network Interface)provide protection (isolation) for one class from others Principle 2R1R21.5 Mbps link 1 Mbps phone packet marking and policing

第76页：原理面向 QoS 保证补充

原理面向 QoS 保证补充

• Allocatingfixed(non-sharable) bandwidth to flow:inefficientuse of bandwidth if flows doesn’t useits allocation While providing isolation, it is desirable to useresources as efficiently as possible Principle 3R1R21.5 Mbps link 1 Mbpsphone 1 Mbps logical link 0.5 Mbps logical link

第77页：调度与管制机制

调度与管制机制

• scheduling:choose next packet to send on link
• FIFO (first in first out) scheduling:send in order ofarrival to queue
  • real-world example?
  • discard policy:if packet arrives to full queue: who to discard?
• Tail drop: drop arriving packet
• priority: drop/remove on priority basis
• random: drop/remove randomly

第78页：调度策略：优先级调度

调度策略：优先级调度

• multiple classes, with different priorities
  • class may depend on marking or other header info, e.g. IPsource/dest, port numbers, etc..
  • Real world example?

第79页：调度策略：轮转调度

调度策略：轮转调度

• multiple classes
• cyclically scan class queues, serving one from eachclass (if available)
• real world example?

第80页：调度策略：加权公平排队

调度策略：加权公平排队

• generalized Round Robin
• each class gets weighted amount of service in eachcycle
• real-world example?

第81页：区分服务与调度管制（示意图）

区分服务与调度管制（示意图）

• (Long term) Average Rate:how many pkts can be sentper unit time (in the long run)
  • crucial question: what is the interval length: 100 packets persec or 6000 packets per min have same average!
• Peak Rate:e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate
• (Max.) Burst Size:max. number of pkts sentconsecutively (with no inter vening idle)

第82页：区分服务与调度管制（示意图）

区分服务与调度管制（示意图）

• bucket can hold b tokens
• tokens generated at rater token/secunless bucketfull
• over interval of length t: number of packets admitted less than or equal to (r t + b).

第83页：区分服务与调度管制（示意图）

区分服务与调度管制（示意图）

• token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., Qo S guarantee!WFQtoken rate, rbucket size, bper-flowrate, RD = b/Rmaxarrivingtraffic

第84页：IETF Differentiated Services

IETF Differentiated Services

• want “qualitative” service classes
  • “behaves like a wire”
  • relative service distinction: Platinum, Gold, Silver
• scalability:simple functions in network core,relatively complex functions at edge routers (orhosts)
  • signaling, maintaining per-flow router state difficult with large number of flows
• don’t define define service classes, provide functional components to build service classes

第85页：边缘路由器

边缘路由器

• per-flowtraffic management
• marks packets asin-profileandout-profile Core router:
• per class traffic management
• buffering and scheduling basedonmarkingat edge
• preference given toin-profilepackets Diffserv Architecture scheduling...rbmarking

第86页：Edge-router

Edge-router

• class-based marking: packets of different classes marked differently
• intra-class marking: conforming portion of flow marked differently than non-conforming one
• profile:pre-negotiatedrate A, bucket size B
• packet marking at edge based onper-flowprofile Possible usage of marking:User packets Rate AB

第87页：Classification and Conditioning

Classification and Conditioning

• Packet is marked in the Type of Service (TOS) in IPv 4, and Traffic Class in IPv 6
• 6 bits used for Differentiated Service Code Point(DSCP) and determine PHB that the packet willreceive
• 2 bits are currently unused

第88页：Classification and Conditioningmay

Classification and Conditioningmay

• user declares traffic profile (e.g., rate, burst size)
• traffic metered, shaped if non-conforming

第89页：Forwarding (PHB)

Forwarding (PHB)

• PHB result in a different observable (measurable)forwarding performance behavior
• PHB does not specify what mechanisms to use toensure required PHB performance behavior
• Examples:
  • Class A gets x% of outgoing link bandwidth over timeintervals of a specified length
  • Class A packets leave first before packets from class B

第90页：Forwarding (PHB)PHBs being developed

Forwarding (PHB)PHBs being developed

• Expedited Forwarding:pkt departure rate of aclass equals or exceeds specified rate
  • logical link with a minimum guaranteed rate
• Assured Forwarding:4 classes of traffic
  • each guaranteed minimum amount of bandwidth
  • each with three drop preference partitions

第91页：第7章路线图

第7章路线图

Chapter 7 outline 7.1 multimedia networking applications 7.2 streaming stored audioand video 7.3 making the best out ofbest effort service 7.4 protocols for real-time interactive applications RTP, RTCP, SIP7.5 providing multiple classes of service 7.6 providing Qo Sguarantees

第92页：第7章路线图

第7章路线图

• 7.1 Multimedia Networking Applications
• 7.2 Streaming stored audio and video
• 7.3 Real-time Multimedia:Internet Phone study
• 7.4 Protocols for Real-Time Interactive Applications
  • RTP, RTCP, SIP
• 7.5 Distributing Multimedia: content distribution networks
• 7.6 Beyond Best Effort
• 7.7 Scheduling and Policing Mechanisms
• 7.8 Integrated Services and Differentiated Services
• 7.9 RSVP

第93页：原理面向 QoS 保证补充

原理面向 QoS 保证补充

• Basic fact of life:can not support traffic demands beyond link capacity Call Admission: flow declares its needs, network mayblock call (e.g., busy signal) if it cannot meet needs Principle 4R1R21.5 Mbps link 1 Mbpsphone 1 Mbpsphone

第94页：Qo S 保证场景

Qo S 保证场景

• Resource reservation
  • call setup, signaling (RSVP)
  • traffic, Qo S declaration
  • per-element admission control
  • Qo S-sensitive scheduling (e.g., WFQ)request/reply

第95页：IETF Integrated Services

IETF Integrated Services

• architecture for providing QOS guarantees in IPnetworks for individual application sessions
• resource reservation: routers maintain state info(a la VC) of allocated resources, Qo S req’s
• admit/deny new call setup requests:Question:can newly arriving flow be admittedwith performance guarantees while not violated Qo S guarantees made to already admitted flows?

第96页：Call Admission

Call Admission

• declare its QOS requirement
  • R-spec:defines the QOS being requested
• characterize traffic it will send into network
  • T-spec:defines traffic characteristics
• signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required)
  • RSVP

第97页：综合服务 Qo S：服务模型

综合服务 Qo S：服务模型

• worst case traffic arrival:leaky-bucket-policed source
• simple (mathematically provable)boundon delay[Parekh 1992, Cruz 1988]Controlled load service:
• "a quality of service closely approxi mating the Qo S thatsame flow would receivefrom an unloaded network element."WFQtoken rate, rbucket size, bper-flowrate, RD = b/Rmaxarrivingtraffic

第98页：因特网中的信令

因特网中的信令

• New requirement:reserve resources along end-to-endpath (end system, routers) for Qo S for multimedia applications
• RSVP:Resource Reservation Protocol [RFC 2205]
  • “ … allow users to communicate requirements to network inrobust and efficient way.” i.e., signaling !
• earlier Internet Signaling protocol: ST-II [RFC 1819]

第99页：RSVP Design Goals 1.accommodate

RSVP Design Goals 1.accommodate

RSVP Design Goals 1.accommodate heterogeneous receivers(different bandwidth along paths)2.accommodate different applicationswith differentre source requirements 3.makemulticast a first class service, with adaptationto multicast group membership 4.leverage existing multicast/unicast routing, withadaptation to changes in underlying unicast,multicast routes 5.control protocol overheadto grow (at worst) linearin # receivers 6.modular designfor heterogeneous underlying technologies

第100页：RSVP: does not…

RSVP: does not…

• specify how resources are to be reserved
• rather: a mechanism for communicating needs
• determine routes packets will take
• that’s the job of routing protocols
• signaling decoupled from routing
• interact with forwarding of packets
• separation of control (signaling) and data(forwarding) planes

第101页：RSVP 概述的操作

RSVP 概述的操作

• senders, receiver join a multicast group
  • done outside of RSVP
  • senders need not join group
• sender-to-network signaling
  • path message:make sender presence known to routers
  • path teardown: delete sender’s path state from routers
• receiver-to-network signaling
  • reservation message:reserve resources from sender(s) toreceiver
  • reservation teardown: remove receiver reservations
• network-to-end-system signaling
  • path error
  • reservation error

第102页：第7章小结

第7章小结

• classify multimedia applications
• identify network services applications need
• making the best of best effort service Protocols and Architectures
• specific protocols for best-effort
• mechanisms for providing Qo S
• architectures for Qo S
  • multiple classes of service
  • Qo S guarantees, admission control