1 The Role of “Awareness” in Internet Protocol Performance Carey Williamson Professor/iCORE Senior Research Fellow Department of Computer Science University of Calgary

2 Introduction r It is an exciting time to be an Internet researcher (or even a user!) r The last 10 years of Internet development have brought many advances: m World Wide Web (WWW) m Media streaming applications m “Wi-Fi” wireless LANs m Mobile computing m E-Commerce, mobile commerce m Pervasive/ubiquitous computing

3

4 The Wireless Web r The emergence and convergence of these technologies enable the “wireless Web” m the wireless classroom (CRAN) m the wireless workplace m the wireless home r My iCORE mandate: design, build, test, and evaluate wireless Web infrastructures r Holy grail: “anything, anytime, anywhere” access to information (when we want it, of course!)

5 Some Challenges r Portable computing devices: no problem (cell phones, PDAs, notebooks, laptops…) r Wireless access: not much of a problem (WiFi, b, BlueTooth, Pringles…) r Security: still an issue, but being addressed r Services: the next big growth area??? r Performance transparency: providing an end-user experience that is hopefully no worse than that in traditional wired Internet desktop environments (my focus!)

6 Research Theme r Existing layered Internet protocol stack does not lend itself well to providing optimal performance for diversity of service demands and environments r Who should bend: users or protocols? r Explore the role of “awareness” in Internet protocol performance r Identify tradeoffs, evaluate performance

7 Talk Overview r Introduction r Background m Internet Protocol Stack m TCP 101 r Motivating Examples r Our Work on CATNIP r Concluding Remarks

8 Internet Protocol Stack r Application: supporting network applications and end-user services m FTP, SMTP, HTTP, DNS, NTP r Transport: end to end data transfer m TCP, UDP r Network: routing of datagrams from source to destination m IPv4, IPv6, BGP, RIP, routing protocols r Data Link: hop by hop frames, channel access, flow/error control m PPP, Ethernet, IEEE b r Physical: raw transmission of bits Application Transport Network Data Link Physical

9 Viewpoint r “Layered design is good; layered implementation is bad” -Anon. r Good: m unifying framework for describing protocols m modularity, black-boxes, “plug and play” functionality, well-defined interfaces (good SE) r Bad: m increases overhead (interface boundaries) m compromises performance (ignorance)

10 Tutorial: TCP 101 r The Transmission Control Protocol (TCP) is the protocol that gets your data reliably r Used for , Web, ftp, telnet, … r Makes sure that data is received correctly: right data, right order, exactly once r Detects and recovers from any problems that occur at the IP network layer r Mechanisms for reliable data transfer: sequence numbers, acknowledgements, timers, retransmissions, flow control...

11 TCP 101 (Cont’d) r TCP is a connection-oriented protocol SYN SYN/ACK ACK GET URL YOUR DATA HERE FIN FIN/ACK ACK

12 TCP 101 (Cont’d) r TCP slow-start and congestion avoidance ACK

13 TCP 101 (Cont’d) r TCP slow-start and congestion avoidance ACK

14 TCP 101 (Cont’d) r TCP slow-start and congestion avoidance ACK

15 TCP 101 (Cont’d) r This (exponential growth) “slow start” process continues until either of the following happens: m packet loss: after a brief recovery phase, you enter a (linear growth) “congestion avoidance” phase based on slow-start threshold found m all done: terminate connection and go home

16 Simple Observation r Consider a big file transfer download: m brief startup period to estimate network bandwidth; most time spent sending data at the “right rate”; small added penalty for lost packet(s) r Consider a typical Web document transfer: m median size about 6 KB, mean about 10 KB m most time is spent in startup period; as soon as you find out the network capacity, you’re done! m if you lose a packet or two, it hurts a lot!!!

17 The Problem (Restated) r TCP doesn’t realize this dichotomy between optimizing throughput (the classic file transfer model) versus optimizing transfer time (the Web document download model) r Wouldn’t it be nice if it did? (i.e., how much data it was sending, and over what type of network) r Some research starting to explore this...

18 Motivating Example #1 r Wireless TCP Performance Problems Wired Internet Wireless Access High capacity, low error rate Low capacity, high error rate

19 Motivating Example #1 r Solution: “wireless-aware TCP” (I-TCP, ProxyTCP, Snoop-TCP,...)

20 Motivating Example #2 r Multi-hop “ad hoc” networking Carey Haruna

21 Motivating Example #2 r Multi-hop “ad hoc” networking Carey Haruna

22 Motivating Example #2 r Multi-hop “ad hoc” networking Carey Haruna

23 Motivating Example #2 r Multi-hop “ad hoc” networking Carey Haruna

24 Motivating Example #2 r Multi-hop “ad hoc” networking Carey Haruna

25 Motivating Example #2 r Multi-hop “ad hoc” networking Carey Haruna

26 Motivating Example #2 r Multi-hop “ad hoc” networking Carey Haruna

27 Motivating Example #2 r Multi-hop “ad hoc” networking Carey Haruna

28 Motivating Example #2 r Multi-hop “ad hoc” networking Carey Haruna

29 Motivating Example #2 r Multi-hop “ad hoc” networking Carey Haruna

30 Motivating Example #2 r Two interesting subproblems: m Dynamic ad hoc routing: node movement can disrupt the IP routing path at any time, disrupting TCP connection; yet another way to lose packets!!!; possible solution: Explicit Loss Notification (ELN) m TCP flow control: the bursty nature of TCP packet transmissions can create contention for the shared wireless channel among forwarding nodes; possible solution: rate-based flow control

