TCP over Wireless (I) some slides adapted, notably from

Document Sample
TCP over Wireless (I) some slides adapted, notably from Powered By Docstoc
					TCP over Wireless (I) some slides adapted,
   notably from tutorial by Nitin Vaidya




                                             1
      Wireless Connectivity - Characteristics
   Transmission errors
     Wireless LANs - 802.11, Hyperlan
     Cellular wireless
     Multi-hop wireless
     Satellites
   Low bandwidth
     Cellular wireless
     Packet radio (e.g., Metricom)
   Long or variable latency
     GEO, LEO satellites
     Packet radio - high variability
   Asymmetry in bandwidth, error characteristics
     Satellites (example: DirectPC)
                                                    2
                  TCP/IP over Wireless

   De facto standard for internetworking

   Allows wireless devices to connect seamlessly to the
    Internet

   TCP over wireless introduces some problems not
    faced in wired networks (transmission errors, mobility
    …)
     We will overview these issues as well as existing solutions

   What type of wireless network (cellular, last hop, ad
    hoc, satellite …)?
                                                                3
               Quick review of
Transmission Control Protocol / Internet Protocol

                    TCP/IP




                                               4
                Internet Protocol (IP)


   Packets may be delivered out-of-order

   Packets may be lost

   Packets may be duplicated




                                            5
        Transmission Control Protocol (TCP)


   Reliable ordered delivery

   Implements congestion avoidance and control

   Reliability achieved by means of retransmissions if
    necessary

   End-to-end semantics
     Acknowledgements sent to TCP sender confirm delivery of
     data received by TCP receiver
    Ack for data sent only after data has reached receiver
                                                                6
                          TCP Basics

   Cumulative acknowledgements

   An acknowledgement ack’s all contiguously received
    data

   TCP assigns byte sequence numbers
   For simplicity, we will assign packet sequence
    numbers
   Also, we use slightly different syntax for acks than
    normal TCP syntax
     In our notation, ack i acknowledges receipt of packets
       through packet i
                                                               7
          Cumulative Acknowledgements

   A new cumulative acknowledgement is generated
    only on receipt of a new in-sequence packet

          40            39            38        37

               33            34            35        36




          41            40            39        38

               34            35            36        37



                    i    data     i    ack                8
             Delayed Acknowledgements
   An ack is delayed until
     another packet is received, or
     delayed ack timer expires (200 ms typical)
   Reduces ack traffic                          New ack not produced
                                                   on receipt of packet 36,
                                                     but on receipt of 37

           40           39               38             37

                33                            35




           41           40               39             38

                             35                              37
                                                                      9
            Duplicate Acknowledgements

   A dupack is generated whenever an
    out-of-order segment arrives at the receiver

          40         39                38        37

                          34                          36




          42         41                40        39

                          36                          36

                                                  Dupack
                                            On receipt of 38   10
(Above example assumes delayed acks)
             Duplicate Acknowledgements
   Duplicate acks are not delayed
   Duplicate acks may be generated when
     a packet is lost, or
     a packet is delivered out-of-order (OOO)
           40          39             37             38

                            34                            36




           41          40             39             37

                                           36             36

                                                      Dupack
                                                On receipt of 38   11
Number of dupacks depends on how much
            OOO a packet is
    40         39                  37        38

                    34                            36
                         New Ack                       New Ack


    41         40                  39        37

          34                            36        36

     New Ack                   New Ack        Dupack


     42        41                  40        39

                    36                  36        38

                New Ack             Dupack    New Ack      12
              Window Based Flow Control

   Sliding window protocol
   Window size minimum of
     receiver’s advertised window - determined by available
     buffer space at the receiver
    congestion window - determined by the sender, based on
     feedback from the network



                     Sender’s window

            1 2 3 4 5 6 7 8 9 10 11 12 13


         Acks received                 Not transmitted
                                                               13
Window Based Flow Control


      Sender’s window

1 2 3 4 5 6 7 8 9 10 11 12 13



          Ack 5




1 2 3 4 5 6 7 8 9 10 11 12 13


             Sender’s window    14
                       Ack Clock


   TCP window flow control is ―self-clocking‖

   New data sent when old data is ack’d

   Helps maintain ―equilibrium‖




                                                 15
            Window Based Flow Control

   Congestion window size bounds the amount of data
    that can be sent per round-trip time

   Throughput <= W / RTT




                                                       16
                    Ideal Window Size

   Ideal size = delay * bandwidth
     delay-bandwidth product




   What if window size < delay*bw ?
    Inefficiency (wasted bandwidth)

   What if > delay*bw ?
    Queuing at intermediate routers
        • increased RTT due to queuing delays
    Potentially, packet loss
                                                17
       How does TCP detect a packet loss?



   Retransmission timeout (RTO)



   Duplicate acknowledgements




                                            18
            Detecting Packet Loss Using
           Retransmission Timeout (RTO)


   At any time, TCP sender sets retransmission timer for
    only one packet

   If acknowledgement for the timed packet is not
    received before timer goes off, the packet is assumed
    to be lost

   RTO dynamically calculated



                                                       19
    Retransmission Timeout (RTO) calculation


   RTO = mean + 4 mean deviation
     Standard deviation s : s 2 = average of (sample – mean)2
     Mean deviation d = average of |sample – mean|
     Mean deviation easier to calculate than standard deviation
     Mean deviation is more conservative: d >= s


   Large variations in the RTT increase the deviation,
    leading to larger RTO


                                                                   20
                  Timeout Granularity

   RTT is measured as a discrete variable, in multiples
    of a ―tick‖

   1 tick = 500 ms in many implementations

   smaller tick sizes in more recent implementations
    (e.g., Solaris)

   RTO is at least 2 clock ticks



                                                           21
                      Exponential Backoff

   Double RTO on each timeout



               T1                T2 = 2 * T1
                              Timeout interval doubled
   Packet
transmitted
                Time-out occurs
              before ack received,
              packet retransmitted


                                                         22
                   Fast Retransmission


   Timeouts can take too long
     how to initiate retransmission sooner?

   Fast retransmit




                                               23
       Detecting Packet Loss Using Dupacks
           Fast Retransmit Mechanism
   Dupacks may be generated due to
     packet loss, or
     out-of-order packet delivery

   TCP sender assumes that a packet loss has occurred
    if it receives three dupacks consecutively

                            3 dupacks are also generated if a packet
      12 8 11 10 9 7        is delivered at least 3 places beyond its
                            in-sequence location


