WebTP—Transport Framework for Web Applications

1. WebTP—Transport Framework for Web Applications EECS 228ANov 16, 2000.H. Wilson So

2. FACULTY Venkat Anantharam David Tse Pravin Varaiya Jean Walrand STUDENTS Yogesh Bhumralkar Rajarshi Gupta Jeng Lung H. Wilson So Jing Tien Daniel Yoo Ye Xia Current Members

3. Introduction Motivation & Project Goals

4. Motivation • Web browsing is an interactive activity • But limited bandwidth causes World Wide Wait • Broadband Internet access alleviates the problem – but wireless web and shared cable modems resurrects the same problems • Millions are still using modems!!

5. Question • Given a limited amount of bandwidth, • How do we use it intelligently to give the best user-perceived performance? • Observation: Some bits are more important than others (to a user)

6. Download important objects first Progressive refinement of objects (e.g. progressive JPEGs) Scenario 1: Simple Web Browsing

7. Scenario 2: Real-time Multimedia • Application decides how to allocate the available bandwidth to different connections • Audio is more important than video and text) 28.8 Kbps leftover

8. Problem 1: TCP is not optimized for web • TCP treats data as a stream of bytes • Framing is done by TCP, so out of order packets cannot be delivered to applications • Not all flows needs to be reliable • Single packet loss causes out-of-order packets to wait • Slow start is too slow for short pages

9. Problem 2: No bandwidth control over multiple flows • Different TCP flows probe bandwidth independently and compete with each other rather than trying to cooperate • The allocation of bandwidth is not up to the application. • TCP congestion control is not very smooth

10. Problem 3: UDP is not enough • UDP does not have congestion control, flow control, or delivery notifications • Asking application programmers to do them is asking too much • A flexible transport framework with an integrated scheduler and congestion congestion control is desirable

11. Transport Requirementsfrom RUTS BOF ’98 • Quoted from Requirements of Unicast Transport Sessions (RUTS) BOF from Orlando IETF, Dec 1998: • Quick connection establishments • Application Level Framing • Congestion control • App control over reliability • TCP Slow-start/slow restart hit for interactive traffic

12. Transport Requirements Summary • Transport gives real-time statistics of the network conditions (delay, bandwidth, and loss rate) • Applications decides how to use available bandwidth (what to send, and when to send)

13. Essential Concepts • ADUs: each object is composed of ADUs (a video frame, a scan of a JPEG, etc.) • Flows: light-weight connections corresponding to an application-level conversation. Light-weight enough to support 1 flow per object transfer. • Pipes: one pipe per destination; multiple connections to the same destination (IP) are muxed onto a single pipe. Assume flows within a pipe see the same network conditions.

14. ADUs, Flows, and Pipes App 1 App 2 Flows Flows Pipe(to IP A) Pipe(to IP B)

15. Transport Protocol Architecture • ADU fragmentation & reassembly • Reliability Control • Flow Control • Min buffering in WebTP Flow-LevelManagement • Mux/Demux packets • Bandwidth allocation Bandwidth Management • Loss detection/Ack • Congestion control • Network measurements Pipe-Level Management

16. Packet Formats • Flow: • ADU number • ADU fragment offset, length • Pipe: • Packet sequence number • Ack number • …

17. Design Philosophy • Each flow can be reliable or unreliable • Lost packets of ADUs from reliable flows are retransmitted • Packet losses from unreliable flows are signaled to applications • Congesion Control probes available bandwidth

18. Challenges at Pipe Levels Error Control

19. ACK Scheme • Reliable and unreliable flows • Lost packets of reliable ADUs should be retransmitted • But all pkts are muxed onto the same pipe • Problem: Cumulative ACKs doesn’t work!

20. Ack Scheme • TCP style cum-ack doesn’t work for reliable/unreliable mix!! • Assume 1,2 belongs to reliable ADU X; 3,4 belongs to unreliable ADU Y; 5,6 belongs to reliable ADU Z • Packet 3 & 4 are lost • Receiver doesn’t know if 3,4 are unreliable, so it can only ack 2 upon receiving 5 and 6 using Cum-Ack • But 3 & 4 are never retransmitted !! 1 2 3 4 5 6

