protocols without qos support n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Protocols without QoS Support PowerPoint Presentation
Download Presentation
Protocols without QoS Support

Loading in 2 Seconds...

play fullscreen
1 / 78

Protocols without QoS Support - PowerPoint PPT Presentation


  • 152 Views
  • Updated on

INF 5070 – Media Storage and Distribution Systems:. Protocols without QoS Support. 22/9 - 2003. Overview. Non-QoS protocols: Transport level protocols Application layer protocols Signaling protocols. Requirements for Continuous Media. Acceptable delay

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Protocols without QoS Support


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. INF 5070 – Media Storage and Distribution Systems: Protocolswithout QoS Support 22/9 - 2003

    2. Overview Non-QoS protocols: • Transport level protocols • Application layer protocols • Signaling protocols

    3. Requirements for Continuous Media • Acceptable delay • Seconds in asynchronous on-demand applications • Milliseconds in synchronous interpersonal communication • Acceptable jitter • Milliseconds at the application level • Tolerable buffer size for jitter compensation • Delay and jitter include retransmission, error-correction, ... • Acceptable continuity • Streams must be displayed in sequence • Streams must be displayed at acceptable, consistent quality • Acceptable synchronity • Inter-media: different media played out at matching times • Intra-media: time between successive packets must be conveyed to receiver

    4. Basic Techniques • Delay and jitter • Reservation (sender, receiver, network) • Buffering (receiver) • Scaling (sender) • Continuity • Real-time packet re-ordering (receiver) • Loss detection and compensation • Retransmission • Forward error correction • Stream switching (encoding & server) • Synchronity • Fate-sharing and route-sharing (networks with QoS-support) • Time-stamped packets (encoding) • Multiplexing (encoding, server, network) • Buffering (client) • Smoothing (server)

    5. QoS vs. Non–QoS Approaches • Internet without network QoS support • Internet applications must cope with networking problems • Application itself or middleware • "Cope with" means either "adapt to" or "don’t care about“ • "Adapt to" must deal with TCP-like service variations • "Don’t care about" approach is considered "unfair“ • "Don’t care about" approach cannot work with TCP • Internet with network QoS support • Application must specify their needs • Internet infrastructure must change – negotiation of QoS parameters • Routers need more features • Keep QoS-related information • Identify packets as QoS-worthy or not • Treat packets differently keep routing consistent

    6. Various • Not a concern • No flexibility • IPv4 • IPv6 • Limited flexibility • UDP • TCP • New developments • Complete freedom • Compatibility is an applicationissue Protocols for Non–QoS Approaches Application Layer • TCP/IP Protocol stack • Has only 4 layers • IP is central • Nothing must compete with IP at the network layer • There is no QoS support • Routing is transparent for the application • Transport-unrelated functions are application-layer tasks Transport Layer Network Layer Physical Layer

    7. Traditional Transport Layer Approaches

    8. Described in Internet Engineering Note 88 Request for Comments 768 Internet Standard 6 Connection-less Unreliable Unordered Datagram-oriented Uncontrolled Optionally checksummed Often used in multimedia streaming applications – can build whatever needed on top Simple add pseudo-header calculate checksum finish header send to IP No... ... guarantees ... fairness ... User Datagram Protocol (UDP)

    9. Described in Internet Engineering Note 2 Request for Comments 793 Internet Standard 7 Connection-oriented Reliable Ordered Stream-oriented Flow-controlled Checksummed High fraction of today’s traffic is TCP-based, e.g., electronic mail web file transfers ... We need to know some details about the TCP behavior/traffic – we’ll briefly look at TCP ... ...retransmission timeouts ...congestion control ...friendliness Transmission Control Protocol (TCP)

    10. RTT 1 2 3 4 5 6 time TCP Round Trip Time Estimation EstimatedRTT = (1 - ) * EstimatedRTT +  * SampleRTTusually,  = 0.125 [RFC 2988] sender receiver Initially, EstimatedRTT is based on packets sent during “handshake” operation (connection setup), e.g., 3 round 1 The following RTTs are calculated using the formula above taking one SampleRTT each round: - going slightly up if EstimatedRTT < SampleRTT - going slightly down if EstimatedRTT > SampleRTT - e.g. ( = 0.5 ): round 2 2) EstimatedRTT = .5 * 3 + .5 * 3= 3 3) EstimatedRTT = .5 * 3 + .5 * 5= 4 round 3 4) EstimatedRTT = .5 * 4 + .5 * 1 = 2.5 NOTE: the next RTT isnot necessarily ready before the corresponding round starts (and we startsending the next packets) round 4

    11. TCP Timeout • The EstimatedRTT is used for the retransmission timer – timeout interval should be • ≥ estimatedRTT – avoiding unnecessary retransmissions • but not too much larger – slow retransmit, large delay • margin should be large when lot of fluctuations, otherwise small • Additionally, TCP uses RTT variation – deviated RTT: DevRTT = (1 - ) * DevRTT +  * | SampleRTT – EstimatedRTT |, usually, = 0.25 • Retransmission interval given byTimeoutInterval = EstimatedRTT + 4 * DevRTT • Modifications • timeout interval doubling each timeout (form of congestion control) • fast retransmission – three duplicate ACKs (decrease delay)

    12. TCP Congestion Control • TCP limit sending rate as a function of perceived network congestion • little traffic – increase sending rate • much traffic – reduce sending rate • Congestion algorithm has three major “components”: • additive-increase, multiplicative-decrease (AIMD) • slow-start • reaction to timeout events

    13. 16 8 4 2 1 TCP Congestion Control Initially, the CONGESTION WINDOW is 1 MSS (message segment size) sender receiver round 1 Then, the size increases by 1 for each received ACK (until a threshold is reached or an ACK is missing) sent packetsper round(congestion window) round 2 round 3 round 4 time

    14. sent packetsper round(congestion window) 65 20 16 40 10 50 60 70 30 25 35 75 55 45 80 15 8 4 5 1 2 time TCP Congestion Control Normally, the threshold is 65 K • Losing a single packet (TCP Tahoe): • threshold drops to halve CONGESTION WINDOW • CONGESTION WINDOW back to 1 • Losing a single packet (TCP Reno): • threshold drops to halve CONGESTION WINDOW • CONGESTION WINDOW back to new threshold

    15. TCP Congestion Control • TCP congestion control is based on the notion that the network is a “black box” – congestion indicated by a loss • Sufficient for best-effort applications, but losses might severely hurt traffic like audio and video streams  congestion indication better enabling features like quality adaptation • Use active queue management to detect congestion

    16. Random Early Detection (RED) • Random Early Detection (discard/drop) (RED) uses active queue management • Drops packet in an intermediate node based on average queue length exceeding a threshold • TCP receiver reports loss in ACK • sender applies MD • Current Internet RED • restricted to packet drop as congestion indication, but • could also only indicate congestion setting congestion experienced (CE) bit in packet header

    17. Early Congestion Notification (ECN) • Early Congestion Notification (ECN) - RFC 2481 • an end-to-end congestion avoidance mechanism • Implemented in routers and supported by end-systems • Not multimedia-specific, but very TCP-specific • Two IP header bits used • ECT - ECN Capable Transport, set by sender • CE - Congestion Experienced, may be set by router • Extends RED • if packet has ECT bit set • ECN node sets CE bit • TCP receiver sets ECN bit in ACK • sender applies multiple decrease (AIMD) • else • Act like RED

    18. Early Congestion Notification (ECN) • Effects • Congestion is not oscillating - RED & ECN • ECN-packets are never lost on uncongested links • Receiving an ECN mark means • TCP window decrease • No packet loss • No retransmission

    19. A TCP connection’s throughput is bounded • wmax - maximum retransmission window size • RTT - round-trip time The TCP send rate limit is In case of at least one loss in an RTT • Congestion windows size changes • AIMD algorithm • additive increase, multiple decrease In case of no loss , TCP Friendliness • That’s not generally true • Bigger RTT • higher loss probability per RTT • slower recovery • Disadvantage for long-distance traffic • TCP is said to be fair • Streams that share a path will reach an equal share

    20. P – packet loss rate C – constant value Rr – packet arrival rate TCP Friendliness • A protocol is TCP-friendly if • Colloquial: It long-term averagethroughput is not bigger than TCP’s • Formal: Its arrival rate is at mostsome constant over the square rootof the packet loss rate • The AIMD algorithm with a≠1/2 and b≠1 is still TCP-friendly, if the rule is not violated • TCP-friendly protocols may - if the rule is not violated - • Probe for available bandwidth faster than TCP • Adapt to bandwidth changes more slowly than TCP • Use different equations or statistics, i.e., not AIMD • Not use slow start (i.e., don’t start with w=0)

    21. Comparison of Non-QoS Philosophies

    22. Using Standard Protocols

    23. RTP: An Application Layer Approach

    24. Real-time Transport Protocol (RTP) • Real-time Transport Protocol (RTP) • RFC 1889 • Designed for requirements of real-time data transport • NOT real-time • NOT a transport protocol • Two Components: • Real-Time Transport Protocol (RTP) • RTP Control Protocol (RTCP) • Provides end-to-end transport functions • Scalable in multicast scenarios • Media independent • Mixer and translator support • RTCP for QoS feedback and session information

    25. Real-time Transport Protocol (RTP) • No premise on underlying resources • layered above transport protocol • no reservation / guarantees • Integrated with applications • RTP follows principles of • Application Level Framing and • Integrated Layer Processing

    26. RTP Control Protocol (RTCP) • Companion protocol to RTP (tight integration with RTP) • Monitoring • of QoS • of application performance • Feedback to members of a group about delivery quality, loss, etc. • Sources may adjust data rate • Receivers can determine if QoS problems are local or network-wide • Loose session control • Convey information about participants • Convey information about session relationships • Automatic adjustment to overhead • report frequency based on participant count • Typically, “RTP does ...” means “RTP with RTCP does ...”

    27. RTP • RTP services are: • Sequencing • Synchronization • Payload identification • QoS feedback and session information • RTP supports • Multicast in a scalable way • Generic real-time media and changing codecs on the fly • Mixers and translators to adapt to bandwidth limitations • Encryption • RTP is not designed for: • Reliable delivery • QoS provision or reservation

    28. RTP Functions • RTP with RTCP provides: • Support for transmission of real-time data • Over multicast or unicast network services • Functional basis for this: • Loss detection – sequence numbering • Determination of media encoding • Synchronization – timing • Framing - “guidelines” in payload format definitions • Encryption • Unicast and multicast support • Support for stream “translation” and “mixing” (SSRC; CSRC)

    29. RTP Profile (RFC 1890) • Set of standard encodings and payload types • Audio: e.g. PCM-u, GSM, G.721 • Video: e.g. JPEG, H.261 • Number of samples or frames in RTP packet • Sample-based audio: no limit on number of samples • Frame-based audio: several frames in RTP packet allowed • Clock rate for timestamp • Packetized audio: default packetization interval 20 ms • Video: normally 90 kHz, other rates possible

    30. RTP Profiles • Payload type identification • RTP provides services needed for generic A/V transport • Particular codecs with additional requirements • Payload formats defined for each codec: syntax and semantic of RTP payload • Payload types • static: RTP AV profile document • dynamic: agreement on per-session basis • Profiles and Payload Formats in RTP Framework

    31. RTP Quality Adaptation • Component interoperations for control of quality • Evaluation of sender and receiver reports • Modification of encoding schemes and parameters • Adaptation of transmission rates • Hook for possible retransmissions (outside RTP)

    32. a byte RTP Packet Format Typical IETF RFC bit-exact representation a longword (32 bit)

    33. RTP Packet Format Version number, always 2 Padding indicator bitif set, number of padding bytes is in last byte of payload Header extension bit True if header extension is present 7 bit payload type Allows identification of the payload’s content type Marker bit Meaning depends on payload profile, e.g. frame boundary 4 bit CSRC count, indicates the number of contributing sources in the header

    34. RTP Packet Format 16 bit sequence number 32 bit timestamp 32 bit SSRC Synchronization source identifier, a random number identifying the sender Header extension, multiples of 32 bit Several 32 bit CSRC Contribution source identifier, the number is indicated by CC A mixer copies the original sources’ SSRCs here

    35. RTP Packet Format • Relatively long header (>40 bytes) • overhead carrying possibly small payload • header compression • other means to reduce bandwidth (e.g. silence suppression) • No length field • exactly one RTP packet carried in UDP packet • Can use TCP or ATM AAL5 • do-it-yourself packaging • Header extensions for payload specific fields possible • specific codecs • error recovery mechanisms

    36. RTCP Packets • Several RTCP packets carried in one compound packet • RTCP Packet Structure • SR Sender Report (statistics from active senders: bytes sent -> estimate rate) • RR Receiver Report (statistics from receivers) • SDES Source Descriptions (sources as “chunks” with several items like canonical names, email, location,...) • BYE explicit leave • APP extensions, application specific

    37. RTCP Sender / Receiver Reports • Sender report • Sender Information • Timestamps (RTP, NTP) • Packet Count, Byte Count • List of statistics per source heard (receiver reports) • Receiver report • for each source: • loss statistics • inter-arrival jitter • timestamp of last SR • delay between reception of last SR and sending of RR • Analysis of reports • cumulative counts for short and long time measurements • NTP timestamp for encoding- and profile independent monitoring

    38. RTP Mixer • Mixer • Reconstructs constant spacing generated by sender • Translates audio encoding to a lower-bandwidth • Mixes reconstructed audio streams into a single stream • Resynchronizes incoming audio packets • New synchronization source value (SSRC) stored in packet • Incoming SSRCs are copied into the contributing synchronization source list (CSRC) • Forwards the mixed packet stream • Useful in conference bridges

    39. RTP Translator • Translation between protocols • e.g., between IP and ST-2 • Two types of translators are installed • Translation between encoding of data • e.g. for reduction of bandwidth without adapting sources • No resynchronization in translators • SSRC and CSRC remain unchanged

    40. RTPIdentifiers SSRC chosen by sender S1 SSRC chosen by mixer M1 S1 S3 S3:19 S1:10 M1:33 (10,1) M1:33 (10,1) M1 R1 M2 T1 S4:13 M2:17 (19,13,33) S2:1 S4:13 S2 S4 Translators keep SSRCs and CSRCs CSRCs from mixed sources S1 and S2 CSRCs contain previous SSRCs, but not previous CSRCs

    41. Protocol Development • Changes and extensions to RTP • Scalability on very large multicast groups • Congestion Control • Algorithms to calculate RTCP packet rate • Several profile and payload formats • Efficient packetization of Audio / Video • RTCP-based retransmission • Loss / error recovery

    42. Other Application Layer Approaches

    43. Progressive Download • In-band in long-running HTTP response • Plain file for the web server • Even simpler than FTP • No user interactions – start, stop, ... • If packet loss is ... • ...low – rate control by back-pressure from client • ...high – client’s problem • Applicability • Theoretical • For very low-bit-rate codecs • For very loss-intolerant codecs • Practical • All low-volume web servers

    44. Progressive Download Web server Backpressure ! Decoder Receive buffer TCP Stack TCP Stack Can recreate timing from media file Accepts buffer underruns Serves requested files as quickly as possible Network (uncongested)

    45. Progressive Download Web server Retransmission Timeout Decoder Receive buffer TCP Stack TCP Stack Network (congested)

    46. Priority Progress Streaming • Unmodified TCP (other transports conceivable) • Unmodified MPEG-1 video-in (other encoding formats conceivable) • Real-time video processing • Convert MPEG to Spatially Scalable MPEG (SPEG) – 10-25% overhead • Packetize SPEG to separate by frame and by SNR quality step • More variations conceivable: color, resolution • Assign priorities to SPEG packets • Dynamic utility curves indicate preference for frame or SNR dropping • Write SPEG packets in real-time into reordering priority progress queue • Queues are long • Much longer than TCP max window • Dynamically adjustment allows fast start and dynamic growth • With longer queues • Total delay is increased • High priority packets win more often

    47. High priority Medium priority To TCP Low priority Priority Progress Queue Priority Progress Streaming Packets to send

    48. Receiver-driven Layered Multicast (RLM) • Requires • IP multicast • layered video codec (preferably exponential thickness) • Operation • Each video layer is one IP multicast group • Receivers join the base layer and extension layers • If they experience loss, they drop layers (leave IP multicast groups) • To add layers, they perform “join experiments” • Advantages • Receiver-only decision • Congestion affects only sub-tree quality • Multicast trees are pruned, sub-trees have only necessary traffic

    49. Receiver-driven Layered Multicast (RLM) • Requires • IP multicast • layered video codec (preferably exponential thickness) • Operation • Each video layer is one IP multicast group • Receivers join the base layer and extension layers • If they experience loss, they drop layers (leave IP multicast groups) • To add layers, they perform "join experiments“ • Advantages • Receiver-only decision • Congestion affects only sub-tree quality • Multicast trees are pruned, sub-trees have only necessary traffic

    50. Receiver-driven Layered Multicast (RLM)