nice

Document Sample
nice Powered By Docstoc
					                       TCP Nice: A Mechanism for
                         Background Transfers


                  Arun Venkataramani, Ravi Kokku, Mike Dahlin

                Laboratory of Advanced Systems Research(LASR)
                 Computer Sciences, University of Texas at Austin



April 4, 2013                  Department of Computer Sciences, UT Austin
            What are background transfers?


             Data that humans are not waiting for
             Non-deadline-critical
             Unlimited demand

             Examples
                - Prefetched traffic on the Web
                - File system backup
                - Large-scale data distribution services
                - Background software updates
                - Media file sharing
April 4, 2013                  Department of Computer Sciences, UT Austin
            Desired Properties


             Utilization of spare network capacity

             No interference with regular transfers
                - Self-interference
                   - applications hurt their own performance
                - Cross-interference
                   - applications hurt other applications’ performance




April 4, 2013                    Department of Computer Sciences, UT Austin
            Goal: Self-tuning protocol

             Many systems use magic numbers
                -   Prefetch threshold [DuChamp99, Mogul96, …]
                -   Rate limiting      [Tivoli01, Crovella98, …]
                -   Off-peak hours     [Dykes01, many backup systems, …]


             Limitations of manual tuning
                -   Difficult to balance concerns
                -   Proper balance varies over time


             Burdens application developers
                -   Complicates application design
                -   Increases risk of deployment
                -   Reduces benefits of deployment


April 4, 2013                      Department of Computer Sciences, UT Austin
            TCP Nice


             Goal: abstraction of free infinite bandwidth
             Applications say what they want
                - OS manages resources and scheduling

             Self tuning transport layer
                - Reduces risk of interference with FG traffic
                - Significant utilization of spare capacity by BG
                - Simplifies application design


April 4, 2013                   Department of Computer Sciences, UT Austin
            Outline


             Motivation

             How Nice works

             Evaluation

             Case studies

             Conclusions

April 4, 2013                Department of Computer Sciences, UT Austin
            Why change TCP?


             TCP does network resource management
                - Need flow prioritization

             Alternative: router prioritization
                + More responsive, simple one bit priority
                - Hard to deploy

             Question:
                - Can end-to-end congestion control achieve non-
                  interference and utilization?


April 4, 2013                   Department of Computer Sciences, UT Austin
            Traditional TCP Reno

             Adjusts congestion window (cwnd)
                - Competes for “fair share” of BW (=cwnd/RTT)
             Packet losses signal congestion
                - Additive Increase
                   - no losses  Increase cwnd by one packet per RTT
                - Multiplicative Decrease:
                   - one packet loss (triple duplicate ack) halve cwnd
                   - multi-packet loss  set cwnd = 1


             Problem: signal comes after damage done

April 4, 2013                    Department of Computer Sciences, UT Austin
            TCP Nice

             Proactively detects congestion

             Uses increasing RTT as congestion signal
                - Congestion  incr. queue lengths  incr. RTT

             Aggressive responsiveness to congestion

             Only modifies sender-side congestion control
                - Receiver and network unchanged
                - TCP friendly

April 4, 2013                 Department of Computer Sciences, UT Austin
            TCP Vegas


             Early congestion detection using RTTs

             Additive decrease on early congestion

             Restrict number of packets maintained by
              each flow at bottleneck router

             Small queues, yet good utilization



April 4, 2013               Department of Computer Sciences, UT Austin
            TCP Nice

             Basic algorithm
                -   1. Early Detection  thresh. queue length incr. in RTT
                -   2. Multiplicative decrease on early congestion
                -   3. Maintain small queues like Vegas
                -   4. Allow cwnd < 1.0

             per-ack operation:
               - if(curRTT > minRTT + threshold*(maxRTT – minRTT))
                     numCong++;
             per-round operation:
               - if(numCong > f.W)
                      W  W/2
                  else { … Vegas congestion control }

April 4, 2013                      Department of Computer Sciences, UT Austin
            Nice: the works

                Reno Add *          Add *              Add *                   Mul +
                Nice Add *         Add + Mul +                                 Mul +
                                      t.B


                           m                                                        pkts

                                                                 B
                         minRTT = t                                         maxRTT = t+B/m


          Non-interference getting out of the way in time
          Utilization maintaining a small queue