21. Ack Scheme #1 • Use separate sequence number spaces for reliable and unreliable packets. • Use cumulative acks for reliable packets • Use selective acks to ack the last consecutive run of unreliable pkts received R1 U1 U2 R2 R3 • E.g. ack sequence (R1,--), --- ,(R1,U2), (R2,U2), (R3,U2) • Disadv: 2 logically separate ack streams => increased complexity, higher packet header overhead

22. Ack Scheme #2 • Unified ack for reliable and unreliable flows: each ack packet consists of: • Ack #: the highest sequence number received for this pipe • Ack vector: 32-bit vector in which a 1 in the j-th position indicates packet (ACK # - 1 - j) has been received; a 0 indicates a loss.

23. Benefits of ACK Vector Assume packet 102, and ack for 103 & 104 are lost Using cumulative ack … Sender sends: 101, 102, 103, 104, 105 Receiver recv: 101, , 103, 104, 105 Receiver ACKs: 101, , 101, 101, 101 Sender receives: 101, , 101 ACK Vector: (ACK vector size = 4) Receiver recv: 101, , 103, 104, 105 Receiver ACKs: 101, , 103, 104, 105 [ack vector omitted] Sender receives: 101 (0000), , 105 (1011) Result: After receiving ACK 105, it will resend packet 101 if the flow is reliable.

24. Challenges at Pipe Levels Congestion Control

25. Congestion Control at Pipe Source Application Application Application Destination Unreliable Video Unreliable Audio Reliable FTP Reliable FTP Scheduler WebTP Pipe Congestion Control

26. Congestion Control Phases Start Probing Idle Degrade Timeout Detect Sufficient Loss(es) Congestion Avoidance Pipe Timer

27. Congestion Control Challanges • TCP Friendliness • What about integrated flows? • Insensistive to out of order packets • TCP’s 3 dup-ack loss detection problematic • Improve slow start performance, while not causing congestion collapse • Remember history, avoid slow start for small transfers

28. Challenges of Bandwidth Management Scheduling

29. Transport & Scheduler • Traditionally, scheduler is not part of the transport layer • Integrated congestion control makes scheduling necessary • Challenge: What scheduling discipline should we use when the available bandwidth is variable and unknown?

30. Role of Scheduler • Pipe abstraction: IP to IP • Each pipe has certain amount of congestion credits available at any time (pipe’s congestion window) • Scheduler decides how to distribute the available credits within the pipe • [Assume pipes do not share bottlenecks; sharing between pipes has to be dealt with using congestion control]

31. Audio Video Best Effort 0 20 35 50 Rate (kbps) Example: • 3 traffic classes: audio, video and best effort in order from highest to lowest priority. • Audio/video flows ask for specific rate of transfer • provide this rate to them over a given time interval • make sure the priorities hold so that you satisfy bandwidth requirement in order of priorities based on available rates.

32. Scheduler Hierarchy

33. Priority, Round Robin, Rate-Limited • Among classes: Send by priority • Within a class: WRR for the different flows (weight = rates) • Rate limit over the time interval that you’re providing these guarantees - unless other classes are idle • Administrator can limit rates requested by user

34. Scheduler Hierarchy R A B cw3 cw1 cw3 cw1 cw2 cw2 C1 C2 C3 C1 C2 C3 fw1 fw3 fw2 F1 F2 F2

35. Priority Algorithm: • Pipe level: • start at beginning and round robin through pipes • send from pipe as long as there are congestion credits and pipe credits available • No explicit pipe-level weights for sharing; at this level, rely on congestion credits to do sharing between pipes • Class level: • go through classes in order of priority • send from class as long as the class has credits available to transmit