Fast retransmit useful only if lower layers deliver packets
―almost ordered‖ ---- otherwise, unnecessary fast retransmit
                                                                 24
         Congestion Avoidance and Control


Slow Start
 initially, congestion window size cwnd = 1 MSS
  (maximum segment size)
 increment window size by 1 MSS on each new ack

 slow start phase ends when window size reaches the
  slow-start threshold

   cwnd grows exponentially with time during slow start
     factor of 1.5 per RTT if every other packet ack’d
     factor of 2 per RTT if every packet ack’d
     Could be less if sender does not always have data to send 25
                Congestion Avoidance


   On each new ack, increase cwnd by 1/cwnd packets

   cwnd increases linearly with time during congestion
    avoidance
     1/2 MSS per RTT if every other packet ack’d
     1 MSS per RTT if every packet ack’d




                                                          26
                         14                    Congestion
Congestion Window size



                         12                    avoidance

                         10
     (segments)




                         8                                          Slow start
                         6Slow start                                threshold

                         4
                         2
                         0
                              0   1    2      3    4    5       6   7    8
                                           Time (round trips)


                         Example assumes that acks are not delayed               27
                  Congestion Control

   On detecting a packet loss, TCP sender assumes
    that network congestion has occurred

   On detecting packet loss, TCP sender drastically
    reduces the congestion window

   Reducing congestion window reduces amount of data
    that can be sent per RTT
     throughput may decrease



                                                       28
            Congestion Control -- Timeout

   On a timeout, the congestion window is reduced to
    the initial value of 1 MSS

   The slow start threshold is set to half the window size
    before packet loss
     more precisely,
       ssthresh = maximum of min(cwnd,receiver’s advertised
       window)/2 and 2 MSS


   Slow start is initiated


                                                              29
Congestion window (segments)                                 After timeout
                               25
                                                       cwnd = 20
                               20

                               15

                               10
                                        ssthresh = 8                    ssthresh = 10
                               5

                               0
                                                 12

                                                       15

                                                            20

                                                                   22

                                                                          25
                                0

                                    3

                                        6

                                            9




                                              Time (round trips)

                                                                                        30
        Congestion Control - Fast retransmit

   Fast retransmit occurs when multiple (>= 3) dupacks
    come back

   Fast recovery follows fast retransmit

   Different from timeout : slow start follows timeout
     timeout occurs when no more packets are getting across
     fast retransmit occurs when a packet is lost, but latter
     packets get through
    ack clock is still there when fast retransmit occurs
    no need to slow start

                                                                 31
                      Fast Recovery

   ssthresh =
    min(cwnd, receiver’s advertised window)/2
        (at least 2 MSS)
   retransmit the missing segment (fast retransmit)
   cwnd = ssthresh + number of dupacks
   when a new ack comes: cwnd = ssthreh
     enter congestion avoidance



Congestion window cut into half

                                                       32
                                           After fast recovery


                         10
Window size (segments)


                                                               Receiver’s advertized window
                         8
                         6
                         4
                         2
                         0
                              0   2   4      6     8     10 12 14
                                          Time (round trips)


               After fast retransmit and fast recovery window size is
               reduced in half.                                                        33
                     TCP Reno

   Slow-start
   Congestion avoidance
   Fast retransmit
   Fast recovery




                                34
                       Fast Recovery
Fast recovery can result in a timeout with multiple
  losses per RTT
.
 TCP New-Reno [Hoe96]
   stay in fast recovery until all packet losses in window are
       recovered
    can recover 1 packet loss per RTT without
       causing a timeout

   Selective Acknowledgements (SACK)
    [mathis96rfc2018]
     provides information about out-of-order packets received by
       receiver
    can recover multiple packet losses per RTT                   35
Does IEEE 802.11 Work Well in Multi-hop Wireless
                  Network?




          Author: Shugong Xu, Tarek Saadawi
               City University of New York




                                                   36
                             Overview of The Paper


   This paper is about TCP over multi-hop networks, but its also
    about cross-layer interactions
   Conclusion: Cross Layer interactions between 802.11 Protocol,
    routing and TCP can be destructive.

   Experimental Scenario:
      A Static String Topology

             0       1       2      3      4     5      6      7
      TCP as Transport Layer Protocol

   Problems:
      Instability Problem
      Unfairness Problem




                                                                    37
                         Simulation Environment


   Simulator: ns-2 with wireless extensions
   MAC Layer: IEEE 802.11 MAC Distributed Coordination
    function(DCF).
   Transport Layer: TCP connections carrying bulk transfers
    (always have data)
   Network Scenario
      A Static String Network Topology
      Interference range is a little more than two times of the
          communication range


Interference Range                Communication Range




             0       1    2       3       4         5    6         7



                                                                       38
                Instability Problem—Experiment Setup




                1     2      3      4      5
       Source                                   Destination




   A single TCP connection, with node 1 as the source and node
    5 as the destination.

   Three sets of experiments with Maximum Window
    Size(window_) 32, 8, and 4 respectively.




                                                              39
                 Instability Problem—Experiment Result



   When window_=32 or 8, serious oscillation of throughput is observed.
   When window_4, throughput is stable.




                                                                           40
    Instability Problem—Trace Analysis(1)


    Interference Range of Node 2

     RTS                                    Data
1               2                  3    4          5
     CTS                                    Ack




                                                       41
             Instability Problem—Summary

   Collision and exposed terminal problem prevent node 2 from
    receiving RTS from or sending CTS to node 1.

   The random back-off, big data packet, and sending back-to-back
    packets worsen the above problems.

    When window_ = 4, the chance to send back a CTS is greatly
    increased, so the throughput becomes stable.

   After node 1 fails seven times to receive CTS, node 1 believes there
    is a route failure and starts a route discovery.

   Before a route is available, node 1 can not send out a data packet.
    This period usually is long enough to cause a timeout at the TCP
    sender.

   For TCP, timeout triggers Slow Start, which significantly reduces the
    throughput.


                                                                            42
                Unfairness Problem—Experiment Setup




                  Second Session           First Session

                       2    3         4          5         6
              Source         Destination                       Source




   In the first session, data flow from 6 to 4. In the second session,
    data flow from 2 to 3.
   The first session starts at 10.0s. The second session starts at 30.0s.




                                                                         43
                           Unfairness Problem (1)


   The first session has a throughput of about 450kbps from 10s to 30s, and
    0kbps after 30s.
   The second session has a throughput of about 900kbps from 30s to 130s.




                                                                               44
                          Unfairness Problem (2)



   The first session never succeeds to send out packet with sequence number
    2164.




                                                                               45
           Unfairness Problem—Trace Analysis(1)


                              Interfering Range of Node 5

    Data                             RTS             Data