April 4, 2013                  Department of Computer Sciences, UT Austin
            Evaluation of Nice


             Analysis

             Simulation micro-benchmarks

             WAN measurements

             Case studies




April 4, 2013                Department of Computer Sciences, UT Austin
            Theoretical Analysis

             Prove small bound on interference

             Main result – interference decreases exponentially
              with bottleneck queue capacity, independent of the
              number of Nice flows

             Guided algorithmic design
                -   All 4 aspects of protocol essential


             Unrealistic model
                -   Fluid approximation
                -   Synchronous packet drop



April 4, 2013                       Department of Computer Sciences, UT Austin
            TCP Nice Evaluation


             Micro-benchmarks (ns simulation)
                - test interference under more realistic assumptions
                   - Near optimal interference
                   - 10-100X less than standard TCP
                - determine if Nice can get useful throughput
                   - 50-80% of spare capacity
                - test under stressful network conditions
                - test under restricted workloads, topologies



April 4, 2013                   Department of Computer Sciences, UT Austin
            TCP Nice Evaluation


             Measure prototype on WAN
                + test interference in real world
                + determine if throughput is available to Nice
                - limited ability to control system

             Results
                - Nice causes minimal interference
                   - standard TCP – significant interference
                - Significant spare BW throughout the day


April 4, 2013                    Department of Computer Sciences, UT Austin
            NS Simulations

             Background traffic:
                -   Long-lived flows
                -   Nice, rate limiting, Reno, Vegas, Vegas-0
                -   Ideal: Router prioritization
             Foreground traffic: Squid proxy trace
                -   Reno, Vegas, RED
                -   On/Off UDP
             Single bottleneck topology
             Parameters
                -   spare capacity, number of Nice flows, threshold
             Metric
                -   average document transfer latency

April 4, 2013                       Department of Computer Sciences, UT Austin
            Network Conditions
                                          1e3


                 Document Latency (sec)   100


                                           10                 V0
                                                                                                      Reno
                                                       Nice
                                            1                                          Vegas

                                                    Router Prio
                                          0.1
                                                1                            10                              100
                                                                       Spare Capacity

           Nice causes low interference even when there isn’t
            much spare capacity.
April 4, 2013                                            Department of Computer Sciences, UT Austin
            Scalability

                                          1e3
                                                                                         Vegas
                 Document Latency (sec)
                                          100
                                                    Reno

                                           10                                                     V0

                                                                                                   Nice
                                            1
                                                          Router Prio
                                          0.1
                                                1                       10                                100
                                                                   Num BG flows


           W < 1 allows Nice to scale to any number of
            background flows
April 4, 2013                                        Department of Computer Sciences, UT Austin
            Utilization

                                     8e4
                                                               Vegas
                                                   Reno
                                     6e4                                                    Router Prio
                BG Throughput (KB)




                                     4e4
                                                    V0

                                                                                     Nice
                                     2e4


                                           0
                                               1                      10                                  100
                                                                 Num BG flows


           Nice utilizes 50-80% of spare capacity w/o stealing
            any bandwidth from FG
April 4, 2013                                        Department of Computer Sciences, UT Austin
            Case study 1 : Data Distribution

             Tivoli Data Exchange system

             Complexity
                -   1000s of clients
                -   different kinds of networks – phone line, cable modem, T1


             Problem
                -   tuning data sending rate to reduce interference and
                    maximize utilization


             Current solution
                -   manual setting for each set of clients

April 4, 2013                       Department of Computer Sciences, UT Austin
            Case study 1 : Data Distribution

                                       350
                                                                                   Manual tuning
                                       300                                                  Nice point
                Ping latency (in ms)



                                       250                                                                             Austin
                                                                                                                         to
                                       200                                                                             London
                                       150

                                       100

                                       50

                                             20    40    60         80        100       120          140   160   180
                                                  Completion time(in seconds)


April 4, 2013                                           Department of Computer Sciences, UT Austin
            Case study 2: Prefetch-Nice

             Novel non-intrusive prefetching system [USITS’03]

             Eliminates network interference using TCP Nice
             Eliminates server interference using simple monitor

             Readily deployable
                -   no modifications to HTTP or the network
                -   JavaScript based


             Self-tuning architecture, end-to-end interference
              elimination

