4. TCP-MM – extension to TCP-RTM

1. Receiving application snd_cwnd step1 ? re-request Receiving application step2 ! Too late to resend - acknowledge step3 Receiving application Receiving application step1 ? ? ? re-request packet received but not yet consumed by application packet consumed by application Receiving application step2 empty buffer skipped packet ! resent Receiving application step3 packet received but not consumed by application packet consumed by application empty buffer skipped packet recovered packet Receiving application snd_cwnd step1 ? ? ? Receiving application (blocked) step2 ? ? ? re-requeston rto step3 Receiving application out-of-date packet received but not yet consumed by application packet consumed by application empty buffer received out-of-date packet Play-back delay, mS Burst size, packets TCP-MM – a real-time transport protocol for multimedia in in-home networksAuthor: S. Kozlov 1. Co-authors: Peter v.d. Stok 1,2, Johan Lukkien 1 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. 3. Loss properties of wireless networks Measurements set-up: infrastructure wireless networks by NatLab, Philips Research Eindhoven • 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 2. Evaluation of TCP-RTM [1] Single packet losses “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 4. TCP-MM – extension to TCP-RTM “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. More than 90% of the holes get filled when the assumptions are met* * with: pbd=250mS, rto<60mS, loss rate <10% Bursty losses 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: 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. • 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 • 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 • Conclusions • TCP-RTM performs well on networks with non-bursty losses… • … but bursty losses make TCP-RTM hardly applicable frame_size=1024K, frames sent every 20mS * for loss sizes >= 5 - sending buffer gets overflowed Reference: [1] TCP-RTM: Using TCP for Real Time Multimedia Applications. Sam Liang, David Chariton. Distributed Systems Group, Stanford University. 2003 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 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