2             3               4                 5              6
    Ack                                             No Route
                                     CTS

                  Interfering Range of Node 4




                                                                   46
           Unfairness Problem—Trace Analysis(2)


                              Interfering Range of Node 5

    Data                             RTS             Data
2             3               4                 5              6
    Ack                                             No Route
                                     CTS

                  Interfering Range of Node 4




                                                                   47
              Unfairness Problem—Summary

   In one-hop TCP connections, the interval between
    packet transmission is larger than that of the multi-
    hop TCP connections, which gives the one-hop
    connection more chances to transmit data.

   Random back-off is actually advantageous to the
    last succeeding host.


   Problem called ―One-hop unfairness problem‖
     Authors argue that since one-hop connection is common
       in a wireless network problem must be addressed




                                                              48
                        Discussion?

   Problems Shown:
     Instability Problem
     Unfairness problem

   Conclusions:
     IEEE 802.11 does not work well in multi-hop wireless
     networks.
    It may be inappropriate to take IEEE 802.11 as the MAC
     layer to simulate routing or transport protocols for multi-
     hop wireless networks.

   Are Cross Layer Solutions needed?

   Maybe a different set of protocols that play nicer
    together?

                                                                   49
                           More discussion

   Rooted in IEEE 802.11 MAC?
      TCP is not designed with wireless networking in mind.
      Timeout  Slow Start

   Interfering range and communication range
      If interfering range is the same as the communication range, the two
       problems presented in this paper will disappear.
      Is the configuration of the interfering range simply an engineering issue?

   Only a simple topology is considered
     What happens if more complex scenarios are considered?
     Different traffic?
     Multiple connections?
     Different spacing between nodes?
     More realistic wireless channel?

   Can you relate to other stuff we have discussed so far?


                                                                                    50
Impact of transmission errors
   on TCP performance




                                51
                    Random Errors

   If number of errors is small, they may be corrected by
    an error correcting code
   Excessive bit errors result in a packet being
    discarded, possibly before it reaches the transport
    layer




                                                         52
Random Errors May Cause Fast Retransmit




       40            39                38           37

                          34                              36




 Example assumes delayed ack - every other packet ack’d

                                                               53
Random Errors May Cause Fast Retransmit




       41            40                39           38

            34                              36




 Example assumes delayed ack - every other packet ack’d

                                                          54
Random Errors May Cause Fast Retransmit




       42          41             40   39

                        36                  36

                                        dupack


 Duplicate acks are not delayed

                                                 55
Random Errors May Cause Fast Retransmit




     43        42        41        40

          36                  36        36

                       Duplicate acks




                                             56
Random Errors May Cause Fast Retransmit




     44      43                42        41

                  36                36        36


                       3 duplicate acks trigger
                       fast retransmit at sender


                                                   57
    Random Errors May Cause Fast Retransmit

   Fast retransmit results in
     retransmission of lost packet
     reduction in congestion window
   Reducing congestion window in response to errors is
    unnecessary
   Reduction in congestion window reduces the
    throughput




                                                      58
    Sometimes Congestion Response May be
       Appropriate in Response to Errors

   On a CDMA channel, errors occur due to interference
    from other user, and due to noise [Karn99pilc]
     Interference due to other users is an indication of
     congestion. If such interference causes transmission errors,
     it is appropriate to reduce congestion window
    If noise causes errors, it is not appropriate to reduce window

   When a channel is in a bad state for a long duration,
    it might be better to let TCP backoff, so that it does
    not unnecessarily attempt retransmissions while the
    channel remains in the bad state
    [Padmanabhan99pilc]

                                                                 59
Impact of Random Errors [Vaidya99]

1600000

1200000

 800000                                       bits/sec

 400000

      0
          4


                   8


                             6


                                     72
        38


                 76


                          53


                                    10
      16


               32


                        65


              1/error rate        13
                                 (in bytes)


     Exponential error model
     2 Mbps wireless full duplex link
     No congestion losses                                60
         Burst Errors May Cause Timeouts

   If wireless link remains unavailable for extended
    duration, a window worth of data may be lost
     driving through a tunnel
     passing a truck
   Timeout results in slow start
   Slow start reduces congestion window to 1 MSS,
    reducing throughput
   Reduction in window in response to errors
    unnecessary
   Multiple packet losses (random) can also result in
    timeout when using TCP-Reno (and to a lesser extent
                                    when using SACK)

                                                          61
           Impact of Transmission Errors

   TCP cannot distinguish between packet losses due to
    congestion and transmission errors
   Unnecessarily reduces congestion window
   Throughput suffers




                                                     62
  Classification of Schemes to
Improve Performance of TCP in
Presence of Transmission Errors




                                  63
     Techniques to Improve TCP Performance
              in Presence of Errors
                 Classification 1

Classification based on nature of actions taken to
improve performance

   Hide error losses from the sender
     if sender is unaware of the packet losses due to errors, it will
       not reduce congestion window


   Let sender know, or determine, cause of packet loss
     if sender knows that a packet loss is due to errors, it will not
       reduce congestion window

                                                                     64
     Techniques to Improve TCP Performance
              in Presence of Errors
                 Classification 2

Classification based on where modifications are needed

   At the sender node only

   At the receiver node only

   At intermediate node(s) only

   Combinations of the above

                                                     65
                        Ideal Behavior

   Ideal TCP behavior: Ideally, the TCP sender should simply
    retransmit a packet lost due to transmission errors, without
    taking any congestion control actions
     Such a TCP referred to as Ideal TCP
     Ideal TCP typically not realizable

   Ideal network behavior: Transmission errors should be hidden
    from the sender -- the errors should be recovered transparently
    and efficiently

   Proposed schemes attempt to approximate one of the above
    two ideals


                                                                   66
     Selected Schemes to
