FAST TCP - PowerPoint PPT Presentation

1 / 25
About This Presentation
Title:

FAST TCP

Description:

Andrew, Bunn, Choe, Doyle, Hegde, Jin, Li, Low, Newman, ... Paganini, Z. Wang. StarLight. deFanti, Winkler. CERN. Martin. SLAC. Cottrell. PSC. Mathis ... – PowerPoint PPT presentation

Number of Views:50
Avg rating:3.0/5.0
Slides: 26
Provided by: steve429
Category:
Tags: fast | tcp | paganini

less

Transcript and Presenter's Notes

Title: FAST TCP


1
FAST TCP
  • Design, architecture, algorithms
  • Experimental evaluations

Lachlan Andrew(for Steven Low) netlab.CALTECH.edu

2
Acks Collaborators
  • Caltech
  • Andrew, Bunn, Choe, Doyle, Hegde, Jin, Li, Low,
    Newman, Papadoupoulous, Ravot, Singh, Tang, J.
    Wang, Wei, Wydrowski, Xia
  • UCLA
  • Paganini, Z. Wang
  • StarLight
  • deFanti, Winkler
  • CERN
  • Martin
  • SLAC
  • Cottrell
  • PSC
  • Mathis
  • Internet2
  • Almes, Shalunov
  • Abilene GigaPoPs
  • GATech, NCSU, PSC, Seattle, Washington
  • Cisco
  • Aiken, Doraiswami, McGugan, Smith, Yip
  • Level(3)
  • Fernes
  • LANL
  • Wu

3
TCP/AQM
  • Congestion control is a distributed asynchronous
    algorithm to share bandwidth
  • It has two components
  • TCP adapts sending rate (window) to congestion
  • AQM adjusts feeds back congestion information
  • They form a distributed feedback control system
  • Equilibrium stability depends on both TCP and
    AQM
  • And on delay, capacity, routing, connections

4
Packet flow level
Reno TCP
FAST, BIC, H-TCP
  • Packet level - first
  • Packet level
  • Implement flow behavior

ACK W ? W 1/W Loss W ? W 0.5W
  • Flow level
  • Equilibrium
  • Fairness, performance
  • Dynamics
  • Stability
  • Understood later
  • Flow level
  • Equilibrium
  • Dynamics
  • Design for equilibrium and stability

5
Flow level Reno, HSTCP, STCP, FAST
  • Similar flow level equilibrium
  • ?, b, c determine equilibrium
  • Common flow level dynamics!

window adjustment
control gain
flow level goal
  • Different gain k and utility Ui
  • Determine equilibrium and stability
  • Different congestion measure pi
  • Loss probability (Reno, HSTCP, STCP)
  • Queueing delay (Vegas, FAST)
  • Loss pattern in BIC, HTPC, Combination in CTCP

6
FAST Architecture
Loss Control
7
Window control algorithm
  • Feedback is Queueing Delay, not Loss
  • Theorem (Infocom04, CDC04, Infocom05, Infocom07)
  • Full utilization
  • regardless of bandwidth-delay product
  • Globally stable
  • exponential convergence
  • Fairness
  • weighted proportional fairness, parameter a
  • Utility function ai log (wi/RTTi)

8
Isnt FAST just like Vegas?
  • Similarities
  • Feedback is Queueing Delay, not Loss
  • Same equilibrium
  • Differences
  • New dynamics
  • Change proportional to error
  • Responds much faster when flows come/go
  • Implementation details Burstiness control

rate
time
9
RTT
RTT 400ms double baseRTT
FAST
Throughput
Yusung Kim, KAIST, Korea 10/2004
  • All can achieve high throughput except Reno
  • FAST adds negligible queueing delay
  • Loss-based control (almost) fills buffer
  • adding delay and reducing ability to absorb bursts

HSTCP
BIC
10
Wireless Networking
max
FAST
B. Wydrowski S. Hegde Caltech, April 2005
()
11
Delay based control
  • Need not fill buffers
  • Less delay, can absorb bursts
  • Control rates but can ignore loss
  • Less need to over-engineer links
  • Continuous feedback
  • no window-halving
  • Neither more nor less conservative
  • Network equilibrium of heterogeneous congestion
    control protocolsTang et al., INFOCOM, 2005
  • Depends on buffer sizes vs link speeds
  • Can have multiple equilibria

12
Conclusion
  • Mathematically, FAST fits into the standard
    TCP/AQM framework
  • AQM signal is delay
  • High utilisation with small queues
  • Insensitive to loss
  • Stable
  • No window halving
  • Control-theoretically stable

13
Dynamic sharing 3 flows
FAST
Linux Reno
Steady throughput
HSTCP
BIC
14
queue
Room for mice !
FAST
Linux
loss
throughput
HSTCP
HSTCP
BIC
15
Is large queue necessary for high throughput?
16
  • DSL upload (6Mbps/512kbps), 5/2005
  • Min RTT 10ms

17
Ultrascale protocol development FAST TCP
  • FAST TCP
  • Based on TCP Vegas
  • Uses end-to-end delay and loss to dynamically
    adjust the congestion window
  • Defines an explicit equilibrium

Capacity OC-192 9.5Gbps 264 ms round trip
latency 1 flow
BW use 50
BW use 79
BW use 30
BW use 40
Linux TCP Westwood BIC
TCP FAST
(Yang Xia, Caltech)
18
FAST backs off to make room for Reno
Periodic losses every 10mins
(Yang Xia, Harvey Newman, Caltech)
19
I2LSR, SC2004 Bandwidth Challenge
Harvey Newmans group, Caltech http//dnae.home.ce
rn.ch/dnae/lsr4-nov04
OC48
OC192
  • November 8, 2004 Caltech and CERN transferred
  • 2,881 GBytes in one hour (6.86Gbps)
  • between Geneva - US - Geneva (25,280 km)
  • through LHCnet/DataTag, Abilene and CENIC
    backbones
  • using 18 FAST TCP streams
  • on Linux 2.6.9 kernel with 9000KB MTU
  • at 174 Pbm/s

20
  • Theory
  • general large scale network
  • performance, fairness, dynamics

theory
  • Theory
  • heterogeneous protocols
  • TCP/IP interactions
  • Alg, prototype
  • a tuning
  • loadable kernel module
  • Application
  • make robust
  • support deployment

21
(No Transcript)
22
FAST Architecture
  • Each component
  • designed independently
  • upgraded asynchronously

Loss Control
23
Window control algorithm
  • Theorem (Infocom04, CDC04, Infocom05)
  • Mapping from w(t) to w(t1) is contraction
  • Global exponential convergence
  • Full utilization after finite time
  • Utility function ai log xi (proportional
    fairness)

24
Wireless Networking
FAST
B. Wydrowski S. Hegde Caltech, April 2005
()
25
Internet2 Abilene Weather Map
OC48
OC192
7.1G GENV-PITS-LOSA-SNVA-STTL-DNVR-KSCY-HSTON-ATL
A-WASH-NYCM-CHIN-GENV
Newmans group, Caltech
Write a Comment
User Comments (0)
About PowerShow.com