1 / 15

Supporting Heterogeneous Packet Flows in the Internet

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. Heterogeneous Packet Flows.

doria
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. 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. 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

More Related