April 4, 2013                      Department of Computer Sciences, UT Austin
            Case study 2: Prefetch-Nice



                                                                          Hand-tuned threshold
                     Response time



                                                                                   Aggressive threshold
                                                                                              +
                                                                                    Self-tuning protocol
                                     Aggressiveness


           A self-tuning architecture gives optimal performance
            for any setting


April 4, 2013                         Department of Computer Sciences, UT Austin
            Prefetching Case Study



                                                       Cable modem

                                      120
                Response time (sec)




                                      100
                                      80
                                                                                                       Reno
                                      60
                                                                                                       Nice
                                      40
                                      20
                                        0
                                            None                   Cons                         Aggr
                                                      Prefetching mode

April 4, 2013                                      Department of Computer Sciences, UT Austin
            Prefetching case study



                                                        Phone line
                                      4000
                Response time (sec)




                                      3500
                                      3000
                                      2500                                                          Reno
                                      2000                                                          Nice
                                      1500
                                      1000
                                       500
                                         0
                                             None                Cons                        Aggr
                                                    Prefetching mode

April 4, 2013                                   Department of Computer Sciences, UT Austin
            Conclusions


             End-to-end strategy can implement simple
              priorities

             Enough usable spare bandwidth out there
              that can be Nicely harnessed

             Nice makes application design easy




April 4, 2013              Department of Computer Sciences, UT Austin
            TCP Nice Evaluation Key Results

             Analytical
                -   interference bounded by factor that falls exponentially with
                    bottleneck queue size independent of no. of Nice flows
                -   all 3 aspects of algorithm fundamentally important
             Microbenchmarks (ns simulation)
                -   near optimal interference
                -   interference up to 10x less than standard TCP
                -   TCP-Nice reaps substantial fraction of spare BW
             Measure prototype on WAN
                -   TCP Nice: Minimal interference
                     - standard TCP: Significant interference
                -   significant spare BW available throughout the day


April 4, 2013                        Department of Computer Sciences, UT Austin
            Freedom from thresholds
                                          20
                Document Latency (sec)


                                          16
                                                   I » O(e-B/m.(1-t))
                                          12


                                          8

                                          4

                                          0
                                               0    0.2     0.4    0.6                     0.8            1
                                                            Threshold


           Dependence on threshold is weak
                                         - small threshold )low interference
April 4, 2013                                                Department of Computer Sciences, UT Austin
            Manual tuning

             Prefetching – attractive, restraint necessary
                - prefetch bandwidth limit [DuChamp99, Mogul96]
                - threshold probability of access [ Venk’01]
                - pace packets by guessing user’s idle time [Cro’98]
                - prefetching during off-peak hours [Dykes’01]

             Data distribution / Mirroring
                - tune data sending rates on a per-user basis
                - Windows XP – Background (BITS)
                   - rate throttling approach
                   - different rates  different priority levels



April 4, 2013                     Department of Computer Sciences, UT Austin
            Goal: Self-tuning protocol


             Hand-tuning may not work
                - Difficult to balance concerns
                - Proper balance varies over time

             Burdens application developers
                - Complicates application design
                - Increases risk of deployment
                - Reduces benefits of deployment


April 4, 2013                  Department of Computer Sciences, UT Austin
            Nice: the works
                   Reno Add *       Add * Add *
                  Vegas Add *       Add + Add +
                   Nice Add * Add + Mul +
                                        t.B


                             m                                                        pkts

                                                                   B
                            minRTT = t                                        maxRTT = t+B/m


          Nested congestion triggers:
                - Nice < Vegas < Reno
April 4, 2013                    Department of Computer Sciences, UT Austin
            TCP Vegas
                                                    Expected


                m
                                       Diff
                                                                 Actual
                                a

                                     b
                    1/minRTT
                               W*                              Window

                E = W / minRTT                              if(Diff < a / minRTT)
                A = W /observedRTT                               WÃW+1
                                                            else if(Diff > b / minRTT)
                Diff = (E – A)/minRTT
                                                                 WÃW-1

             Additive decrease when packets queue