Improve Performance of TCP in
Presence of Transmission Errors




                                  67
                  Various Schemes

   Link level mechanisms
   Split connection approach
   TCP-Aware link layer
   TCP-Unaware approximation of TCP-aware link layer
   Explicit notification
   Receiver-based discrimination
   Sender-based discrimination

For a brief overview, see [Dawkins99,Montenegro99]


                                                     68
Link Level Mechanisms




                        69
              Link Layer Mechanisms
              Forward Error Correction


   Forward Error Correction (FEC) [Lin83] can be use
    to correct small number of errors

   Correctable errors hidden from the TCP sender

   FEC incurs overhead even when errors do not occur
     Adaptive FEC schemes [Eckhardt98] can reduce the
      overhead by choosing appropriate FEC dynamically




                                                         70
               Link Layer Mechanisms
             Link Level Retransmissions


   Link level retransmission schemes retransmit a
    packet at the link layer, if errors are detected

   Retransmission overhead incurred only if errors occur
     unlike FEC overhead




                                                       71
               Link Layer Mechanisms

In general

   Use FEC to correct a small number of errors

   Use link level retransmission when FEC capability is
    exceeded




                                                           72
            Link Level Retransmissions
                                              Link layer state


                    TCP connection

application          application               application
transport            transport                 transport
network              network                   network
                                       rxmt
link                 link                      link
physical             physical                  physical




                                   wireless
                                                                 73
              Link Level Retransmissions
                        Issues
   How many times to retransmit at the link level before
    giving up?
     Finite bound -- semi-reliable link layer
     No bound -- reliable link layer

   What triggers link level retransmissions?
    Link layer timeout mechanism
    Link level acks (negative acks, dupacks, …)
    Other mechanisms (e.g., Snoop, as discussed later)

   How much time is required for a link layer
    retransmission?
     Small fraction of end-to-end TCP RTT
     Large fraction/multiple of end-to-end TCP RTT
     Interaction of timers at link level and TCP?        74
              Link Level Retransmissions
                        Issues

   Should the link layer deliver packets as they arrive, or
    deliver them in-order?
     Link layer may need to buffer packets and reorder if
       necessary so as to deliver packets in-order




                                                          75
             Link Level Retransmissions
                       Issues

   Retransmissions can cause head-of-the-line blocking

                                      Receiver 1



           Base station               Receiver 2


   Although link to receiver 1 may be in a bad state, the
    link to receiver 2 may be in a good state
   Retransmissions to receiver 1 are lost, and also block
    a packet from being sent to receiver 2


                                                        76
              Link Level Retransmissions
                    (Early Studies)

   The sender’s Retransmission Timeout (RTO) is a
    function of measured RTT (round-trip times)
     Link level retransmits increase RTT, therefore, RTO

   If errors not frequent, RTO will not account for RTT
    variations due to link level retransmissions
     When errors occur, the sender may timeout & retransmit
     before link level retransmission is successful
    Sender and link layer both retransmit
    Duplicate retransmissions (interference) waste wireless
     bandwidth
    Timeouts also result in reduced congestion window
                                                               77
RTO Variations




                 Wireless
                 Packet loss
                 RTT sample
                 RTO




                       78
                A More Accurate Picture


   With large RTO granularity, interference is unlikely,
    if time required for link-level retransmission is small
    compared to TCP RTO [Balakrishnan96Sigcomm]
      Standard TCP RTO granularity is often large
      Minimum RTO (2*granularity) is large enough to allow a
     small number of link level retransmissions, if link level RTT is
     relatively small
    Interference due to timeout not a significant issue when
     wireless RTT small, and RTO granularity large [Eckhardt98]




                                                                   79
              Link Level Retransmissions
                A More Accurate Picture

   Frequent errors increase RTO significantly on slow
    wireless links
     RTT on slow links large, retransmissions result in large
     variance, pushing RTO up
    Likelihood of interference between link layer and TCP
     retransmissions smaller
    But congestion response will be delayed due to larger RTO
    When wireless losses do cause timeout, much time wasted




                                                                 80
    Large TCP Retransmission Timeout Intervals


   Good for reducing interference with link level
    retransmits

   Bad for recovery from congestion losses

   Need a timeout mechanism that responds
    appropriately for both types of losses
     Open problem



                                                     81
             Link Level Retransmissions
   Selective repeat protocols can deliver packets out of
    order

   Significantly out-of-order delivery can trigger TCP fast
    retransmit
     Redundant retransmission from TCP sender
     Reduction in congestion window

   Example: Receipt of packets
                                             Lost packet
    3,4,5 triggers dupacks
                                             Retransmitted packet



                        6   2    5   4   3      2   1         82
             Link Level Retransmissions
                   In-order delivery


   To avoid unnecessary fast retransmit, link layer using
    retransmission should attempt to deliver packets
    ―almost in-order‖



                        6   5   4   3   2   2   1




                        6   5   2   4   3   2   1
                                                         83
           Adaptive Link Layer Strategies
           [Lettieri98,Eckhardt98,Zorzi97]


Adaptive protocols attempt to dynamically choose:

   FEC code

   retransmission limit

   frame size




                                                    84
Link Layer Retransmissions [Vaidya99]

   2000000
   1600000
                                               base TCP
   1200000
    800000                                     Link layer
                                               retransmission
    400000
          0
               16384

                       32768

                               65536

                                       1E+05
                                                    20 ms       1 ms
              1/error rate       (in bytes)
                                                   10 Mbps 2 Mbps

2 Mbps wireless duplex link with 1 ms delay
Exponential error model
No congestion losses                                                   85
           Link Layer Schemes: Summary

When is a reliable link layer beneficial to TCP
 performance?

   if it provides almost in-order delivery

and

   TCP retransmission timeout large enough to tolerate
    additional delays due to link level retransmits



                                                          86
         Link Layer Schemes: Classification


   Hide wireless losses from TCP sender

   Link layer modifications needed at both ends of
    wireless link
     TCP need not be modified




                                                      87
                  Various Schemes

   Link level mechanisms
   Split connection approach
   TCP-Aware link layer
   TCP-Unaware approximation of TCP-aware link layer
   Explicit notification
   Receiver-based discrimination
   Sender-based discrimination




                                                    88
