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



October 24, 2011                  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
October 24, 2011                  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




October 24, 2011                    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


October 24, 2011                      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


October 24, 2011                   Department of Computer Sciences, UT Austin
           Outline


            Motivation

            How Nice works

            Evaluation

            Case studies

            Conclusions

October 24, 2011            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?


October 24, 2011                   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

October 24, 2011                    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

October 24, 2011                 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



October 24, 2011           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 }

October 24, 2011                      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

October 24, 2011                Department of Computer Sciences, UT Austin
           Evaluation of Nice


            Analysis

            Simulation micro-benchmarks

            WAN measurements

            Case studies




October 24, 2011            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



October 24, 2011                       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



October 24, 2011                   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


October 24, 2011                    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

October 24, 2011                       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.
October 24, 2011                                           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
October 24, 2011                                       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
October 24, 2011                                        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

October 24, 2011                       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)


October 24, 2011                                      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

October 24, 2011                      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


October 24, 2011                     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

October 24, 2011                                      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

October 24, 2011                                   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




October 24, 2011          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


October 24, 2011                        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
October 24, 2011                                          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



October 24, 2011                     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


October 24, 2011                  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
October 24, 2011                    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
October 24, 2011                   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
October 24, 2011                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
October 24, 2011                                         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)
October 24, 2011        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
October 24, 2011                                          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
October 24, 2011                                     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

October 24, 2011                                     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

October 24, 2011                                      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


October 24, 2011                                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
October 24, 2011                                       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

October 24, 2011               Department of Computer Sciences, UT Austin

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:10/24/2011
language:English
pages:43