WebTP

1
WebTPTransport Framework for Web Applications

• EECS 228ANov 16, 2000.H. Wilson So

2
Current Members

• 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

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
Scenario 1 Simple Web Browsing

• Download important objects first
• Progressive refinement of objects (e.g.
  progressive JPEGs)

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 doesnt work!

20
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
• But 3 4 are never retransmitted !!

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 gt
  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
Timeout
Idle Degrade
Detect Sufficient Loss(es)
Congestion Avoidance
Pipe Timer
27
Congestion Control Challanges

• TCP Friendliness
• What about integrated flows?
• Insensistive to out of order packets
• TCPs 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 (pipes 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
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 youre
  providing these guarantees - unless other classes
  are idle
• Administrator can limit rates requested by user

34
Scheduler Hierarchy
R
A
B
cw3
cw1
cw1
cw3
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
cant 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 gt
  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 gt 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)
PipeCB
PipeCBHead
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)

51
Conclusion and Future Work

• Decoupling Congestion Control from Reliability is
  the source of numerous new challenges
• Event though TCP dominates the world today, more
  research in transport protocol is needed to
  accommodate new applications and hi-speed
  networks!