WebTP A New Transport Architecture for the Web

1
WebTPA New Transport Architecture for the Web

• Rajarshi Gupta
• Wilson So
• UCB EECS

2
Team Members

• FACULTY
• Venkat Anantharam
• Steven McCanne
• David Tse
• Pravin Varaiya
• Jean Walrand

• STUDENTS
• Ye Xia
• Wilson So
• Rajarshi Gupta
• Yogesh Bhumralkar
• Jeng Lung
• Richard La Post Doc
• David Starobinski

3
Motivation

• World Wide Web today is vast and vital
• Mostly runs Web transport (http) over TCP
• TCP and UDP sub-optimal for many applications
• Attempts at incremental improvements
• Need a comprehensive solution, without trying to
  fit in with TCP/HTTP
• Web Applications important enough to motivate new
  cross-layer architecture
• WebTP is the answer ?

4
WebTP Project Work Items

• User utility characterization
• WebTP architecture and protocol (motivation
  design)
• Active research areas

5
WebTP Project Work Items

• User utility characterization
• WebTP architecture and protocol (motivation
  design)
• Active research areas

6
Conceptual View
interaction
Server
Network
Display
Client
Satisfaction
Document
Resources
User Rules
Utility Function
7
S f (D , C , N , U)

• S User Satisfaction
• D Document Descriptor
• C Client Set of Rules
• N Observed Network State
• U Utility Function

Client Rules C
Network State
User Preferences
Document D
Document D
Satisfaction
8
Utility Function U

• Measure of utility generated by the objects on
  the page
• Simple additive form, or more complicated
• Utility depends on Arrival, Browse Time
• Experimental work to characterize utility

9
WebTP Transfer

• Given
• a set of objects to transfer
• current network state
• We find an Optimal Transfer Schedule
• Optimal order of transfer
• Optimal subset of objects (dynamic programming)
• Universal delay constraint
• Browse time constraint
• Optimal ?
• Maximizes user utility

10
Experimental Setup

• Sample page (CNN Digest)
• www.path.berkeley.edu/guptar/SAMPLE/index.html
• Quantitative metric for comparison of utilities
• Comparison of transfers in terms of utilities

WebTP
Normal
WebTP vs Normal Web Transfer (example)
11
WebTP Project Work Items

• User utility characterization
• WebTP Architecture Protocol (motivation
  design)
• Active research areas of WebTP

12
WebTP Design Philosophy
USER

• Consider the web browsing process as a whole.
• Bring the user into the loop of decision.

APP
PROTOCOL
NETWORK
13
Todays Focus Transport
USER

• Requirements of the transport protocol
• Overview of WebTP transport architecture

APP
PROTOCOL (TRANSPORT)
NETWORK
14
Assumptions

• For Todays discussions, we assume
• Network provides best-effort service only
• Optimize at end-hosts, not within the network
• Design a new transport, but leave the network
  layer (IP) intact

15
Transport Requirements

• Scenario 1 browsing a static web page composed
  of text, graphics, and pictures.
• What are the requirements of the transport layer
  imposed by this application?

16
Transport Requirements

• Application specify the download order of
  different objects
• Allow progressive delivery of objects (e.g.
  progressive JPEGs)
• Send data in small chunks (a paragraph or 1 scan
  of an img)

3
2
1
17
Transport Requirements

• Scenario 2User browses through supplementary
  information while watching a video stream

18
Transport Requirements

• Allow user/application to decide how to allocate
  the available bandwidth to different connections
• Notify application of the currently available
  bandwidth

28.8 Kbps
leftover
19
Transport Requirements Summary

• Data should be transferred in small chunks that
  can be processed displayed independently
  (Application Data Units)
• App specifies transfer order of ADUs within a
  connection and bandwidth allocation among
  different connections
• Transport informs each app of how much bandwidth
  it gets each app decides how to best use it

20
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

21
Preliminary Design
App 1
App 2
Connections
Connections
Pipe(to IP A)
Pipe(to IP B)
22
Preliminary Design

• ADUs each object is composed of ADUs
• Connections light-weight objects corresponding
  to an application-level conversation. Should be
  able to open one connection per object transfer.
• Pipes one pipe per destination multiple
  connections to the same destination (IP) are
  muxed onto a single pipe.

23
Why Separate Connections and Pipes?

• Connections
• low overhead app can open as many connections as
  it wants
• allow fine-grained reliability control on a per
  ADU basis
• allow app-controlled bandwidth allocation

• Pipes
• Integrated Congestion Management Architecture
  proposed by Hari Balakrishnan et al.
• allow connections to cooperate to find out the
  available bandwidth

24
WebTP Architecture

• ADU fragmentation reassembly
• Reliability Control
• Flow Control
• Min buffering in WebTP

ConnectionManagement

• Mux/Demux packets
• Bandwidth allocation

Bandwidth Management

• Loss detection/Ack
• Congestion control
• Network monitoring