Split Connection Approach




                            89
               Split Connection Approach


   End-to-end TCP connection is broken into one
    connection on the wired part of route and one over
    wireless part of the route

   A single TCP connection split into two TCP
    connections
     if wireless link is not last on route, then more than two TCP
       connections may be needed




                                                                  90
                 Split Connection Approach


   Connection between wireless host MH and fixed host
    FH goes through base station BS

   FH-MH = FH-BS            +     BS-MH




          FH            BS             MH

    Fixed Host      Base Station      Mobile Host    91
                 Split Connection Approach


   Split connection results in independent flow control
    for the two parts

   Flow/error control protocols, packet size, time-outs,
    may be different for each part




          FH            BS           MH

    Fixed Host      Base Station   Mobile Host              92
            Split Connection Approach

                                         Per-TCP connection state

       TCP connection          TCP connection


application             application              application
                                         rxmt
transport               transport                transport
network                 network                  network
link                    link                     link
physical                physical                 physical




                                      wireless                 93
             Split Connection Approach
          Indirect TCP [Bakre95,Bakre97]


   FH - BS connection : Standard TCP
   BS - MH connection : Standard TCP




                                           94
          Split Connection Approach
Selective Repeat Protocol (SRP) [Yavatkar94]


   FH - BS connection : standard TCP
   BS - FH connection : selective repeat protocol on top
    of UDP

   Performance better than Indirect-TCP (I-TCP),
    because wireless portion of the connection can be
    tuned to wireless behavior




                                                        95
    Split Connection Approach : Other Variations

   Asymmetric transport protocol (Mobile-TCP)
    [Haas97icc]

    Low overhead protocol at wireless hosts, and higher
    overhead protocol at wired hosts
     smaller headers used on wireless hop (header compression)
     simpler flow control - on/off for MH to BS transfer
     MH only does error detection, BS does error correction too
     No congestion control over wireless hop



                                                              96
     Split Connection Approach : Classification


   Hides transmission errors from sender
   Primary responsibility at base station
   If specialized transport protocol used on wireless,
    then wireless host also needs modification




                                                          97
     Split Connection Approach : Advantages
   BS-MH connection can be optimized independent of FH-BS
    connection
     Different flow / error control on the two connections

   Local recovery of errors
     Faster recovery due to relatively shorter RTT on wireless link

   Good performance achievable using appropriate BS-MH
    protocol
     Standard TCP on BS-MH performs poorly when multiple packet
      losses occur per window (timeouts can occur on the BS-MH
      connection, stalling during the timeout interval)
     Selective acks improve performance for such cases



                                                                       98
    Split Connection Approach : Disadvantages

   End-to-end semantics violated
     ack may be delivered to sender, before data delivered to the
     receiver
    May not be a problem for applications that do not rely on
     TCP for the end-to-end semantics



                               39

                               40
                                          38          37
FH                              BS                               MH
                40                                         36

                                                                  99
    Split Connection Approach : Disadvantages

   BS retains hard state
    BS failure can result in loss of data (unreliability)
     If BS fails, packet 40 will be lost
     Because it is ack’d to sender, the sender does not buffer 40



                               39

                               40
                                          38          37
FH                               BS                             MH
                40                                         36

                                                                 100
    Split Connection Approach : Disadvantages

   BS retains hard state
    Hand-off latency increases due to state transfer
     Data that has been ack’d to sender, must be moved to new
       base station
                            39
                            40       38    37
         FH                   BS                  MH
                  40                         36



                                   39
                                   40             MH      Hand-off


                                                             101
                       New base station
    Split Connection Approach : Disadvantages


   Buffer space needed at BS for each TCP connection
     BS buffers tend to get full, when wireless link slower (one
       window worth of data on wired connection could be stored at
       the base station, for each split connection)


   Window on BS-MH connection reduced in response
    to errors
     may not be an issue for wireless links with small delay-bw
       product



                                                                102
    Split Connection Approach : Disadvantages


   Extra copying of data at BS
     copying from FH-BS socket buffer to BS-MH socket buffer
     increases end-to-end latency

   May not be useful if data and acks traverse different
    paths (both do not go through the base station)
     Example: data on a satellite wireless hop, acks on a dial-up
       channel
                                                       data

FH                                                             MH


                                                                103
                                                 ack
                  Various Schemes

   Link layer mechanisms
   Split connection approach
   TCP-Aware link layer
   TCP-Unaware approximation of TCP-aware link layer
   Explicit notification
   Receiver-based discrimination
   Sender-based discrimination




                                                   104
TCP-Aware Link Layer




                       105
        Snoop Protocol [Balakrishnan95acm]


   Retains local recovery of Split Connection approach
    and link level retransmission schemes

   Improves on split connection
     end-to-end semantics retained
     soft state at base station, instead of hard state




                                                          106
              Snoop Protocol

                                 Per TCP-connection state

                TCP connection

application      application              application
transport        transport                transport
network          network                  network
                                   rxmt
link             link                     link
physical         physical                 physical



       FH               BS                       MH
                               wireless
                                                        107
                   Snoop Protocol

   Buffers data packets at the base station BS
     to allow link layer retransmission
   When dupacks received by BS from MH, retransmit
    on wireless link, if packet present in buffer
   Prevents fast retransmit at TCP sender FH by
    dropping the dupacks at BS




         FH         BS           MH


                                                      108
                      Snoop : Example
                                   35      TCP state
                                          maintained at
                                   36
                                           link layer
                                   37

                                   38

           40            39                38           37
FH                                 BS                              MH
                              34                              36




     Example assumes delayed ack - every other packet ack’d

                                                                    109
          Snoop : Example
                35    39

                36

                37

                38

41         40         39         38

     34                     36




                                      110
               Snoop : Example

                            37   40

                            38

                            39

      42          41             40   39

                       36                  36

                                       dupack


Duplicate acks are not delayed

                                                111
          Snoop : Example

                37    40

                38    41

                39

43         42          41        40

     36                     36        36

                     Duplicate acks




                                           112
                    Snoop : Example

                                   37     40

                                   38     41

                                   39     42

         44            43                     37        41
