DOC PREVIEW
Stanford CS 144 - Lecture Notes

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Outline• Multimedia is different• Real Time Protocol (RTP)• Session Description Protocol (SDP)• Session Initiation Protocol (SIP)Elastic vs. Inelastic Workloads• Some applications adapt to network performance- Examples: file transfer, printing.- Will perform the same task regardless of bandwidth- Such workloads are elastic—they adapt fine to lowerperformance• Other apps have traffic performance requirements:- Example: video requires a certain available bandwidth- Workloads that fail if requirements not met are inelasticWhy is this an issue?• Most data networks provide best effort delivery- Try their best to deliver your data, but no guarantees• Traditional data applications:- Use protocols such as TCP to deal with data loss andunknown network available bandwidth,- Tend to generate data in bursts, and- Normally do not require any kinds of guarantees from thenetwork• Elastic workloads will often swamp inelastic ones- BitTorrent can make Skype sound terrible• Traditional networks have not been designed withQuality Of Service (QoS) in mindWhere do things break?EncoderDecoderVideoDecoderVideoVideoDecoderHubRouter1.5 Mb/sRouterHub700 kb/s700 kb/s700 kb/sVideoEncoderVideoVideoEncoder•Things break when there is a contention for resources• Service may be unacceptable for allExample of a Network with QoS:The Phone Network• Before you can communicate- Must negotiate a channel with the network- If network lacks the resources, your call is not completed• If call is completed, you “own” circuit- Yours for the duration of the call- Regardless of the additional traffic in the network• Circuit has appropriate capacity for voiceQoS Components• Must know traffic characteristics and requirements- Must describe them to the network to reserve bandwidth• Need signaling protocol betw. nodes & net. mgmt• The Network must implement Admission Control- Reject connections exceeding available bandwidth• The Network may also implement Traffic Policing- Make sure traffic emitted by the nodes conform to theagreed parametersWhere to Provide?• 1990s and early 2000s saw a lot of work on getting QoSinto layer 3: Resource ReSerVation Protocol (RSVP)- Fine for walled garden networks, e.g., IP-telephony backbones- Consumer applications do not want to assume QoS support• There’s a lot more to multimedia than simple QoS- Session establishment, media negotiation• Higher layers need to be involved- Transport: Real Time Protocol (RTP)- Session: Session Description Protocol (SDP)- Application: Session Initiation Protocol (SIP)Outline• Multimedia is different• Real Time Protocol (RTP)• Session Description Protocol (SDP)• Session Initiation Protocol (SIP)RTP [RFC 3550]• Provides end-to-end delivery services for datawith real-time characteristics- E.g. interactive audio and video- Services include: Source & payload type identification,Sequence numbering, Time-stamping, Delivery monitoring• Typically used on top of UDP- Relies on UDP for multiplexing & checksums• Work over other network or transport protocols- Lower-level must provide framing & length indicationRTP continued• Supports data transfer to multiple destinations- Uses network-level multicast if available• Does not ensure timely delivery/QoS guarantees- Relies on lower-layer services to do so• Does not guarantee in-order delivery• Does not even guarantee delivery- Underlying network need not be reliable- Underlying network need not deliver packets in sequence- RTP sequence numbers determine proper location of packetTwo parts to RTP1. RTP- Carries data that has real time properties2. RTCP- Monitors quality of service- Conveys information about participants in a session(for “loosely controlled” sessions)RTP protocol framework• RTP is not a complete protocol- It is a protocol framework, deliberately not complete- Tailored to applications through modification, not options• Each applications needs a profile specification- defines set of payload type codes- defines mapping of payload types to payload formats• Also need actual payload format specificationRTP Session• Association among a set of participantscommunicating with RTP• A session is defined by a particular pair ofdestination transport addresses- One network address- A pair of ports (one for RTP and one for RTCP)- May be common to all participants (as in IP multicast)- May be different for each (individual network address +common port address)Synchronization Source (SSRC)• Source of a stream of RTP packets- Randomly chosen 32-bit numeric identifier- Intended to be globally unique- Carried in RTP header (not dependent on network address)• Timing & sequence number space are per-SSRC- Lets receiver separately handle packets from same source- RTCP sender/receiver reports are per SSRC• One participant may use multiple SSRCs- Should use one for each stream- Different streams may have different media clock rates- Or one stream may switch encodings mid-stream• Binding of SSRCs is provided through RTCP- E.g., if participant uses multiple cameras in one sessionRTP Translators and Mixers• Intermediate act as gateways at RTP layer- Allow RTP traffic to pass through firewalls- Mix and/or recode data to fit over a low bandwidth link• Translators leave original SSRC intact- So sources distinct even when all packets from translator- Translator may change payload type or combine packets• Mixers combine streams from multiple sources- Output requires new SSRC with new seq/timestamps- Original sources conveyed in each packet using“contributing sources” (CSRC) listRTP Packet• Fixed RTP packet header• List of contributing sources (possibly empty)• RTP Payload- E.g. audio samples, compressed video data, etc. . . .RTP Data Header0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X| CC |M| PT | sequence number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| timestamp |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| synchronization source (SSRC) identifier |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| contributing source (CSRC) identifiers || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RTP Data Header details• Padding (P, 1 bit)- Packet ends w. padding octets ending in padding length- E.g., useful when encrypting with block cipher• Extension (X, 1


View Full Document

Stanford CS 144 - Lecture Notes

Documents in this Course
IP Review

IP Review

22 pages

Load more
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?