1. 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. 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. 3 Current Transport Protocols 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: UDP TCP UnreliableReliable Sequenced Stream delivery Delay unbounded Unsequenced Unreactive Application level mechanisms – 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. 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. 5 HPF Architecture Read/Write frames or packets Specify priority, reliability, deadline, dependency Optional: congestion feedback, priority-based packet drop, rate feedback, delay bounded delivery Network Layer RC sub-layer GC sub-layer AF sub-layer Application Frame -> packet Rate, RTT Send/Receive frames Send/Receive packets HPF API Segmentation / Reassembly Conversion frame policies into packet policies Sequencing Reliability and timing Windowing Flow control Rate control Estimation of running average of rate Estimation of round trip time

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

7. 7 Selective Reliability and Sequencing One of the more tricky questions is: how do we move the receiver’s window forward? snd_unasnd_nxt rcv_nxt sender receiver Packet Header 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

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

9. 9 Goodput control senderreceiver r app (t)r inst (t) r savg (t)r lavg (t) transport rate adaptation r inst (t) r t application rate adaptation r inst (t) r t r app (t) Priority/Deadline/Dependency dropping network

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

11. 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. 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. 13Performance 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 droploss percentage: I =0%P=0% B=24% –No Priority drop loss percentage: I=20%P=20%B=8% Comparisons with RTP ongoing work

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