FH                                 BS                             MH
                                                   36        36
                                    Discard
                                    dupack

 Dupack triggers retransmission 36
  of packet 37 from base station

  BS needs to be TCP-aware to
be able to interpret TCP headers                                   113
     Snoop : Example

           37    40         43

           38    41

           39    42

45    44          42         37

                       36         36




            36


            36
                                       114
                      Snoop : Example

                            37       40        43

                            38       41        44

                            39       42

            46         45            43         42

                                          36         41


TCP sender does not
  fast retransmit            36 36


                             36
                                                          115
                      Snoop : Example

                            37       40        43

                            38       41        44

                            39       42        45

            47         46            44         43

                                          41


TCP sender does not
  fast retransmit            36 36


                             36 36
                                                     116
          Snoop : Example

                42        45

                43        46

                44


     48    47                  45   44
FH                   BS                       MH
                41                       43




                     36 36


                     36 36
                                               117
           Snoop [Balakrishnan95acm]

           2000000
           1600000
bits/sec

           1200000                                                base TCP
            800000                                                Snoop

            400000
                 0
                     16K
                           32K
                                 64K
                                       128K
                                                256K
                                                       no error
                     1/error rate             (in bytes)




                     2 Mbps Wireless link
                                                                             118
                      Snoop Protocol
                      When Beneficial?

   Snoop prevents fast retransmit from sender despite
    transmission errors, and out-of-order delivery on the
    wireless link

   OOO delivery causes fast retransmit only if it results
    in at least 3 dupacks

   If wireless link level delay-bandwidth product is less
    than 4 packets, a simple (TCP-unaware) link level
    retransmission scheme can suffice
     Since delay-bandwidth product is small, the retransmission
       scheme can deliver the lost packet without resulting in 3
       dupacks from the TCP receiver
                                                                   119
           Snoop Protocol : Classification


   Hides wireless losses from the sender

   Requires modification to only BS (network-centric
    approach)




                                                        120
               Snoop Protocol : Advantages

   High throughput can be achieved
     performance further improved using selective acks

   Local recovery from wireless losses

   Fast retransmit not triggered at sender despite out-of-order link
    layer delivery

   End-to-end semantics retained

   Soft state at base station
     loss of the soft state affects performance, but not correctness


                                                                        121
          Snoop Protocol : Disadvantages


   Link layer at base station needs to be TCP-aware

   Not useful if TCP headers are encrypted (IPsec)

   Cannot be used if TCP data and TCP acks traverse
    different paths (both do not go through the base
    station)




                                                       122
              WTCP Protocol [Ratnam98]

   Snoop hides wireless losses from the sender
   But sender’s RTT estimates may be larger in
    presence of errors
   Larger RTO results in slower response for congestion
    losses




         FH           BS           MH


                                                      123
                    WTCP Protocol

   WTCP performs local recovery, similar to Snoop

   In addition, WTCP uses the timestamp option to
    estimate RTT
   The base station adds base station residence time to
    the timestamp when processing an ack received from
    the wireless host
   Sender’s RTT estimate not affected by
    retransmissions on wireless link
         FH           BS           MH


                                                      124
                WTCP Example




                3                       3
   FH                       BS                  MH
                    4                       3




Numbers in this figure are timestamps

Base station residence time is 1 unit

                                                     125
                 WTCP : Disadvantages

   Requires use of the timestamp option
   May be useful only if retransmission times are large
     link stays in bad state for a long time
     link frequently enters a bad state
     link delay large

   WTCP does not account for congestion on wireless
    hop
     assumes that all delay at base station is due to queuing and
     retransmissions
    will not work for shared wireless LAN, where delays also
     incurred due to contention with other transmitters
                                                                126
                  Various Schemes

   Link layer mechanisms
   Split connection approach
   TCP-Aware link layer
   TCP-Unaware approximation of TCP-aware link layer
   Explicit notification
   Receiver-based discrimination
   Sender-based discrimination




                                                   127
TCP-Unaware Approximation of
   TCP-Aware Link Layer




                               128
Delayed Dupacks Protocol [Mehta98,Vaidya99]

   Attempts to imitate Snoop, without making the base
    station TCP-aware

   Snoop implements two features at the base station
     link layer retransmission
     reducing interference between TCP and link layer
       retransmissions (by dropping dupacks)


   Delayed Dupacks implements the same two features
     at BS : link layer retransmission
     at MH : reducing interference between TCP and link layer
       retransmissions (by delaying dupacks)
                                                            129
            Delayed Dupacks Protocol

                                             Link layer state
                   TCP connection

application         application                application
transport           transport                  transport
network             network                    network
                                      rxmt
link                link                       link
physical            physical                   physical




                                  wireless
                                                                130
               Delayed Dupacks Protocol
   Link layer retransmission scheme at the base station

   Link layer delivers packets out-of-order when
    transmission errors occur

    Why may a link layer deliver packets out-of-order?
        • Only an issue when the link layer does not use stop-and-
          go protocol

    With OOO link layer delivery, loss of a packet from one flow
      does not block delivery of packets from another flow

    If in-order delivery is enforced, when retransmission for a
      packet is being performed, packets from other other flows
      may also be blocked from being delivered to the upper layer
                                                                   131
              Delayed Dupacks Protocol


   TCP receiver delays dupacks (third and subsequent)
    for interval D, when out-of-order packets received

   Dupack delay intended to give link level retransmit
    time to succeed

   Benefit: Delayed dupacks can result in recovery from
    a transmission loss without triggering a response
    from the TCP sender

   Disadvantage: Recovery from congestion losses
    delayed
                                                          132
              Delayed Dupacks Protocol


   Delayed dupacks released after interval D, if missing
    packet not received by then

   Link layer maintains state to allow retransmission
   Link layer state is not TCP-specific




                                                         133
         Delayed Dupacks : Example
                              35
                                    Link layer state
                              36

                              37

                              38

       40           39                38           37

                         34                              36




Example assumes delayed ack - every other packet ack’d

Link layer acks are not shown                                 134
          Delayed Dupacks : Example
                          36

                          37

                          38

                          39

        41          40              39         38
                           BS
             34                          36




35   Removed from BS link layer buffer on receipt of a
     link layer ack (LL acks not shown in figure)
                                                         135
        Delayed Dupacks : Example

                            37   40

                            38

                            39

      42          41             40   39

                       36                  36

                                       dupack


