1. PROGRESS project: Quality of Service in In-Home Digital Networks System Architecture and Networking 4. TCP-MM – extension to TCP-RTM Affiliation 1) Eindhoven University of Technology Department of Mathematics and Computer Science HG 6.57, P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlands 2) Philips Research NatLab Prof. Holstlaan 4, 5656AA Eindhoven, The Netherlands TCP-MM – a real-time transport protocol for multimedia in in-home networks Author: S. Kozlov 1. Co-authors: Peter v.d. Stok 1,2, Johan Lukkien 1 About the Author Sergei Kozlov received his M.Sc. in Informatics from the Department of Applied Mathematics of Belarussian State University in 1998. In 2003 Sergei started a Ph.D. project within the SAN group of Computer Science Department, TU/e in collaboration with Philips Research NatLab S ingle packet losses B ursty losses Bursty loss size, packets Minimum pbd to cover losses, mS 170 2260 3220 4700 5…-* 2. Evaluation of TCP-RTM [1] Narrow congestion window problem: Step 1. Congestion window size (snd_cwnd) prevents delivery of packets after the “hole”. Hence, receiver cannot send immediate acknowledgement. Step 2. The application blocks at the moment it requests the packets that were lost. The connection freezes untill a retransmission time-out occurs. Step 3. The application receives a burst of packets, which are out-of-date. Time-outs grow exponentially with every consecutively lost packet: frame_size=1024K, frames sent every 20mS * for loss sizes >= 5 - sending buffer gets overflowed 5. Conclusions - TCP-RTM is not suitable for real-time streaming over networks where bursty losses take place regularly - “Free congestion window” (FCW) modification helps avoiding long “recovery” times after a bursty loss has occurred - Concept of FCW was the key extension of TCP-RTM, which lead to the creation of the proposed TCP-MM (multi-media) protocol - Play-back delay needed to resent the lost packets with TCP-MM depends linearly on the burst size 1. Introduction Digital networking is a fundamental building block of the Ambient Intelligence environment. A crucial point here is the effective use of network resources. As part of the task to enable multimedia streaming over the network we investigate real-time transport protocols and their applicability for wireless networks. Play-back delay, mS Burst size, packets Receiving application ? re-request step1 step2 step3 ?? ! resent packet consumed by application packet received but not consumed by application skipped packet empty buffer recovered packet Reference: [1] TCP-RTM: Using TCP for Real Time Multimedia Applications. Sam Liang, David Chariton. Distributed Systems Group, Stanford University. 2003 The figure shows that in case of TCP-MM recovery play-back delay is linearly (versus quadratic for TCP-RTM) bounded to the burst size. 3. Loss properties of wireless networks Observations and conclusions: - Bursty losses of size up to 80 packets occur regularly (e.g. because of “hand-overs”) - An adaptation of TCP-RTM should be made to allow multimedia streams Measurements set-up: infrastructure wireless networks by NatLab, Philips Research Eindhoven Conclusions - TCP-RTM performs well on networks with non-bursty losses… - … but bursty losses make TCP-RTM hardly applicable “Skip-over-hole” technique: Step 1. While there are packets for the application to read, “holes” can still be filled up. Step 2. When the application meets a “hole”, TCP-RTM accomplishes a “skip-over-hole” – it delivers the next arrived packet from out-of-order queue. In meanwhile, it acknowledges the lost packet to the receiver. Step 3. The application has to handle the packet loss on application level Assumptions on the network conditions: - Only occasional single packets are lost More than 90% of the holes get filled when the assumptions are met* * with: pbd=250mS, rto<60mS, loss rate <10% empty buffer Receiving application ? Receiving application (blocked) Receiving application re-request on rto step1 step2 step3 ?? snd_cwnd ??? out-of-date packet consumed by application received out-of-date packet packet received but not yet consumed by application “Free congestion window” (FCW) concept Step 1. Number of packets-on-air is not limited with snd_cwnd, hence the packets after the hole are not prevented from being sent. It allows receiver acknowledge immediately. Step 2. To the moment when the application requests lost packets, those can be (partially) resent. Step 3. The application continues receiving timely arrived packets. Measurements conditions - Controlled packet losses are introduced in the kernel of the sending machine -Clocks at the machines are synchronized at the moment when the connection is established Receiving application ? ! Too late to resend - acknowledge re-request step1 step2 step3 packet consumed by application packet received but not yet consumed by application skipped packet empty buffer snd_cwnd