supporting heterogeneous packet flows in the internet n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Supporting Heterogeneous Packet Flows in the Internet PowerPoint Presentation
Download Presentation
Supporting Heterogeneous Packet Flows in the Internet

Loading in 2 Seconds...

play fullscreen
1 / 15
doria

Supporting Heterogeneous Packet Flows in the Internet - PowerPoint PPT Presentation

116 Views
Download Presentation
Supporting Heterogeneous Packet Flows in the Internet
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

  1. Supporting Heterogeneous Packet Flows in the Internet Jia Ru Li, Sungwon Ha, Vaduvur Bharghavan TIMELY Research Group http://timely.crhc.uiuc.edu University of Illinois at Urbana-Champaign {juru,s-ha,bharghav}@timely.crhc.uiuc.edu http://timely.crhc.uiuc.edu

  2. Heterogeneous Packet Flows In a heterogeneous packet flow, different packets of the same flow can have different QoS requirements • Multimedia flows are “heterogeneous” in nature • e.g. MPEG (control, I, P, and B frames), VR (control, text, audio, video), etc. • Applications may have “frame-specific” QoS policies for reliability, priority, deadlines, dependencies • Goal is to maximize the “goodput” for the application while adapting to the dynamics of the network • Application specifies the QoS policies; transport layer provides the mechanisms to implement these policies What are the trade-offs in moving the mechanisms for implementing QoS policies in heterogeneous packet flows from the application to the transport?

  3. Current Transport Protocols Unreliable Reliable UDP • TCP and UDP are at two extremes • RTP provides realtime transport, but not the per-frame policies we want • Currently, multimedia applications handle heterogeneity as follows: TCP • Unsequenced • Unreactive • Application level mechanisms • Sequenced • Stream delivery • Delay unbounded • split a heterogeneous packet flow into component packet flows (e.g. layers) • possibly open a distinct connection for each component packet flow • explicitly provide mechanisms for implementing QoS requirements in the application

  4. HPF: A Transport Protocol for Supporting Heterogeneous Packet Flows • Supports framing. • Frame-specific QoS policies for reliability, priority, deadline, dependencies • Guarantees sequencing, selective reliability. • Provides “goodput control”. • How much to send (estimates the dimensions of the the connection pipe) • What to send (determines how best to fill up the pipe) • Propagates application-specified priorities as hints to network routers. • Helps network routers preferentially drop low-priority packets.

  5. HPF Architecture Read/Write frames or packets Specify priority, reliability, deadline, dependency Application Send/Receive frames API Segmentation / Reassembly Conversion frame policies into packet policies AF sub-layer Frame -> packet Sequencing Reliability and timing Windowing Flow control HPF GC sub-layer Rate, RTT Rate control Estimation of running average of rate Estimation of round trip time RC sub-layer Send/Receive packets Optional: congestion feedback, priority-based packet drop, rate feedback, delay bounded delivery Network Layer

  6. Selective Reliability and Sequencing retransmitted till successfully acknowledged by receiver Reliable (R): Unreliable deadline bound (D): Unreliable best effort (B): treated like reliable packet till deadline violation is predicted, then treated like unreliable best effort packet transmitted at most once

  7. snd_una snd_nxt sender receiver rcv_nxt R only: if (rcv_nxt == s) and (receive s) rcv_nxt = s+ 1 s: sequence number R/B only: if (rcv_nxt >= h+1) and (receive s) rcv_nxt = max{rcv_nxt, s + 1} h: previous reliable sequence number R/B/D: if (rcv_nxt >= h + 1) and (receive s) rcv_nxt = max{rcv_nxt, max{w}} w: lower bound on window advance Selective Reliability and Sequencing One of the more tricky questions is: how do we move the receiver’s window forward? Packet Header

  8. Snd_nxt=18 Pkt2 is predicted to violate delay bound. Is deleted Pkt1 R s=11 h=10 w=12 Pkt2 D s=12 h=11 w=12 Pkt3 B s=13 h=11 w=12 Pkt4 B s=14 h=11 w=12 Pkt5 B s=15 h=11 w=16 Pkt6 R s=16 h=11 w=17 Pkt7 B s=17 h=16 w=18 Cack=12 Cack=12 Cack=16 Pkt1 R s=11 h=10 w=12 Pkt3 B s=13 h=11 w=12 Rcv_nxt=12 Rcv_nxt=12 Rcv_nxt=16 Selective Reliability and Sequencing Snd_una=11 Rcv_nxt <=11 R:reliable packet s:sequence number D:unreliable delay-bounded packet h:previous reliable pkt sequence number B:unreliable best effort packet w:move the receiver window up to at least w, if this pkt is received Cack: cumulative ACK Receiver window: between read_nxt & rcv_nxt

  9. Priority/Deadline/Dependency dropping rinst(t) rlavg(t) rsavg(t) r rapp(t) r rinst(t) rinst(t) t t application rate adaptation transport rate adaptation Goodput control sender network receiver rapp(t)

  10. frame-specific QoS policy a b a a a a b b b a a a a b b b Frame mode : b Stream mode: blank a a b b b Read 1 Read 2 Read 3 Framing Sender Receiver

  11. Some Implementation Issues • Use socket API with some enhancements: • socket() • setsockopt(HPF_ENABLE) • listen(), connect() • sendmsg(policies) • readmsg(), getsockopt(REPORT_LOSS) • getsockopt(rate) • Very easy to program: ported TCP-based network video player by changing under 20 lines of code (at obvious places) • Defaults to TCP if either end host is HPF unaware • Multicast extensions to HPF are ongoing

  12. Evaluation Platforms • NS simulation (source available) • VCR from Oregon Graduate Institute (network video player) • User level implementation (Linux, Solaris, NT) • Linux Kernel (source available) • NT kernel version is ongoing Currently used in DARPA ITO Quorum Reference Implementation as the transport protocol by Teknowledge Corp. and Open Group

  13. Performance • 2MB file transfer, HPF/TCP speedup : 0.99971 • LAN test • High priority packets ratio : 50% - 5% • Time improvement vs TCP : 10% - 42% • Loss : 5% - 24% • WAN test over Internet • High priority packets ratio : 66% - 5%, • Time improvement vs TCP : 32% - 70% • Loss : 0.7% - 7.86% • All pkts are unreliable (UDP like) : Improvement: 75%, loss 7.86% • MPEG-1 with congestion • Priority drop loss percentage: I =0% P=0% B=24% • No Priority drop loss percentage: I=20% P=20% B=8% • Comparisons with RTP ongoing work

  14. Unresolved Issues/Ongoing Work • Optimizing the protocol overhead • Analytical evaluation of the goodput control mechanisms • Quantitative comparison with other recent approaches • Multicast extensions • Non-trivial wide area deployment and tests

  15. General Information • Source available for linux 2.0.(31 - 36) and ns2 • HPF paper in Infocom 1999 (extended version in preparation) • Website: http://timely.crhc.uiuc.edu/HPF • Email contact: bharghav@crhc.uiuc.edu