Transcript Chapter 4 Lecture Presentation

Applications and Cheetah
Malathi Veeraraghavan
University of Virginia
[email protected]

Outline


eScience vs. commercial networks
Three modes of bandwidth sharing




large-m
small-m, long-held calls
small-m, short-duration calls
Applications
MCNC meeting, April 10, 2006
1
Circuit/Virtual-Circuit technologies
eScience networks Commercial networks
Raison
d'etre
High-throughput
connectivity
between a few
facilities
Moderate-throughput
connectivity between
millions of users
Key
goal
QoS guarantees
Bandwidth sharing
(different style from
TCP based sharing)
Call
Long-held
duration
Short-duration
Reach
Partial (HOV lanes)
End-to-end
2
Goal of eScience networks




On previous slide, we said "QoS
guarantees"
But usage of the term "networks" implies
bandwidth sharing
If bandwidth is not shared, we have a
"link"
Leased line service
3
What's the difference?

leased line service


service provider is given enough lead time to
add interface modules to meet request
eScience networks being designed today


above is not true
requests are handled by an automated
scheduler and granted or denied within a short
lead time


this is bandwidth sharing
this is "book-ahead" or "advance reservations"
4
GMPLS control plane


How useful is it to these two types of
networks?
Purpose of GMPLS control plane



Bandwidth (BW) sharing (dynamic& distributed)
Provisioning (threading the circuits/VCs)
BW sharing mode