Duplicate acks are not delayed

                                                136
     Delayed Dupacks : Example

                    37     40

                    38     41

                    39

   43          42           41            40

        36                       36            36

Original ack             Duplicate acks




                                                    137
   Delayed Dupacks : Example

                       37

                       39       41

                       40       42

  44         43                 37         41

                  36                 36
                                                  36
               dupack            dupacks
                                                Delayed
                                                dupack
Base station forwards dupacks


                                                  138
 Delayed Dupacks : Example

                    37   42

                    40   43

                    41

45        44             42     37

     36        36
                                        36

dupacks                                 36


                              Delayed dupacks

                                         139
              Delayed Dupacks : Example

                           37      43

                           41      44

                           42

            46        45            43         42

                 36                                  41


                             Delayed dupacks are
                               discarded if lost
TCP sender does not         packet received before
  fast retransmit              delay D expires
                                                          140
       Delayed Dupacks [Vaidya99]
   2000000
   1600000
                                               base TCP
   1200000
    800000                                     dupack delay
    400000                                     80ms + LL
                                               Retransmit
          0                                    Only LL
               16384

                       32768

                               65536

                                       1E+05
                                               retransmit



              1/error rate       (in bytes)
                                                    20 ms     20 ms

                                                  10 Mbps 2 Mbps

2 Mbps wireless duplex link with 20 ms delay
No congestion losses
                                                                 141
  Delayed Dupacks [Vaidya99]
160000
140000
120000                                   base TCP
100000
 80000
 60000                                   dupack delay
 40000                                   80ms + LL
 20000                                   Retransmit
     0                                   Only LL
         16384


                 32768


                         65536


                                 1E+05
                                         retransmit



         1/error rate     (in bytes)          20 ms     20 ms

                                            10 Mbps 2 Mbps


     5% packet loss due to congestion
                                                           142
      Delayed Dupacks Scheme : Advantages


   Link layer need not be TCP-aware

   Can be used even if TCP headers are encrypted

   Works well for relatively small wireless RTT
    (compared to end-to-end RTT)
         relatively small delay D sufficient in such cases




                                                              143
    Delayed Dupacks Scheme : Disadvantages


   Right value of dupack delay D dependent on the
    wireless link properties

   Mechanisms to automatically choose D needed

   Delays dupacks for congestion losses too, delaying
    congestion loss recovery




                                                         144
                  Various Schemes

   Link-layer retransmissions
   Split connection approach
   TCP-Aware link layer
   TCP-Unaware approximation of TCP-aware link layer
   Explicit notification
   Receiver-based discrimination
   Sender-based discrimination




                                                   145
Explicit Notification




                        146
            Explicit Notification Schemes
                General Philosophy

   Approximate Ideal TCP behavior: Ideally, the TCP
    sender should simply retransmit a packet lost due to
    transmission errors, without taking any congestion
    control actions

   A wireless node somehow determines that packets
    are lost due to errors and informs the sender using
    an explicit notification

   Sender, on receiving the notification, does not reduce
    congestion window, but retransmits lost packet

                                                          147
            Explicit Notification Schemes


   Motivated by the Explicit Congestion Notification
    (ECN) proposals [Floyd94]



Variations proposed in literature differ in

   who sends explicit notification
   how they know to send the explicit notification
   what the sender does on receiving the notification

                                                         148
          Explicit Notification
Space Communication Protocol Standards-
     Transport Protocol (SCPS-TP)

  Satellite

              wireless




                             TCP destinations
         Ground station




                                           149
    Space Communication Protocol Standards-
         Transport Protocol (SCPS-TP)
   The receiving ground station keeps track of how many packets
    with errors are received (their checksums failed)
   When the error rate exceeds a threshold, the ground station
    sends corruption experienced messages to destinations of
    recent error-free TCP packets
     destinations are cached
   The TCP destinations tag acks with corruption-experienced bit
   TCP sender, after receiving an ack with corruption-experienced
    bit, does not back off until it receives an ack without that bit
    (even if timeout or fast retransmit occurs)




                                                                  150
     Explicit Loss Notification [Balakrishnan98]
            when MH is the TCP sender
   Wireless link first on the path from sender to receiver
   The base station keeps track of holes in the packet
    sequence received from the sender
   When a dupack is received from the receiver, the
    base station compares the dupack sequence number
    with the recorded holes
     if there is a match, an ELN bit is set in the dupack
   When sender receives dupack with ELN set, it
    retransmits packet, but does not reduce congestion
    window                    Record
                           hole at 2
            4   3    2 1                   4   3   1
    MH                          BS                     FH
          wireless    1  1                       1 1     151
                               Dupack with ELN set
     Explicit Bad State Notification [Bakshi97]
              when MH is TCP receiver


   Base station attempts to deliver packets to the MH
    using a link layer retransmission scheme

   If packet cannot be delivered using a small number of
    retransmissions, BS sends a Explicit Bad State
    Notification (EBSN) message to TCP sender

   When TCP sender receives EBSN, it resets its timer
    timeout delayed, when wireless channel in bad state

                                                         152
                Partial Ack Protocols
                 [Cobb95][Biaz97]
   Send two types of acknowledgements
   A partial acknowledgement informs the sender that a
    packet was received by an intermediate host
    (typically, base station)
   Normal TCP cumulative ack needed by the sender
    for reliability purposes




                                                      153
                 Partial Ack Protocols

   When a packet for which a partial ack is received is
    detected to be lost, the sender does not reduce its
    congestion window
     loss assumed to be due to wireless errors

                                         37


                         37                       36


                       Partial ack        Cumulative ack




                                                           154
                       Variations

   Base station may or may not locally buffer and
    retransmit lost packets
   Partial ack for all packets or a subset ?


                                        37


                         37                      36


                      Partial ack        Cumulative ack




                                                          155
      Explicit Loss Notification [Biaz99thesis]
             when MH is TCP receiver

   Attempts to approximate hypothetical ELN proposed
    in [Balakrishnan96] for the case when MH is receiver

   Caches TCP sequence numbers at base station,
    similar to Snoop. But does not cache data packets,
    unlike Snoop.

   Duplicate acks are tagged with ELN bit before being
    forwarded to sender if sequence number for the lost
    packet is cached at the base station

   Sender takes appropriate action on receiving ELN
                                                         156
