WebTP—Transport Framework for Web Applications EECS 228A Nov 16, 2000. H. Wilson So.
-
date post
19-Dec-2015 -
Category
Documents
-
view
216 -
download
0
Transcript of WebTP—Transport Framework for Web Applications EECS 228A Nov 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
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.
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
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.
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
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
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
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
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
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)