Immediate request (can't specify a future callinitiation time or call holding time in protocols)
Call accepted or rejected: "call blocking"
5
Understanding call blocking mode of
BW sharing

Input parameters

Link capacity: e.g. 10Gbps




Traffic load


Express this as m channels
If per-call BW is 1Gb/s, m = 10
m is comparable to the number of bank tellers
measure of call arrival rate (calls/sec) and mean
call holding time (seconds/call)
Measure of success of BW sharing mode


Call blocking probability (% of calls blocked)
Link utilization
6
Strong dependence on m: if m=10, to run link at an 80%
utilization level, call blocking probability will be a high 23.62%
Call blocking probability vs. m
Utilization
m is a measure of high-throughput vs. moderate-throughput
difference between eScience and commercial networks
7
For high-throughput, m is small
Dependence on call duration?
(eScience: long-held; commercial: short-duration)





Consider traffic load
Typically, if mean call duration (holding
time) is high, call arrival rate is low
Traffic load is a product of these two
parameters
For a given call blocking probability, link
utilization and m, the required traffic load
is a fixed value
Dependence on call duration unclear
8
But BW sharing does depend on
mean call holding time if m is small
Large m
Moderate throughput
Small m
High throughput
immediate-request
with call blocking
Short calls
call queueing


Bank teller
Long calls
Doctor's office
book-ahead
Mean waiting time is proportional to mean call holding time
Can afford to have a queueing based solution if calls are short
9
eScience: small-m, long-held


Does a book-ahead BW sharing mechanism help
with the high call blocking probability problem?
We analyzed and simulated two types of BookAhead (BA) mechanisms



BA-n: caller specifies n call-start time options
BA-all: caller is willing to accept any open time slot
Parameters:


K: reservation time horizon (in timeslots): 2000
Two call classes:


class-1 holding time: 100 (h1); 10% of calls (r1)
class-2 holding time: 300 (h2); 90% of calls (r2)
10
Call blocking probability
0.35
0.3
BA-1
Call blocking probability P
B
Erlang-B
0.25
IR
0.2
BA-3
0.15
BA-5
0.1
BA-10
0.05
BA-all
0
0.01
0.015
0.02
0.025
0.03
0.035
Call Arrival Rate 
0.04
0.045
0.05
(m=10, K=2000, l=2, h1=100, h2=300, r1=0.1, r2=0.9)
11
Xiangfei Zhu, [email protected]
Utilization
1
BA-all
BA-10
BA-5
0.9
0.8
Utilization U
0.7
BA-3
IR & Erlang-B
0.6
BA-1
0.5
0.4
0.3
0.2
0.01
0.015
0.02
0.025
0.03
0.035
Call Arrival Rate 
0.04
0.045
0.05
(m=10, K=2000, l=2, h1=100, h2=300, r1=0.1, r2=0.9)
12
Xiangfei Zhu, [email protected]
Observations

BA-n/BA-all performs better than IR


eg., if we want to achieve 80% utilization, the call
blocking probabilities using different mechanisms are
 IR, 22.6%
 BA-3, 8.3%
 BA-5, 4%
 BA-10, 2%
 BA-all, almost 0%
BA-1 performs worse than IR


because of the interaction between the two call classes
if class-1 calls reserve timeslots with gaps, class-2 calls
are denied
13
Xiangfei Zhu, [email protected]
Third type of BW sharing

Calls with small-m, short-duration


Call queueing mode
Have a couple of ideas, but need to study


delayed start
distributed queueing at callers (like CSMA-CD)
14
Status check

Outline


eScience vs. commercial
networks
Three modes of bandwidth
sharing




large-m
small-m, long-held calls
small-m, short-duration calls
Applications
15
Applications (small-m, long-held)

Cheetah project supports TSI (Terascale Supernova Initiative)



Very large dataset (TB) transfers
Ensight for remote visualization
Other apps with high-throughput long-duration calls (good for
book-ahead)






Other eScience applications
e-Learning (small-USBs at each desk - better quality)
Access Grid, Videnet video conferencing, teleimmersion
Distributed Grid computing - MPI apps, e.g. blast (recruit clusters 6 hours)
IPTV/VOD/HDTV/Triple-play video streaming (entertainment)
Asynchronous Storage Area Network support (nightly backups)
16
Applications

Large-m applications


High-quality video-telephony (10Mbps) at every desk (3 min. average
durations)
100MB to GB range file transfers:





Remote storage: LORS IBP Depots, synchronous SAN operations
Gaming (warcraft, battlenet)




currently written for low-BW; need good Graphics cards
if higher-BW is available can more information be moved with simpler lowercost graphics cards for a lower-lag experience?
OfficeLive, "network is the computer" model, old dumb-terminal model


through web (Red Hat Linux distribution)
GridFTP, PVFS, NFS/XFS
web caching
lower admin costs
Others? Suggestions?
Small-m (high-throughput), short-duration calls


100MB to GB range file transfers
Want to give 1Gbps per transfer to lower delays
17
Status check

Outline


eScience vs. commercial
networks
Three modes of bandwidth
sharing




large-m
small-m, long-held calls
small-m, short-duration calls
Apps for large-m
 video-telephony
 web downloads and caching
18
Video telephony



Paul Sijben writes: "Today, video telephony usually implies that a
group of people gather around a table and watch a TV showing a
similar group of people around another table. Personal video
telephony usually means watching postage stamp sized people in
a PC screen, whose image is refreshed occasionally."
Also, "As has been known for quite some time, the nuances of
face, body and arm gestures add a wealth of information to
communication."
Can we exploit higher-speeds (10Mbps, OC1, OC3 rates) for
better TV-like video-telephony?


Delay requirement: 150ms one-way
Compress less, use more bandwidth for lower latency and higher
quality
19
Sony SNC-RZ30 Camera
• Ethernet output:
• 640 x 480 @ 30 FPS
• ~ 8Mb/s using Motion-JPEG
• Built-in web server
• Total system latency
• ~109ms
(90-160ms observed)
• Timer courtesy of www.Auvidea.com
20
Tyson Baldridge, [email protected]
Video Products Group – VPG5720


Maps video signal onto a Sonet OC3
I/O Connections:







Video: SDI or NTSC/PAL
Audio: AES/EBU or analog
A/V Sync within 10mS
Unidirectional: need a TX & RX module at both endpoints.
Need one chassis per endpoint: VPG6200
Esoteric solution, but ideal for testing best-case
performance
Any experience?
21
Tyson Baldridge, [email protected]
Other issues









Automating "camera-man," "director" roles
Movement sensor based positioning of camera?
Lighting issues
Eye contact
Placement in offices
LCD projectors on to walls?
Multiple camera feeds - hence the director role?
Not really teleimmersion but a better experience to
improve remote communications (save energy costs, less
travel!)
Suggestions?
22
Status check

Outline


eScience vs. commercial
networks
Three modes of bandwidth
sharing




large-m
small-m, long-held calls
small-m, short-duration calls
Apps for large-m
 video-telephony
 web downloads and caching
23
File transfer application

Two CHEETAH solutions


Web file transfers across CHEETAH (end-to-end)
Web caching (partial-path circuits)
24
Web File Transfer on CHEETAH
Consists of a software package, called WebFT

Leverages CGI for deployment without
modifying web client and web server software

Integrated
with
CHEETAH
end-host
software APIs to provide use of CHEETAH
network in a mode transparent to users
Xiuduan Fang, [email protected]
25
WebFT Architecture
Web server
Web client
Web Browser
(e.g. Mozilla)
URL
Response
RSVP-TE
daemon
Web Server
(e.g. Apache)
CGI scripts
(download.cgi &
redirection.cgi
WebFT sender
WebFT receiver
RSVP-TE API
C-TCP API
Control messages
via Internet
Data transfers
via a circuit
Cheetah end-host software APIs
and daemons
OCS API RD API
OCS daemon
RSVP-TE API
RD daemon
C-TCP API
RSVP-TE daemon
Cheetah end-host software APIs
and daemons
OCS: Optical connectivity service
RD: Routing Decision
C-TCP: Circuit TCP
26
Xiuduan Fang, [email protected]
Experimental Testbed and Results for
WebFT--cont.
Internet
IP routers
IP routers
NIC I
NIC I
zelda3
NIC II
wukong
CHEETAH
Network
Sycamore SN16000
Atlanta, GA


NIC II
Sycamore SN16000
MCNC, NC
Zelda3 and Wukong: Dell machines, running Linux FC3 and ext2/3, with
RAID-0 SCCI disks
RTT between them: 24.7ms on the Internet path, and 8.6ms for the
CHEETAH circuit.
27
Xiuduan Fang, [email protected]
Experimental Results for
WebFT--cont.
The web page to test WebFT


Test parameters:
 Test.rm: 1.6 GB, circuit rate: 1 Gbps
Test results
 throughput: 680 Mbps, delay: 19 s
28
Xiuduan Fang, [email protected]
Web caching (partial-path circuits)


Uses the web proxy software package, squid,
to make CHEETAH accessible to nonCHEETAH hosts.
Improves web performance by


Breaking up the long-distance connectionless (CL)
path into a partial circuit through CHEETAH, and
two low-RTT CL sub-paths
Leverages web caching protocols
29
Xiuduan Fang, [email protected]
The Framework for using web
caching and partial-path circuits
Internet
Original HTTP messages
HTTP
messages
Web client
HTTP
messages
squid
squid
CHEETAH
CHEETAH
Application
Gateway (CAG)
HTTP and ICP
messages
Web server
CHEETAH
Application
Gateway (CAG)
30
Xiuduan Fang, [email protected]
Experimental Testbed
Web server
Web client
Ballstein.cs.virginia.edu
CHEETAH
CAG
wuneng at MCNC
NIC I: 128.109.34.22
NIC II: 152.48.249.103




CAG
zelda1 at Atlanta
NIC I: 130.207.252.131
NIC II: 10.0.0.11
Configure caching hierarchy such that zelda1’s NIC II is
wuneng’s parent.
Configure CAGs to cache file with the size < 4 GB
RTT for the Internet path:
 ballstein and wuneng: 14.6 ms
RTT for the CHEETAH path

wuneng and zelda1: 8.9 ms
31
Xiuduan Fang, [email protected]
Experimental Results for Web
Partial CO Transfer
Web server parameters
name
RTT (ms) with
location
zelda1
ballstein
total
RTT (ms)
through
CHEETAH
file
size
(MB)
delay (s) through
CHEETAH,
cached?
No
Yes
Intern
et path
www.kernel.org
Ashland,
Oregon
61.6
86.0
14.6 + 8.9 +
61.6 = 85.1
48
33
18
70
internap.dl.sour
ceforge.net
Atlanta,
GA
6.0
32.0
14.6 + 8.9 +
6.0 = 29.5
113
140
36
520
www.cs.virginia.
edu
Charlot
tesville,
VA
25.0
<1
14.6 + 8.9 +
25.0 = 48.5
113
50
30
14
32
Xiuduan Fang, [email protected]
Future Work




Decide whether to use a partial-path
circuit by examining the client’s
geographic location relative to server
Use squid to connect multiple circuit/VC
networks to further reduce RTT
Test the scalability and reliability of squid
Model, analyze and measure performance
improvement by using a partial-path circuit
33
Xiuduan Fang, [email protected]
Thanks for listening!

Conclusions:




Add MPLS and/or SONET to create large-m (moderateBW) mode of sharing
Enable partial-path circuits - through Policy Based
Routing to isolate flows (trigger signaling from host)
Avoiding BW partitioning for IR and BA is hard because
IR calls have unlimited holding time while BA needs
specified holding time
 Centralized scheduler per domain is acceptable if BA
load is low
Suggestions, comments, thoughts?

email address: [email protected]
34
CHEETAH Network
NYC
HOPI
Force10
UVa
UVa host H
ORNL
1G
Compute-0-2 152.48.249.4
1GFC
UCNS
1G
1G
1G
H
H
H
WASH
Abilene
T640
H
CUNY host
CUNY
OC192
Centuar
FastIron
FESX448
1G
1G
1G
H
Compute-0-1 152.48.249.3
H
Compute-0-0 152.48.249.2
Wukong
152.48.249.102 H
X1(E)
OC192
1G
2x1G
MPLS tunnels
WASH
HOPI
Force10
Orbitty Compute Nodes
Compute-0-4 152.48.249.6
Compute-0-3 152.48.249.5
Force10
E300
switch
1G
UVa
Catalyst
4948
1G
NCSU
M20
NC
CUNY
Foundry
3x1G VLAN
GbE
1G
1G
GbE
Zelda4 10.0.0.14 H
Zelda5 10.0.0.15 H
1G
1G
1-8-33
1-8-34
1-6-1 1-7-1
1-8-35
1-8-36
1-8-37
1-6-17 1-7-17
1-8-38
10GbE OC192
1-7-33
1-7-34
1-7-35 1-7-1 1-6-1
1-7-36
1G
1G
1G
1G
1G
1G
1-8-39
Cheetah-ornl
MCNC
Catalyst
7600
H Wuneng 152.48.249.103
cheetah-nc
Juniper
T320
Atlanta
OC-192 lamda
Zelda1 10.0.0.11 H
Zelda2 10.0.0.12 H
Zelda3 10.0.0.13 H
1G
1G
1G
1G
2x1G
MPLS tunnels
Juniper
T320
1G
GbE
10GbE OC192
1-7-33
1-7-34
1-7-35
1-6-1
1-7-36
1-7-1
1-7-37
1-7-38
1-6-17
1-7-39
Direct fibers
VLANs
MPLS tunnels
35
Cheetah-atl
Xuan Zheng, [email protected]
Current status


Thanks to HOPI: UVA and CUNY connectivity to
CHEETAH almost done
Software completed






RSVP-TE end host clients
C-TCP transport protocol
OCS - DNS based solution to check connectivity
C-VLSR for Ethernet switches
WebFT application
Current focus:

TSI support + growth of network + large-m applications
36