31 Our Work r Context-Aware Transport/Network Internet Protocol (CATNIP) r Motivation: “Like kittens, TCP connections are born with their eyes shut” - CLW r Research Question: How much better could TCP perform if it knew what it was trying to accomplish (e.g., Web document transfer)?

32 Some Key Observations (I think) r Not all packet losses are created equal r TCP sources have relatively little control r IP routers have all the power!!!

33 Tutorial: TCP 201 r There is a beautiful way to plot and visualize the dynamics of TCP behaviour r Called a “TCP Sequence Number Plot” r Plot packet events (data and acks) as points in 2-D space, with time on the horizontal axis, and sequence number on the vertical axis

34 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X X

35 TCP 201 (Cont’d) r What happens when a packet loss occurs? r Quiz Time... m Consider a 14-packet Web document m For simplicity, consider only a single packet loss

36 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X X

37 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X ?

38 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X X +

39 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X X

40 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X ?

41 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X X

42 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X X

43 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X ?

44 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X X +

45 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X X X X

46 Time SeqNum X + Key: X Data Packet + Ack Packet X + ?

47 Time SeqNum X + Key: X Data Packet + Ack Packet X X X X X X X X X X + + +

48 Time SeqNum Key: X Data Packet + Ack Packet ?

49 Time SeqNum + Key: X Data Packet + Ack Packet X X + + X X X X X

50 TCP 201 (Cont’d) r Main observation: m “Not all packet losses are created equal” r Losses early in the transfer have a huge adverse impact on the transfer latency r Losses near the end of the transfer always cost at least a retransmit timeout r Losses in the middle may or may not hurt, depending on congestion window size at the time of the loss

51 The TCP Transfer “Pain Profile” SeqNum of the Single Lost Packet 1 N Relative Transfer Time

52 Design of CATNIP Can we make the TCP/IP protocols “smarter” about the specific job they are trying to do?  Yes. Convey application-layer context information to the TCP and IP layers Network Transport Application Document Size Packet Priority

53 Design of CATNIP (Cont’d) Q: What could a TCP source do differently? A: If it knew how much data it had to send, and how far along it was already, then maybe…  Rate-Based Pacing of the Last Window (RBPLW)  Early Congestion Avoidance (ECA)  Selective Packet Marking (SPM): Use the reserved high-order bit in the TCP header to convey packet priority information (high priority for the really crucial packets)

54

55 Design of CATNIP (Cont’d) Q: What could an IP router do differently? A: If it knew which packets were the “painful” ones to lose, then the router could…  CATNIP-Good: give them preferential treatment, and avoid throwing them away (if possible) when congested  CATNIP-Bad: throw them away

56 Evaluation of CATNIP Evaluation Simulation: ns-2 Emulation: use WAN emulation to test a prototype implementation of CATNIP in the Linux kernel of an Apache Web server.

57 Simulation Evaluation Network model: Client 100 Server 1 Server 2 Server 10 Client 1 Client 2 Client Mbps, 5 ms 10 Mbps, 5 ms RouterSRouterC

58 Simulation Evaluation (Cont’d) Web workload model:  100 clients, 10 different Web pages  Use empirically-observed distribution to determine the size, and the number of embedded images

59 Simulation Evaluation (Cont’d) Factors and Levels: Performance metrics:  transfer time for each Web page  packet loss ratio

60 Simulation Results for DropTail Routers Reno/ RBPLW Reno ECA ECA/RBPLW Mean and Standard Deviation of Transfer Times

61 Simulation Results for CATNIP-Good Routers Mean and Standard Deviation of Transfer Times Reno/DropTail SPM/Good

62 Simulation Results for CATNIP-Bad Routers Mean and Standard Deviation of Transfer Times Reno/DropTail SPM/Bad

63 Observations r Sources have relatively little control r IP routers have all the power r Adding context-awareness at the IP routers improves both mean and standard deviation of Web page transfer times r SPM and CATNIP-Good provide most of the benefit

64 Network Emulation Experiments Experimental environment:  WAN emulator: IP-TNE (Internet Protocol Traffic and Network Emulator) at the U of C  Web server: Apache Web server (version ) on modified Linux kernel.  Implementation focused on SPM feature only (partially implemented at this time)  Preliminary results available

65 Client 100 Primary Factor: buffer size of the bottleneck link (64 KB KB) 10 Mbps, 5 ms Endpoint Client 1 Client 2 Client Mbps, 5 ms 10 Mbps, 5 ms Network Model Server WAN Emulation RouterSRouterC

66

67 Summary r There seem to be performance advantages to bending the rules regarding the Internet protocol stack layered model r The general notion of “awareness” needs to explored in a variety of contexts m wireless networks, ad hoc routing, TCP/IP, Web caching, mobile computing, adaptive applications, … r Many exciting issues to explore!!

68 The Next Steps r Putting it all together: Web + Wireless r Wireless Internet Performance Lab (UofC) r Experimental Laboratory for Internet Systems and Applications (UofS/UofC,CFI) r Research Collaborations: m UofC, UofS, UofA, TRLabs, CS/ECE m Nortel? HP? Cisco? Agilent? Compaq? Telus?

69 Credits: Research Team r Martin Arlitt: Web performance, workload characterization r Qian Wu: TCP, ns-2 simulation r Guangwei Bai: network traffic measurement and modeling r Tianbo Kuang: wireless networks, video compression, streaming r Nayden Markatchev: tech support r Grad Students: Mingwei Gong, Yujian Li, Kehinde Oladosu, Fang Xiao, and ??? Application Transport Network Data Link Physical

70 The End: Question Time! r For more information: m m URL: