PROGRESS project: Quality of Service in In-Home Digital Networks

System Architecture and Networking

4. TCP-MM – extension to TCP-RTM

Affiliation1) Eindhoven University of Technology

Department of Mathematics and Computer Science

HG 6.57, P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlands2) 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 AuthorSergei 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

Single packet losses

Bursty losses

Bursty loss size, packets

Minimum pbd to cover losses, mS

1 70

2 260

3 220

4 700

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.

TCP-RTM vs TCP-MM

0

100

200

300

400

500

600

700

800

1 2 3 4 5 6 7 8 9 10

Play-back delay, mS

Burst size, packets

Receiving application

?

Receiving application

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

?

Receiving application

!

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