bu

Document Sample
bu Powered By Docstoc
					Adaptive Transmission
Protocols for the Future
       Internet

        Hari Balakrishnan
 MIT Lab for Computer Science
http://www.sds.lcs.mit.edu/~hari
   Internet Service Model
                         Internet

                         Router



     A best-effort network: losses & reordering can occur


• Congestion due to overload causes
  losses
• Transmission protocols provide end-
  to-end data transport
  – Loss recovery (if reliability is important)
  – Congestion management (to reduce
   Transmission Protocols
• User Datagram Protocol (UDP)
  – Simple datagram delivery
  – Other protocols built on top (e.g., RTP for
    video)
• Transmission Control Protocol (TCP)
  – Reliable, in-order byte stream delivery
  – Loss recovery & congestion control
• TCP is dominant today, and is tuned for:
  – Long-running transfers
  – Wired links and symmetric topologies
         Problem #1: The Web!
          r1
          r2
                            Internet
          r3
Server
                                           Client
          r-n
                • Multiple reliable streams
                • Individual objects are small
                • So what?
                  Far too inefficient!
                  Far too aggressive!
     Problem #2: Application
         Heterogeneity
         u1 r1
         u2
            r2          Internet
         u3
            r3
Server
                                        Client
         u-m r-n

 • New applications (e.g., real-time streams)
    – The world isn’t only about HTTP or even
      TCP!
 • So what?
    Applications do not adapt to congestion
            Problem #3: Technology
                       Heterogeneity
Metricom Ricochet Lucent WaveLAN

                                                Regional-Area
                                                      +
                                                 Asymmetry




Cellular Digital   IBM Infrared                     Metro-Area
Packet Data (CDPD)
                                              Campus-Area
• Tremendous diversity                        Packet Radio
• So what?                            In-Building
    Awful performance
    Mobility-related inefficiencies
    Why is Efficient Transport
              Hard?
•   Congestion
•   Channel errors
•   Asymmetry
•   Latency variability
•   Packet reordering
•   Mobility
•   Large network “pipes”
•   Small network “pipes”
       Solution: Adaptive
        Transmissions
• A framework to adapt to various
  network conditions
• Guiding principle: the end-to-end
  argument
  – Do only the “right” amount inside the
    network
  – Expose important information to
    applications
• Algorithms to adapt to different
               This Talk
•   Congestion
•   Channel errors
•   Asymmetry
•   Latency variability
•   Packet reordering
•   Mobility
•   Large network “pipes”
•   Small network “pipes”
               TCP Overview
• Loss                       7
                     8               6
  recovery
        10
          9                                       5
                                                      4
                                                          3
                                                               1
                                         1                        0
               1
          0          1           1                 2          lost

      Timeouts based on mean round-trip time (RTT) and deviation
      Fast retransmissions based on duplicate ACKs

• Congestion control
  – Window-based algorithm to
    determine sustainable rate
  – Upon congestion, reduce window
  – “ACK clocking” sends data
    Congestion Management
         Challenges
•   Heterogeneous traffic mix
•   Multiple concurrent streams
•   Variety of applications and transports
•   Control algorithms must be stable
•   Clean separation from other tasks like
    loss recovery
     “Solution” #1: Persistent
           Connections
         r1
         r2
                 Put everyone on same
         r3       ordered byte stream
Server
         r-n                                  Client

    While this fixes some of the problems of independent
    connections, it really is a step in the wrong direction!
          1. Far too much coupling between objects
          2. Far too application-specific
          3. Does not enable application adaptation
       “Solution” #2: Web
          Accelerators
• Is your Web experience too slow?
• Chances are, it’s because of pesky
  TCP congestion control and those
  annoying timeouts
• Web accelerators will greatly speed up
  your transfers…
• By just “adjusting” TCP’s congestion
  control!
 “Solution” #3: Integrated TCP
           Sessions
         r1
         r2
         r3
Server
         r-n                             Client


• Independent TCP connections, but shared control parame
   [BPS+98, Touch98]
• Shared congestion windows, round-trip estimates
• But, this approach doesn’t accomodate non-TCP traffic
   What is the World Heading
            Toward?
          u1 r1
          u2
             r2           Internet
          u3
             r3
Server
                                           Client
         u-m r-n

         • The world won’t be just HTTP
         • The world won’t be just TCP

  Logically different streams (objects) should be kept
separate, yet efficient congestion management must be
                        performed.
      What We Really Need…
             HTTP     Audio     Video1     Video2


               TCP1     TCP2             UDP


Congestion
Manager                        IP


  An integrated approach to end-to-end
   congestion management for the Internet
   using the CM
 CM: Some Salient Features
• Shared learning
  – Maintains host- and domain-specific
    information
• Heterogeneous application support
• Simple application interfaces to CM
• Robust and stable rate control
  algorithms
• Flexible bandwidth-apportioning using
  receiver hints
• Enables application adaptation to
              The CM API
• A simple but powerful application-to-CM
  API
• Three classes of functions
  – Query
  – Control
  – Application callback
• Design principle: Application-Level
  Framing (ALF)
  – Feed information up to application
  – Application decides what to send; CM tells it
      How the API Works




CM does not buffer any data; request/callback/notify API
      Preliminary Results
• Simulation results show significant
  improvements in performance
  predictability
  – E.g., TCP with CM reduces timeouts and
    shares bandwidth well between connections
• CM’s internal congestion algorithm is
  rate-based
  – Great platform for experimenting with new
    control schemes
• Experiments with scheduling algorithms
       Summary & Status
• The CM provides a simple API to make
  applications adaptive and network-
  aware
  – Enables all traffic to adhere to basic
    congestion control principles
  – Improves performance predictability
  – Enables shared state learning
• ns-2 experiments in progress
• Linux implementation coming soon
  (including rate-adaptive applications)
               This Talk
•   Congestion
•   Channel errors
•   Asymmetry
•   Latency variability
•   Packet reordering
•   Mobility
•   Large network “pipes”
•   Small network “pipes”
   TCP/Wireless Performance
            Today
        Technology     Rated        Typical TCP
                       Bandwidth    Throughput
        IBM            1 Mbps       100-800 Kbps
        Infrared
        Lucent          2 Mbps      50 Kbps-1.5 Mbps
        WaveLAN
        Metricom        100 Kbps    10-35 Kbps
        R icochet
        Hybrid wireless 10 Mbps     0.5-3.0 Mbps
        cable


Goal: To bridge the gap between perceived and rated performance
        Channel Errors
                          Internet

                           Router



                     Loss  Congestion
                                                3
                                                2
                                                  11
                                                  22
Burst losses lead to coarse-grained timeouts
                                                           0
                                     Loss ==> Congestion




        Result: Low throughput
  Performance Degradation
                            2.0E+06
                                               Best possible
                                               TCP with no errors
  Sequence number (bytes)




                                               (1.30 Mbps)
                            1.5E+06
                                                                         TCP Reno
                                                                         (280 Kbps)

                            1.0E+06




                            5.0E+05




                            0.0E+00
                                      0   10      20      30        40     50         60
                                                       Time (s)
2 MB wide-area TCP transfer over 2 Mbps Lucent WaveLAN
      Our Solution: Snoop
           Protocol
• Shield TCP sender from wireless vagaries
  – Eliminate adverse interactions between protocol
    layers
  – Congestion control only when congestion occurs
• The End-to-End Argument [SRC84]
  – Preserve TCP/IP service model: end-to-end
    semantics
  – Is connection splitting fundamentally important?
• Eliminate non-TCP protocol messages
  –Fixed to mobile: transport-aware link protocol
    Is link-layer messaging fundamentally important?
   Mobile to fixed: link-aware transport protocol
      Snoop Protocol: FH to MH
                          4 3 2    1   Snoop agent
      6     5
                                       Base Station


                                           1
FH Sender

Snoop agent: active interposition agent
  – Snoops on TCP segments and ACKs
  – Detects losses by duplicate ACKs and
    timers
  – Suppresses duplicate ACKs from FH
    sender                                       Mobile Host
Cross-layer protocol design: snoop agent
     Snoop Protocol: FH to MH
               Snoop Agent
       1
                         Base Station



FH Sender




                         Mobile Host
  5   Snoop Protocol: FH to MH
            4   3   2   1
                            Base Station



FH Sender




                            Mobile Host
     Snoop Protocol: FH to MH
                4 3 2   1
     6      5
                            Base Station


                               1
FH Sender




                            Mobile Host
6   Snoop Protocol: FH to MH
              4 3 2   1
         5
                          Base Station



Sender                           3
                                     2
                                         1
                                         2


                          Mobile Host
    Snoop Protocol: FH to MH
            5 4 3 2      1
     6
                               Base Station

                                   4
Sender                                 3

                                              2
               Duplicate ACK   ack 0

                               Mobile Host


                          1
    Snoop Protocol: FH to MH
           6 5 4 3 2     1
                               6
                               Base Station
                                 5

                                             Retransmit from cache
                                      1      at higher priority
Sender           ack 0


                                                      4 3 2
                             ack 0

                                     ack 0
                                Mobile Host


                         1
    Snoop Protocol: FH to MH
           6 5 4 3 2         1

                                 Base Station



Sender                                5
                    ack 0
              Suppress                      1 4 3 2
            Duplicate Acks
                                    ack 4
                                 Mobile Host


                             1
    Snoop Protocol: FH to MH
               6 5      Clean cache on new ACK


                             Base Station

                                  6
Sender
                ack 4
                                       5 1 4 3 2

                                  ack 5
    Snoop Protocol: FH to MH
                    6
                         Base Station



Sender
         ack 4   ack 5
                             6   1 5 4 3 2

                             ack 6
                         Mobile Host
    Snoop Protocol: FH to MH
                               7
           9           8
                                             Base Station



Sender
               ack 5               ack 6
                                                 6   1 5 4 3 2


   Active soft state agent at base station
   Transport-aware reliable link protocol
   Preserves end-to-end semantics                     Mobile Host
                                    Snoop Performance
                                       Improvement
                          2.0E+06
                                        Best        Snoop (1.11 Mbps)
                                        possible
Sequence number (bytes)




                          1.5E+06
                                        TCP
                                        (1.30                                TCP Reno
                                        Mbps)                                (280 Kbps)
                          1.0E+06



                          5.0E+05



                          0.0E+00
                                    0          10      20      30       40       50       60
                                                            Time (s)
2 MB wide-area TCP transfer over 2 Mbps Lucent WaveLAN
 Benefits of TCP-Awareness
   Congestion Window (bytes)
                               60000                    Snoop
                               50000

                               40000

                               30000

                               20000

                               10000            LL (no duplicate ack suppression)
                                  0
                                       0   10     20     30      40        50   60   70   80
                                                              Time (sec)

• 30-35% improvement for Snoop: LL congestion
  window is small (but no coarse timeouts occur)
• Connection bandwidth-delay product = 25 KB
Suppressing duplicate acknowledgments and TCP-awareness
leads to better utilization of link bandwidth and performance
      Snoop Protocol Status
• BSD/OS implementation
  – Integrated with Daedalus low-latency handoff
    software
• Version 1 released 1996; Version 2 released
  1998
• In daily production use at Berkeley and UC
  Santa Cruz
• Several hundred downloads
  – Ports to Linux, FreeBSD, NetBSD
       Summary: Wireless Bit-
             Errors
• Problem: wireless corruption mistaken for
  congestion
• Solution: Snoop Protocol
• General lessons
    – Lightweight soft-state agent in network infrastructure
       • Guided by the End-to-End Argument
       • Fully conforms to the IP service model
    – Cross-layer protocolTransport & optimizations
                            design
                                           Link-aware transport
                           Network      (Explicit Loss Notification)
Transport-aware link         Link
(Snoop agent at BS)         Physical
            Conclusions
• Efficient data transport is a hard
  problem: congestion, errors,
  asymmetry,...
• Adaptive transmission schemes are
  essential in the future Internet
• Architectural components should
  include
  – Congestion Manager (CM)
  – Error-handlers (e.g., Snoop protocol)
  – (And many other features)
• Wanted: a grand unified transmission

				
DOCUMENT INFO
Categories:
Tags:
Stats:
views:3
posted:1/21/2012
language:English
pages:42