WebTP—Transport Framework for Web Applications

EECS 228ANov 16, 2000.H. Wilson So

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

Introduction

Motivation & Project Goals

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

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)

Scenario 1: Simple Web Browsing

Download important objects first

Progressive refinement of objects (e.g. progressive JPEGs)

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

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

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

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

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

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)

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.

ADUs, Flows, and PipesApp 1 App 2

Flows Flows

Pipe(to IP A)

Pipe(to IP B)

Transport Protocol Architecture

Pipe-Level Management

Bandwidth Management

Flow-LevelManagement

•ADU fragmentation & reassembly

•Reliability Control

•Flow Control

•Min buffering in WebTP

•Mux/Demux packets

•Bandwidth allocation

•Loss detection/Ack

•Congestion control

•Network measurements

Packet Formats Flow:

ADU number ADU fragment offset, length

Pipe: Packet sequence number Ack number …

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

Challenges at Pipe Levels

Error Control

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!

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

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

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.

Benefits of ACK VectorAssume packet 102, and ack for 103 & 104 are lostUsing cumulative ack …Sender sends: 101, 102, 103, 104, 105Receiver recv: 101, , 103, 104, 105Receiver ACKs: 101, , 101, 101, 101Sender receives: 101, , 101

ACK Vector: (ACK vector size = 4)Receiver recv: 101, , 103, 104, 105Receiver 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.

Challenges at Pipe Levels

Congestion Control

Congestion Control at PipeApplication Application Application

Scheduler

Congestion Control

Reliable FTP

Unreliable Video Unreliable Audio

Reliable FTP

WebTPPipe

Source

Destination

Congestion Control Phases

Tim

eout

Detect S

ufficient Loss(es)

Start

Probing

CongestionAvoidance

PipeTimer

Idle Degrade

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

Challenges of Bandwidth Management

Scheduling

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?

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]

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.

Audio Video Best EffortRate (kbps)0 5020

35

Scheduler Hierarchy

F low 1 F low 2

P 1 (A u d io ) P 2 (V id eo) P 3 (F TP )

P ip e 1

P 1 (A u d io )

F low 1

P 2 (V id eo)

F low 1

P 3 (F TP )

P ip e 2

P 1 (A u d io ) P 2 (V id eo) P 3 (F TP )

P ip e 3

L in k

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

Scheduler HierarchyR

A B

C1 C2 C3 C1 C2 C3

F2F1F2

cw1cw2

cw1cw3cw2

cw3

fw1fw2

fw3

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

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

Challenges

Flow Control & Reliability

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

BSD - TCP Flow Control

Receiver advertises free buffer spacewin = Buf_Alloc – Que_siz

Sender can send [snd_una, snd_una + snd_win –1].snd_win = win; snd_una: oldest unACKed number

1 2 3 4 5 6 7 8 9 10 11 …

sent and ACKed sent not ACKed can send ASAP

snd_win = 6: advertised by receiver

snd_una snd_nxt

can’t send until

window moves

next send number

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.

TCP Example

1 2 3 4 5 6 7 8 9 10 11 …

snd_win = 3

snd_una

1 2 3 4 5 6 7 8 9 10 11 …

• Receiver: ACKs 4, win = 3. (Total buffer size = 6)

• Sender: sends 4 again

3 4 5 6 7 8 9 10 11 12 13 …

snd_win = 6

snd_una

• Sender: after 4 is received at receiver.

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.

WebTP Example

1 2 3 4 5 6 7 8 9 10 11 …

snd_win = 3

snd_una

1 2 3 4 5 6 7 8 9 10 11 …

• Receiver: (positively) ACKs 5, 6, and 7, win = 3. (B_i = 6)

• Sender: can send 4, 8 and 9, subject to congestion control

5 6 7 8 9 10 11 12 13 14 15 …

snd_win = 6

snd_una

• Sender: after 4, 8 and 9 are received at receiver.

rcv_nxt rcv_adv

snd_nxt

snd_nxt

Software Architecture and Implementaion

Application(telnet, Netscape)

Socket Library(part of standard C

library)

Kernel

User

Send(), Recv ()

TCP

IP

Ethernet

Socket

Idea: transparently replace TCP/IPat the user level to avoid changingthe OS kernel

Achieved through circumventingthe system library for the socketinterface.

Emulating Transport Protocol in User Space

Application(telnet, Netscape)

Socket Library(part of standard C

library)

Kernel

User

Send(), Recv ()

TCP

IP

Ethernet

Socket

Imitation Socket Library

TCP sockets WebTP

ToTransport Process

Emulating Transport Protocol in User Space

Inter-Process Communications

App 1

Our Sock Lib

App 2

Our Sock Lib

Transport

UDP

Send(“Hi!”)

Architecture Diagram

WebTP Core Data Structure: Flow Management Module

ProcessCB

FlowCB

ProcessCB ProcessCB ProcessCB

FlowCB

FlowCB

FlowCB FlowCB

FlowCB FlowCB

FlowCB FlowCBFlowCBFlowCB

PipeCBPipeCBHead PipeCB PipeCB

FlowCBHead

(not connected)

(listening)

(pending)

nextpending

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)

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!