36. Priority Algorithm: • Flow level: • make sure you have enough congestion credits available to send from here each time you try to send; if not then go to next pipe • weighted round robin among all flows in pipe • each time you visit a class, start serving at the flow after the one you left off at last time

37. Challenges Flow Control & Reliability

38. TCP Receiver Flow Control • Multiple TCP connections share the same physical buffer: need buffer management so that • One connection does not hog all buffers, effectively shutting down other connections. • Deadlock may be prevented. • Packet re-assembly

39. BSD - TCP Flow Control • Receiver advertises free buffer space win = Buf_Alloc – Que_siz • Sender can send [snd_una, snd_una + snd_win –1]. snd_win = win; snd_una: oldest unACKed number snd_win = 6: advertised by receiver 1 2 3 4 5 6 7 8 9 10 11 … can’t send until sent not ACKed sent and ACKed can send ASAP window moves snd_una snd_nxt next send number

40. TCP Receiver Buffer Management • Time-varying physical buffer size B_r(t), shared by n TCP connections. • BSD implementation: receiver of connection i can buffer no more than B_i amount of data at any time. Source i tries not to overflow a buffer of size B_i. • If TCP-styled control is used, it is hard to guarantee not exceeding the buffer size B_i. • Buffers are not reserved. It is possible  B_i > B_r(t), for some time t.

41. TCP Example • Receiver: ACKs 4, win = 3. (Total buffer size = 6) 1 2 3 4 5 6 7 8 9 10 11 … • Sender: sends 4 again snd_win = 3 1 2 3 4 5 6 7 8 9 10 11 … snd_una • Sender: after 4 is received at receiver. snd_win = 6 3 4 5 6 7 8 9 10 11 12 13 … snd_una

42. WebTP: Buffer Management • Each flow gets a fixed upper bound on queue size, say B_i.  B_i >= B_r is possible. • Later on, B_i will adapt to speed of application. • Receiver of a flow maintains rcv_nxt and rcv_adv. B_i = rcv_adv - rcv_nxt + 1 • Packets outside [rcv_nxt, rcv_adv] are rejected.

43. WebTP Example • Receiver: (positively) ACKs 5, 6, and 7, win = 3. (B_i = 6) 1 2 3 4 5 6 7 8 9 10 11 … rcv_nxt rcv_adv • Sender: can send 4, 8 and 9, subject to congestion control snd_win = 3 1 2 3 4 5 6 7 8 9 10 11 … snd_nxt snd_una • Sender: after 4, 8 and 9 are received at receiver. snd_win = 6 5 6 7 8 9 10 11 12 13 14 15 … snd_una snd_nxt

44. Software Architecture and Implementaion

45. Emulating Transport Protocol in User Space Application(telnet, Netscape) Send(), Recv () Socket Library(part of standard C library) User Idea: transparently replace TCP/IPat the user level to avoid changingthe OS kernel Achieved through circumventingthe system library for the socketinterface. Kernel Socket TCP IP Ethernet

46. Emulating Transport Protocol in User Space Application(telnet, Netscape) Send(), Recv () Imitation Socket Library TCP sockets WebTP Socket Library(part of standard C library) ToTransport Process User Kernel Socket TCP IP Ethernet

47. Inter-Process Communications App 2 App 1 Our Sock Lib Our Sock Lib Send(“Hi!”) Transport UDP

48. Architecture Diagram

49. WebTP Core Data Structure: Flow Management Module ProcessCB ProcessCB ProcessCB ProcessCB FlowCBHead FlowCB FlowCB FlowCB FlowCB (not connected) FlowCB FlowCB FlowCB (pending) next pending FlowCB FlowCB FlowCB FlowCB (listening) PipeCBHead PipeCB PipeCB PipeCB

50. Conclusion • The web works (most of the time) but performance is unpredictable • TCP is really designed for FTP, not WWW or video streaming • WebTP is really about giving application complete control over how bandwidth is used • Congestion Control probes available bandwidth • Scheduler helps application allocate bandwidth • Network stats help applications adapt • Application decides how to use the limited bandwidth (what to send and when to send)