Explicit Loss Notification [Biaz99thesis]
       when MH is TCP receiver

   Sequence numbers      39
cached at base station
                         38

                         37
                                39   38   37

 36      37         37


              Dupack with ELN




                                               157
                  Various Schemes

   Link-layer retransmissions
   Split connection approach
   TCP-Aware link layer
   TCP-Unaware approximation of TCP-aware link layer
   Explicit notification
   Receiver-based discrimination
   Sender-based discrimination




                                                   158
Receiver-Based Discrimination Scheme




                                       159
      Receiver-Based Scheme [Biaz98Asset]


   MH is TCP receiver
   Receiver uses a heuristic to guess cause of packet
    loss
   When receiver believes that packet loss is due to
    errors, it sends a notification to the TCP sender
   TCP sender, on receiving the notification, retransmits
    the lost packet, but does not reduce congestion
    window



                                                        160
               Receiver-Based Scheme

   Packet loss due to congestion
          12   11   10

    FH                   BS                 MH




                                 T

                                12     10
     FH                  BS                 MH


                        11
                     Congestion loss             161
               Receiver-Based Scheme

   Packet loss due to transmission error
          12   11   10

    FH                   BS                      MH



                               2T

                              12       11        10
                                    Error loss
     FH                  BS                      MH



                                                      162
              Receiver-Based Scheme


   Receiver uses the inter-arrival time between
    consecutively received packets to guess the cause of
    a packet loss

   On determining a packet loss as being due to errors,
    the receiver may
     tag corresponding dupacks with an ELN bit, or
     send an explicit notification to sender



                                                       163
       Receiver-Based Scheme
   Diagnostic Accuracy [Biaz99Asset]




Congestion losses         Error losses
                                         164
     Receiver-Based Scheme : Disadvantages

   Limited applicability

   The slowest link on the path must be the last wireless
    hop
     to ensure some queuing will occur at the base station

   The queueing delays for all packets (at the base
    station) should be somewhat uniform
     multiple connections on the link will make inter-packet
       delays variable



                                                                165
      Receiver-Based Scheme : Advantages


   Can be implemented without modifying the base
    station (an ―end-to-end‖ scheme)

   May be used despite encryption, or if data & acks
    traverse different paths




                                                        166
                  Various Schemes

   Link-layer retransmissions
   Split connection approach
   TCP-Aware link layer
   TCP-Unaware approximation of TCP-aware link layer
   Explicit notification
   Receiver-based discrimination
   Sender-based discrimination




                                                   167
Sender-Based Discrimination Scheme




                                     168
       Sender-Based Discrimination Scheme
           [Biaz98ic3n,Biaz99techrep]


   Sender can attempt to determine cause of a packet
    loss

   If packet loss determined to be due to errors, do not
    reduce congestion window

   Sender can only use statistics based on round-trip
    times, window sizes, and loss pattern
     unless network provides more information (example: explicit
       loss notification)

                                                               169
      Heuristics for Congestion Avoidance



throughput
                    cliff
        knee
                            RTT




             load                 load


                                            170
        Heuristics for Congestion Avoidance


   Define condition C as a function of congestion
    window size and observed RTTs

   Condition C evaluated when a new RTT is calculated
     condition C typically evaluates to 2 or 3 possible values
     for now assume 2 values: TRUE or FALSE

   If (C == True) reduce congestion window

   Several proposals for condition C

                                                             171
        Heuristics for Congestion Avoidance
                  Some proposals


   Normalized Delay Gradient [jain89]

    r = [RTT(i)-RTT(i-1)] / [RTT(i)+RTT(i-1)]

    w = [W(i)-W(i-1)] / [W(i)+W(i-1)]



    Condition C = (r/w > 0)


                                                172
        Heuristics for Congestion Avoidance
                  Some proposals


   Normalized Throughput Gradient [Wang91]

    Throughput gradient
             TG(i) = [T(i) - T(i-1) ] / [ W(i)-W(i-1)]

    Normalized Throughout Gradient
              NTG = TG(i) / TG(1)

    Condition C = (NTG < 0.5)

                                                         173
        Heuristics for Congestion Avoidance
                  Some proposals


   TCP Vegas [Brakmo94]

    expected throughput ET = W(i) / RTTmin

    actual throughput   AT = W(i) / RTT(i)

    Condition C = ( ET-AT > beta)




                                              174
               Sender-Based Heuristics


   Record latest value evaluated for condition C

   When a packet loss is detected

    if last evaluation of C is TRUE, assume packet loss is due
     to congestion
    else assume that packet loss is due to transmission errors

   If packet loss determined to be due to errors, do not
    reduce congestion window

                                                                  175
    Sender-Based Schemes
Diagnostic Accuracy [Biaz99ic3n]




                                   176
    Sender-Based Schemes
Diagnostic Accuracy [Biaz99ic3n]




                                   177
     Sender-Based Heuristics : Disadvantage


   Does not work quite well enough as yet !!

Reason

   Statistics collected by the sender garbled by other
    traffic on the network

   Not much correlation between observed short-term
    statistics, and onset of congestion

                                                          178
      Sender-Based Heuristics : Advantages


   Only sender needs to be modified



Needs further investigation to develop better heuristics
  investigate longer-term heuristics




                                                       179
Why do Statistical Technique Perform Poorly?
   The techniques we evaluated use simple statistics on
    RTT and window size W to draw conclusions about
    state of the network
   Unfortunately, correlation between RTT and W is
    often weak
           Fraction of TCP
            connections




                             Coefficient of correlation (RTT,W)   180
                Statistical Techniques
                     Future Work


   Other statistical measures ?

   Mechanisms that achieve good TCP throughput
    despite not-too-good diagnostic accuracy




                                                  181
     TCP in Presence of Transmission Errors
                  Summary


   Many techniques have been proposed, and several
    approaches perform well in many environments


   Recommendation: Prefer end-to-end techniques
     End-to-end techniques are those which
     do not require TCP-Specific help from lower layers
    Lower layers may help improve TCP performance without
     taking TCP-specific actions. Examples:
       • Semi-reliable link level retransmission schemes
       • Explicit notification
                                                             182