Receiving application
Download
1 / 1

4. TCP-MM – extension to TCP-RTM - PowerPoint PPT Presentation


  • 135 Views
  • Uploaded on

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.

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

PowerPoint Slideshow about ' 4. TCP-MM – extension to TCP-RTM' - ora


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

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


ad