Protocols without QoS Support

1. INF 5070 – Media Servers and Distribution Systems: Protocolswithout QoS Support 20/9 - 2004

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, ...

4. Requirements for Continuous Media • Acceptable continuity • Streams must be displayed in sequence • Streams must be displayed at acceptable, consistent quality • Acceptable synchronity • Intra-media: time between successive packets must be conveyed to receiver • Inter-media: different media played out at matching times

5. 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)

6. 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” which must deal with TCP-like service variations • … “don’t care about” which is considered “unfair” and 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

7. Various • Not a concern • No flexibility – IP is THE protocol • 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

8. Traditional Transport Layer Approaches

9. 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 (UDP/IP) calculate checksum finish header send to IP No... ... guarantees ... fairness ... User Datagram Protocol (UDP)

10. Described in Internet Engineering Note 2 Request for Comments 793 Internet Standard 7 Connection-oriented Reliable Ordered Stream-oriented Flow-controlled Checksummed Complex compared to UDP 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)

11. 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

12. TCP Retransmission 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)

13. 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

14. 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 increasesby 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

15. 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

16. TCP Congestion Control Alternatives • Why alternatives? • Improve throughput and variance • Early TCP implementations did little to minimize network congestion • Loss indication forces setting new congestion window threshold to half of the last congestion window size • But … • … what else to conclude from the loss? • … which packets to retransmit?

17. TCP Congestion Control Alternatives • Original TCP • not in use • TCP Tahoe • TCP Reno • TCP New-Reno • standard TCP headers • TCP SACK (Selective Acknowledgements) • TCP FACK (Forward Acknowledgements) • must use a TCP option • RFC 2018 “TCP Selective Acknowledgment Options”

18. Data TCP Congestion Control Alternatives • TCP/IP Header Format for TCP Tahoe, Reno and New Reno Version IHL PRE Type of service ToS Total length Identification D M Fragment offset Time to live Protocol Header checksum IP header Source address Destination Address Options Source port Destination port Sequence number TCP header Piggyback acknowledgement THL unused U A P R S F Advertised window Checksum Urgent pointer THL – TCP header length U: URG – urgent A: ACK – acknowledgement P: PSH – push R: RST – reset S: SYN – sync F: FIN – finalize

19. Data 5 SACK opt. len. Left edge 1st block Right edge 1st block … Right edge last block TCP Congestion Control Alternatives • TCP/IP Header Format for TCP SACK and FACK Version IHL PRE Type of service ToS Total length Identification D M Fragment offset Time to live Protocol Header checksum IP header Source address Left edge: first sequence number of a block of received packet after a lostpacket Destination Address Options Source port Destination port Right edge: first sequence number AFTERthat block Sequence number Piggyback acknowledgement THL unused U A P R S F Advertised window Only 40 bytes TCP options allowed, therefore never more than 4 blocks reported at once Checksum Urgent pointer TCP header 5 SACK opt. len. Left edge 1st block, bits 31-16 Left edge 1st block, bits 15-0 Right edge 1st block, bits 31-16 Sequence number of packet that triggered ACK must be in first block unless it is in the sequence number field Right edge 1st block, bits 15-0 Left edge 2nd block, bits 31-16 Left edge 2nd block, bits 15-0 … … Right edge last block, bits 15-0 Always use as many blocks as possible

20. TCP Congestion Control Alternatives

21. Simulation results Lossy transfer with small delays (link: 500kbps, 105ms delay):

22. 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 can enable features like quality adaptation • Use active queue management to detect congestion

23. 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

24. 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

25. 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

26. 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 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

27. 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 • Thus, if the rule is not violated … • … the AIMD algorithm with a ≠ 1/2 and b ≠ 1 is still TCP-friendly • … TCP-friendly protocols may • 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)

28. Comparison of Non-QoS Philosophies

29. Using Standard Protocols

30. RTP: An Application Layer Approach

31. 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

32. 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

33. 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 ...”

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

35. RTP Quality Adaptation Application Application Encoding Decoding RTP RTCP RTCP RTP UDP/IP UDP/IP • 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)

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

37. 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

38. RTP Packet Format 16 bit sequence number (ordering and loss detection) 32 bit timestamp (synchronization) 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

39. RTP Packet Format • Relatively long header (>40 bytes) • large overhead when carrying small payloads • 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, if do-it-yourself packaging • Header extensions for payload specific fields possible • specific codecs • error recovery mechanisms

40. 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

41. RTP Mixer • Mixes reconstructed streams into a single stream • Reconstructs constant spacing generated by sender • Resynchronizes incoming 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 for example in conference bridges

42. 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

43. 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

44. 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

45. Other Application Layer Approaches

46. 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

47. 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)

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

49. 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

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