1 / 17

TCP-FCW – transport protocol for real-time transmissions on high-loss networks

TCP-FCW – transport protocol for real-time transmissions on high-loss networks. Sergei Kozlov, 23-02-2004. Agenda. RTP/RTCP versus TCP TCP-RTM (TCP Real-Time Mode) TCP-RTM and bursty losses “Free congestion window” (FCW) concept Short evaluation of TCP-FCW Very briefly – future work.

kareem
Download Presentation

TCP-FCW – transport protocol for real-time transmissions on high-loss networks

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TCP-FCW – transport protocol for real-time transmissions on high-loss networks Sergei Kozlov, 23-02-2004

  2. Agenda • RTP/RTCP versus TCP • TCP-RTM (TCP Real-Time Mode) • TCP-RTM and bursty losses • “Free congestion window” (FCW) concept • Short evaluation of TCP-FCW • Very briefly – future work

  3. RTP/RTCP • RTP is widely used for RT streaming • RTP = UDP + time-stamping • no reliability – what is lost is lost • no in-sequence guarantees – upper layers should take care of it • low end-to-end delay, low jitter • RTCP – a protocol for controlling the stream • feedback on the quality of data • delivery to the sender of a participant’s canonical name • awareness of participants about each other

  4. TCP (I) • Guaranteed delivery • what you send is what you receive (sooner or later…) • Sophisticated retransmission mechanism • based on RTT measurements, duplicate acknowledgments, timeouts etc. • Congestion-control mechanism • this is how it stays non-aggressive to the others • It’s designed for reliable data transfers • favors reliability over timeliness • may introduce unwanted delays for RT data

  5. sender receiver data ack data ack TCP (II) – retransmissions and sliding window • Straight-forward acknowledgments • Ineffective usage of the network Sending application snd_wnd • Sliding window (snd_wnd) TCP-buffer ? next_to_be_acked next_to_be_sent not yet send sent & acknowledged sent but not acknowledged empty buffer

  6. TCP-RTM: “semi-reliable” protocol * • Combines retransmission abilities of TCP and non-blocking behavior of RTP • Retransmission mechanisms reused from TCP • Packets that cannot be delivered in timely fashion are being skipped • Application techniques resemble those for RTP (surveyed later) • Requires minimum of TCP-code modifications, can be implemented as another TCP-option * Sam Liang, David Cheriton, “TCP-RTM: Using TCP for Real Time Applications,” Submitted to IEEE ICNP ’02, 2002

  7. TCP-RTM receiver – “read-over-hole” technique Receiving application snd_cwnd step1 ? re-requeston dup-acks Receiving application step2 ! Too late to resend - acknowledge Receiving application step3 segment consumed by application skipped segment segment received but not yet consumed by application empty buffer

  8. TCP-RTM sender Step 1 Step 2 Sending app Sending app TCP TCP SND_BUF SND_BUF NextByteToSend NextByteToSend

  9. TCP-RTM – application techniques • Receiver application doesn’t read from the buffer until the data is needed for timely playback • this provides fixed play-back delay • timestamps are needed for this • TCP-RTM supports application-level framing (ALF) • one application frame per TCP-segment – hence, always integral application frames are lost • every application write/read operation deals with 1 application level frame • ALF helps effective recovery from the losses

  10. Wireless LAN – an example of a burst loss network Managed WLAN (NatLab), UDP packets, packet_size=500B, 100 packets/sec

  11. Receiving application snd_cwnd step1 ? ? ? Receiving application (blocked) step2 ? ? ? re-send on rto step3 Receiving application out-of-date TCP-RTM and burst losses segments consumed by application received out-of-date sergments sergments received but not yet consumed by application empty buffer

  12. Recovery price • rto is doubled with every packet loss buf_size = 64K, frame_size=1K, frames sent every period=20mS Near-exponential dependency – congestion window doesn’t grow large enough to trigger the dup-ack retransmission * - TCP-buffer gets full

  13. TCP-FCW vs TCP-RTM • TCP-RTM wasn’t meant to be used on burst losses networks • Losses of more than one segment in a row are not expected to happen • To be used on the real Internet • Be TCP friendly (use congestion avoidance) • TCP-FCW meets different assumptions • To be used on the QoS enabled networks with bandwidth reservations • “Send as fast as you can, but not faster than requested by the application” • Thus, we can control the bit-rate of the transmission on the application level • Provide “immediate recovery” – no slow start • It’s not meant to be used on the current Internet

  14. TCP-FCW: “free-congestion-window” Receiving application step1 ? ? ? re-request – dup-acks again! Receiving application step2 ! resent Receiving application step3 packet consumed by application skipped packet recovered packet packet received but not consumed by application empty buffer

  15. Evaluation • Result: exponential growth of pbd in case of TCP-RTM vs linear growth in case of TCP-FCW

  16. Further work • TCP-MM (multi-media) – the content-aware transport protocol • Firstly - video • It will “know” about I,P,B frames of a video stream • Not segment, but video-frame-oriented

  17. Questions

More Related