Congestion Management
25
WebTP Protocol Example
26
WebTP Packet Header

• 0 1 2
  3
• 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
  5 6 7 8 9 0 1
• -------------------------
  -------
• Packet number
  
• -------------------------
  -------
• Acknowledgment number
  
• -------------------------
  -------
• Acknowledged Amount
  
• -------------------------
  -------
• ADU number
  
• -------------------------
  -------
• Segment Number
  
• -------------------------
  -------

27
WebTP Transport Header

• Source Port
  UARSFREF
• 
  RCSYIENA
• 
  GKTNNLDS
• -------------------------
  -------
• Destination Port
  C
• 
  L RES
• 
  A
• -------------------------
  -------
• Data
  
• Offset RES Window
  
• 
  
• -------------------------
  -------
• Checksum Options
  
• -------------------------
  -------
• Options
  Padding
• -------------------------
  -------
• data
  
• -------------------------
  -------

28
WebTP Project Work Items

• User utility characterization
• WebTP architecture and protocol (motivation
  design)
• Active research areas

29
ACK Scheme

• Some ADUs are reliable some are not
• Lost packets of reliable ADUs should be
  retransmitted automatically

• But all pkts are muxed onto the same pipe

• Problem Cumulative ACKs doesnt work!

30
Ack Scheme
1
2
3
4
5
6

• TCP style cum-ack doesnt 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 doesnt know if 3,4 are unreliable, so
  it can only ack 2 upon receiving 5 and 6 using
  Cum-Ack

31
Ack Scheme

• Solution 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

1
2
3
4
5
6

• E.g. ack sequence (1,1) , (1,2), (5,5), (5,6)
• Disadv 2 logically separate ack stream gt cant
  easily infer loss from another ack stream
• Solution 2 Use a bit vector to selective ack
  both reliable and unreliable packets
• Disadv high speed long haul links gt long vector
  (large window)

32
Fast WebTP
SYN
RTT Pipe setup delay
SYN-ACK
ACK
Data

• For interactive traffic, pipe setup delay can be
  annoying. Can we get rid of the 3-way handshake
  for setting up a pipe?
• Yes, BUT we might get duplicate data from
  previous incarnation of a pipe.

33
Fast WebTP

• If application can detect duplicate ADUs, or if
  duplicate ADUs doesnt do any harm, 3-way
  handshake is redundant!
• E.g. Duplicate HTTP requests for static objects
  doesnt adversely affect the client or the
  server.
• Problem how to seamlessly integrate the regular
  WebTP(w/ handshake) and Fast WebTP(w/o handshake)
  protocol?

34
Fast WebTP Example
Client
Server(accepts Fast WebTP)
1. Client sends FAST ADU
SYNdata
2(a). Data delivered to app continues handshake
SYN-ACK
3. Sends ACK
2(b). App chooses to accept data
ACK
4. Handshake finishes
Data-ACK
5. Acks data
Data
6. Sends more new data
35
Fast WebTP Example
Client
Server(rejects Fast WebTP)
1. Client sends FAST ADU
SYNdata
2(a). Data delivered to app continues handshake
SYN-ACK
3. Sends ACK
2(b). App chooses to REJECT data
ACK
4. Handshake finishes
5. Dont ACK data (or explicitly reject)
Data
6. Ack timeoutResend 1st ADU
36
Traffic Classification

• Web-related traffic can be roughly classified as
  one of the following categories
• Interactive bursty traffic, delay sensitive
• Bulk high volume traffic, delay insensitive,
  reliable
• Realtime streams multimedia streams, extremely
  sensitive to delay and jitter, tolerate loss
• Buffered streams multimedia streams playback,
  less delay sensitive, tolerate loss

37
Bandwidth Allocation

• Long-term bandwidth allocation is dependent on
  users specification of rates.
• APIs are available for querying available rate,
  current rate, and for setting preferred rate.
• Short-term bandwidth assignment is dependent on
  traffic classes.

38
Bandwidth Allocation and Window Size
Connections
Pipe

• TCP-style congestion control gives us a time
  varying congestion window size per pipe
• How do we allocate this window among different
  connections of different classes?

39
Flexible Software Arch.
How to build a flexible software framework so we
can easily experiment with different kinds of
control algorithms in our transport protocol?
ConnectionManagement
Bandwidth Management
Congestion Management
40
Conclusion

• Most important idea allow user preferences to
  determine how to best use the available bandwidth
• Look at the web browsing process as a whole,
  design a transport protocol that caters to the
  needs of the user/application
• Leads to the design of connections muxed on top
  of pipes

41
Conclusion

• Although muxing isnt entirely novel, the
  explicit separation of congestion and reliability
  control is.
• Decision to allow flexible reliability control on
  a per ADU basis and the addition of Fast WebTP
  introduce many new challenging research problems
• The need to experiment w/ different algs requires
  a flexible software framework