April 4, 2013                       Department of Computer Sciences, UT Austin
            Nice features

               Small a, b not good enough. Not even zero!
               Need to detect absolute queue length
               Aggressive backoff necessary
               Protocol must scale to large number of flows


             Solution
              - Detection ! ‘threshold’ queue build up
              - Avoidance ! Multiplicative backoff
              - Scalability ! window is allowed to drop
                below 1
April 4, 2013                Department of Computer Sciences, UT Austin
            Internet measurements
                 Long Nice and Reno flows
                 Interference metric: flow completion time

                                          80
                   Transfer times (sec)



                                          70
                                          60
                                          50                                                               BG
                                          40
                                          30                                                               FG
                                          20
                                          10
                                           0
                                                    BG


                                                                G




                                                                                             G

                                                                                                      BG
                                               FG




                                                                              G
                                                             2F




                                                                                         9F
                                                                         /B




                                                                                                   /8
                                                                       FG




                                                                                                 FG
                                                    Nice vs Reno: cable modem
April 4, 2013                                            Department of Computer Sciences, UT Austin
            Internet measurements


           Long Nice and Reno flows
           Interference metric: flow completion time

           Extensive measurements over different
            kinds of networks
             - Phone line
             - Cable modem
             - Transcontinental link (Austin to
               London)
             - University network (Abilene: UT Austin
               to Delaware)
April 4, 2013            Department of Computer Sciences, UT Austin
            Internet measurements
                 Long Nice and Reno flows
                 Interference metric: flow completion time

                                          100
                   Transfer times (sec)




                                           80
                                           60
                                           40                                                                 BG
                                           20                                                                 FG

                                            0
                                                     BG


                                                                   G




                                                                                               G

                                                                                                         BG
                                                FG




                                                                                 G
                                                               2F




                                                                                           9F
                                                                           /B




                                                                                                         /8
                                                                         FG




                                                                                                       FG
                                                 Nice vs Reno: Austin to London
April 4, 2013                                             Department of Computer Sciences, UT Austin
            Internet measurements
                 Long Nice and Reno flows
                 Interference metric: flow completion time

                                          400
                                          350
                   Transfer times (sec)




                                          300
                                          250
                                          200
                                          150                                                             BG
                                          100                                                             FG
                                           50
                                            0
                                                FG             BG                  2FG            FG/BG
                                                Nice vs Reno: phone line
April 4, 2013                                        Department of Computer Sciences, UT Austin
            Internet measurements
                                                       Austin to London
                                      25

                Response Time (sec)        Reno
                                      20
                                           Nice
                                      15

                                      10

                                       5

                                       0
                                      May 10 May 11 May 12 May 13 May 14 May 15
                                                             Time of day


           Useful spare capacity throughout the day

April 4, 2013                                     Department of Computer Sciences, UT Austin
            Internet measurements
                                                           Cable modem
                                      300

                                      250
                Response Time (sec)
                                            Reno
                                      200   Nice
                                      150

                                      100

                                       50

                                        0
                                              May 13        May 14            May 15            May 16
                                                             Time of day


           Useful spare capacity throughout the day

April 4, 2013                                      Department of Computer Sciences, UT Austin
            NS Simulations - Red



                       80000

                       70000

                       60000
                BG Throughput (KB)




                       50000

                       40000

                       30000

                       20000
                                                                                    Router Prio
                       10000                                                          Nice-0.03
                                                                                          Nice
                                                                                         Vegas
                                                                                         Reno
                                     0
                                         1                    10                                  100
                                                          Num BG flows


April 4, 2013                                Department of Computer Sciences, UT Austin
            NS Simulations - Red



                               100
                                                  Reno
                Document Latency (sec)




                                                                                        Vegas
                                         10


                                                            Nice

                                         1



                                                             Router Prio
                                                                                            Nice-0.03
                                     0.1
                                              1                         10                              100
                                                                  Spare Capacity
April 4, 2013                                       Department of Computer Sciences, UT Austin
            Analytic Evaluation


             All three aspects of protocol essential
             Main result – interference decreases
              exponentially with bottleneck queue
              capacity irrespective of the number of
              Nice flows
                - fluid approximation model
                - long-lived Nice and Reno flows
                - queue capacity >> number of foreground
                 flows

April 4, 2013               Department of Computer Sciences, UT Austin

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:4/4/2013
language:English
pages:43