Special Topics on Wireless Adhoc Networks

1
Special Topics on Wireless Ad-hoc Networks
Lecture 6 Wireless Internet, TCP on Wireless
Network

• University of Tehran
• Dept. of EE and Computer Engineering
• By
• Dr. Nasser Yazdani

2
Covered topics

• How to build a global wireless network?
• Some considerations
• Mobility
• Transport layer
• References
• Chapter 4 of the book
• Alex C. Snoeren and Hari Balakrishnan, An
  End-to-End Approach to Host Mobility
• Hari Balakrishnan, Venkata N. Padmanabhan,
  Srinivasan Seshan and Randy H. Katz, A
  Comparison of Mechanisms for Improving TCP
  Performance over Wireless Links

3
Outline

• Layer 3 consideration Host Mobility
• TCP basics
• Layer 4 consideration
• Impact of transmission errors on TCP performance
• Timeout
• Approaches to improve TCP performance
• Approaches to improve application performance

4
TCP-level mobility support

• Use dynamic DNS for initial name lookup
• If name changes during a connect, use TCP migrate
  option
• If name changes between DNS lookup and TCP
  connection, then do another DNS lookup

5
TCP-level advantages and disadvantages

• No tunneling
• No need to modify IP layer
• Possibly more input from applications
• Requires secure dynamic DNS
• Scalability issue not entirely dismissable
• What if both endpoints are mobile?
• Need to modify multiple transport layers
• More transport-level changes required than
  IP-level additions
• Security issues more severe (1st paragraph of
  Section 5 is false)
• Requires application-level changes for DNS retries

6
Overall TCP-level questions

• Are IP address changes a routing responsibility
  or an application responsibility?
• Is this really end-to-end?
• With dynamic DNS requirements, application-level
  changes, and TCP changes, why not just do DNS
  retry every time a connection fails?

7
fast handoffs

• Three components
• Detection time
• Link layer handoffs
• Layer 3 handoffs
• The third one can be reduced.
• Pre-registration handoff while attached to the
  old one
• Post-registration handoff continue to use the
  old FA

8
Outline

• Layer 3 consideration Host Mobility
• TCP basics
• Layer 4 consideration
• Impact of transmission errors on TCP performance
• Timeout
• Approaches to improve TCP performance
• Approaches to improve application performance

9
TCP Basics

• Reliable ordered delivery
• 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
• TCP window flow control is self-clocking
• New data sent when old data is ackd
• Helps maintain equilibrium
• Implements congestion avoidance and control

10
Window Based Flow Control

• TCP sender sets retransmission timer for only one
  packet. If ack for the timed packet is not
  received the packet is assumed to be lost
• RTO dynamically calculated
• Congestion window size bounds the amount of data
  that can be sent per round-trip time
• Throughput lt W / RTT

11
Retransmission Timeout (RTO)

• RTO mean 4 mean deviation
• Standard deviation s s average of (sample
  mean)
• Mean deviation d average of sample mean
• Mean deviation easier to calculate than standard
  deviation
• Mean deviation is more conservative d gt s
• Large variations in the RTT increase the
  deviation, leading to larger RTO

2
2
12
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
• Double RTO on each timeout (Exponential backoff)

13
Fast Retransmit Mechanism

• Timeouts can take too long
• Fast retransmit in case of packet loss
• How to identify packet loss? Duplicated Acks.
• Dupacks may be generated due to
• packet loss, or
• out-of-order packet delivery
• Assumes packet loss in case of three consecutive
  dupacks

3 dupacks are generated if a packet 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
14
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

15
Congestion Avoidance

• On each new ack, increase cwnd by 1/cwnd packets
• cwnd increases linearly with time during
  congestion avoidance

Example assumes that acks are not delayed
16
Congestion Control

• TCP assume packet loss is due to congestion
• On packet loss, reduces the congestion window and
  consequently amount of data sent per RTT
• throughput may decrease

17
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,receivers
  advertised window)/2 and 2 MSS
• Slow start is initiated

18
After timeout
cwnd 20
ssthresh 10
ssthresh 8
19
Fast recovery

• Fast retransmit occurs when multiple (gt 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

20
Fast Recovery

• ssthresh min(cwnd, receivers 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

21
After fast recovery
Receivers advertized window
After fast retransmit and fast recovery window
size is reduced in half.
22
Fast Recovery

• Fast recovery can result in a timeout with
  multiple losses per RTT
• TCP New-Reno
• 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

23
Outline

• Host Mobility
• TCP basics
• Impact of transmission errors on TCP performance
• Approaches to improve TCP performance
• Classification
• Discussion of selected approaches

24
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,
• Dups Acks cause Fast retransmit which 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

25
Congestion Response to Errors

• On a CDMA channel, errors occur due to
  interference from other user, and noise
• 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.

26
Burst Errors May Cause Timeouts

• If a wireless link remains unavailable for
  extended duration,
• a window worth of data may be lost
• Timeout might occur
• Timeout results in slow start
• Slow start reduces congestion window to 1 MSS,
  which reduces throughput
• Unfortunately, TCP cannot distinguish between
  packet losses due to congestion and transmission
  errors

27
Outline

• Host Mobility
• TCP basics
• Impact of transmission errors on TCP performance
• Approaches to improve TCP performance

28
Improving TCP

• How to improve performance?
• Hide error losses from the sender
• Not reduce congestion window
• Let sender determine cause of packet loss
• if it is due to errors, it will not reduce
  congestion window.
• where modifications are needed?
• At the sender node
• At the receiver node
• At intermediate node(s)
• Combinations of the above

29
Ideal Behavior

• Ideal TCP behavior TCP sender should retransmit
  a packet lost due to transmission errors, without
  taking any congestion control actions
• 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

30
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

31
Link Layer Mechanisms

• Forward Error Correction (FEC)
• FEC incurs overhead even when errors do not occur
• Adaptive FEC schemes can reduce the overhead by
  choosing appropriate FEC dynamically
• Link level retransmission in case of error in the
  link layer.
• unlike FEC overhead
• FEC to correct a small number of errors
• link level retransmission when FEC capability is
  exceeded

32
Link Level Retransmissions
Link layer state
TCP connection
33
Link Level RetransmissionsIssues

• 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

34
Link Level RetransmissionsIssues

• 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

35
Link Level RetransmissionsIssues

• Retransmissions can cause head-of-the-line
  blocking
• Receiver 1 may be in a bad state, retransmissions
  to receiver 1 are lost, and also block a packet
  from being sent to receiver 2

Receiver 1
Receiver 2
Base station
36
Link Level RetransmissionsIssues

• Retransmissions can cause congestion losses
• Retransmit a packet at the front of the queue
  reduces the available bandwidth, potentially
  making the queue at base station longer
• If the queue gets full, packets may be lost,
  indicating congestion to the sender
• Is this desirable or not ?

Receiver 1
Receiver 2
Base station
37
Link Level Retransmissions

• The senders 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

38
RTO Variations
Wireless
Packet loss
RTT sample
RTO
39
A More Accurate Picture

• With large RTO granularity, interference is
  unlikely, if time required for link-level
  retransmission is small compared to TCP RTO
• Standard TCP RTO granularity is often large
• Minimum RTO (2granularity) 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.

40
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

41
A More Accurate Picture

• Timeout interval may actually be larger than RTO
• Retransmission timer reset on an ack
• If the ackd packet and next packet were
  transmitted in a burst, next packet gets an
  additional RTT before the timer will go off

data
ack
1
2
Timeout RTO
Reset, Timeout RTO
Effectively, Timeout RTT of packet 1 RTO
42
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

43
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
• 3,4,5 triggers dupacks

Lost packet
Retransmitted packet
6
2
5
2
3
4
1
44
Link Level RetransmissionsIn-order delivery

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

6
5
4
2
2
3
1
6
5
2
2
3
4
1
45
Link Level RetransmissionsIn-order delivery

• Not all connections benefit from retransmissions
  or ordered delivery
• audio
• Need to be able to specify requirements on a
  per-packet basis
• Should the packet be retransmitted? How many
  times?
• Enforce in-order delivery?
• Need a standard mechanism to specify the
  requirements
• open issue (IETF PILC working group)

46
Adaptive Link Layer Strategies

• Adaptive protocols attempt to dynamically choose
• FEC code
• retransmission limit
• frame size

47
Link Layer Retransmissions
2 Mbps wireless duplex link with 1 ms
delay Exponential error model No congestion losses
48
Link Layer SchemesSummary

• When is a reliable link layer beneficial to TCP
  performance?
• if it provides almost in-order delivery
• TCP retransmission timeout large enough to
  tolerate additional delays due to link level
  retransmits
• Also
• Hide wireless losses from TCP sender
• Link layer modifications needed at both ends of
  wireless link
• TCP need not be modified

49
Split Connection Approach

• TCP connection is broken into two connections
  the wired and wireless parts
• if wireless link is not last on route, then more
  than two TCP connections may be needed
• FH - BS connection standard TCP
• BS - MH connection selective repeat protocol on
  top of UDP
• FH-MH FH-BS BS-MH

FH
MH
BS
Fixed Host
Base Station
Mobile Host
50
Split Connection Approach

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

Per-TCP connection state
TCP connection
TCP connection
51
Split Connection Approach Other Variations

• Asymmetric transport protocol (Mobile-TCP)
• 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

52
Split Connection Approach Other Variations

• Mobile-End Transport Protocol
• Terminate the TCP connection at BS
• TCP connection runs only between BS and FH
• BS pretends to be MH (MHs IP functionality moved
  to BS)
• BS guarantees reliable ordered delivery of
  packets to MH
• BS-MH link can use any arbitrary protocol
  optimized for wireless link

53
Split Connection Approach

• Hides transmission errors from sender
• Primary responsibility at base station
• If specialized transport protocol used on
  wireless, then wireless host also needs
  modification
• In case of Mobile host, the state of BS can be
  transferred.

54
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

55
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

56
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 ackd to sender, the sender does
  not buffer 40

57
Split Connection Approach Disadvantages

• Hand-off latency increases due to state transfer
• Data that has been ackd to sender, must be moved
  to new base station

58
Split Connection Approach Disadvantages

• Buffer space needed at BS for each TCP connection
• BS buffers tend to get full, when wireless link
  slower.
• Window on BS-MH connection reduced in response to
  errors
• may not be an issue for wireless links with small
  delay-bw product

59
Split Connection Approach Disadvantages

• Extra copying of data at BS
• One for FH-BS socket buffer and one for BS-MH.
• 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
ack
60
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

61
Snoop Protocol

• Buffers data packets at the base station BS
• to allow link layer retransmission
• soft state at base station, instead of hard state
• 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
• Hides wireless losses from the sender
• Requires modification to only BS (network-centric
  approach)

62
Snoop Protocol
Per TCP-connection state
TCP connection
rxmt
FH
MH
BS
wireless
63
Snoop Example
35
TCP state maintained at link layer
36
37
38
40
39
37
38
FH
MH
BS
36
34
Example assumes delayed ack - every other packet
ackd
64
Snoop Example
35
39
36
37
38
41
40
38
39
36
34
65
Snoop Example
37
40
38
39
42
41
39
40
36
36
dupack
Duplicate acks are not delayed
66
Snoop Example
37
40
38
41
39
40
41
43
42
36
36
36
Duplicate acks
67
Snoop Example
37
40
38
41
39
42
41
37
44
43
FH
MH
BS
36
36
Discard dupack
Dupack triggers retransmission of packet 37 from
base station BS needs to be TCP-aware to be
able to interpret TCP headers
36
68
Snoop Example
37
40
43
38
41
39
42
37
42
45
44
36
36
36
36
69
Snoop Example
37
40
43
38
41
44
39
42
42
43
46
45
36
41
TCP sender does not fast retransmit
36
36
36
70
Snoop Example
37
40
43
38
41
44
39
42
45
43
44
47
46
41
TCP sender does not fast retransmit
36
36
36
36
71
Snoop Example
42
45
43
46
44
44
45
48
47
FH
MH
BS
41
43
36
36
36
36
72
Snoop
2 Mbps Wireless link
73
Snoop When Beneficial?

• Snoop prevents fast retransmit despite
  transmission errors, and out-of-order delivery on
  the wireless link
• 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

74
Snoop 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

75
Snoop 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)
• Snoop hides wireless losses from the sender
• But senders RTT estimates may be larger in
  presence of errors
• Larger RTO results in slower response for
  congestion losses

76
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
• Senders RTT estimate not affected by
  retransmissions on wireless link

77
WTCP Example
3
3
FH
BS
MH
3
4
Numbers in this figure are timestamps
Base station residence time is 1 unit
78
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

79
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

80
Delayed Dupacks Protocol

• 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)

81
Delayed Dupacks Protocol
Link layer state
TCP connection
82
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?
• 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 flows may also be blocked from
  being delivered to the upper layer

83
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

84
Delayed Dupacks Example
35
Link layer state
36
37
38
40
39
37
38
36
34
Example assumes delayed ack - every other packet
ackd Link layer acks are not shown
85
Delayed Dupacks Example
36
37
38
39
41
40
38
39
BS
36
34
Removed from BS link layer buffer on receipt of
a link layer ack (LL acks not shown in figure)
35
86
Delayed Dupacks Example
37
40
38
39
42
41
39
40
36
36
dupack
Duplicate acks are not delayed
87
Delayed Dupacks Example
37
40
38
41
39
40
41
43
42
36
36
36
Duplicate acks
Original ack
88
Delayed Dupacks Example
37
39
41
40
42
41
37
44
43
36
36
36
dupack
dupacks
Delayed dupack
Base station forwards dupacks
89
Delayed Dupacks Example
37
42
40
43
41
37
42
45
44
36
36
36
dupacks
36
Delayed dupacks
90
Delayed Dupacks Example
37
43
41
44
42
42
43
46
45
36
41
Delayed dupacks are discarded if lost packet
received before delay D expires
TCP sender does not fast retransmit
91
Delayed Dupacks Vaidya99
2 Mbps wireless duplex link with 20 ms delay No
congestion losses
92
Delayed Dupacks Vaidya99
5 packet loss due to congestion
93
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

94
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

95
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

96
Explicit Notification Schemes

• 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

97
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

98
Space Communication Protocol Standards-Transport
Protocol (SCPS-TP)
Satellite
wireless
TCP destinations
Ground station
99
SCPS-TP Protocol

• 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)

100
Explicit Loss Notification when MH is the TCP
sender

• 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
1
3
4
MH
FH
BS
wireless
1
1
1
1
Dupack with ELN set
101
Explicit Bad State Notification 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

102
Partial Ack Protocols

• 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

103
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
36
37
Partial ack
Cumulative ack
104
Variations

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

37
36
37
Partial ack
Cumulative ack
105
Explicit Loss Notification 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

106
Explicit Loss Notification when MH is TCP receiver
Sequence numbers cached at base station
39
38
37
37
38
39
36
37
37
Dupack with ELN
107
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

108
Receiver-Based Scheme

• MH is TCP receiver which 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

109
Receiver-Based Scheme

• Packet loss due to congestion

10
12
11
FH
MH
BS
T
10
12
FH
MH
BS
11
Congestion loss
110
Receiver-Based Scheme

• Packet loss due to transmission error

10
12
11
FH
MH
BS
2 T
10
11
12
Error loss
FH
MH
BS
111
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

112
Diagnostic Accuracy Biaz99Asset
Congestion losses
Error losses
113
Receiver-Based Scheme Disadvantages

• Disadvantages
• Limited applicability
• 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 multiple connections on
  the link will make inter-packet delays variable

114
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

115
Sender-Based Discrimination Scheme

• 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)

116
Heuristics for Congestion Avoidance
throughput
cliff
knee
RTT
load
load
117
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

118
Heuristics for Congestion Avoidance

• 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 gt 0)

119
Heuristics for Congestion Avoidance

• 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 lt 0.5)

120
Heuristics for Congestion Avoidance

• TCP Vegas Brakmo94
• expected throughput ET W(i) / RTTmin
• actual throughput AT W(i) / RTT(i)
• Condition C ( ET-AT gt beta)

121
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

122
Sender-Based Heuristics Disadvantage

• Does not work quite well enough as yet !!
• Reasons
• Statistics collected by the sender garbled by
  other traffic on the network
• Not much correlation between observed short-term
  statistics, and onset of congestion

123
Sender-Based Heuristics Advantages

• Only sender needs to be modified
• Needs further investigation to develop better
  heuristics
• investigate longer-term heuristics

124
Why do Statistical Technique Perform Poorly?

• Techniques to evaluate RTT and window size W to
  draw conclusions about state of the network use
  simple statistics.
• Unfortunately, correlation between RTT and W is
  often weak

Fraction of TCP connections
Coefficient of correlation (RTT,W)
125
Statistical TechniquesFuture Work

• Other statistical measures ?
• Mechanisms that achieve good TCP throughput
  despite not-too-good diagnostic accuracy

126
Transmission ErrorsSummary

• 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

127
TCP over Satellite

• Geostationary Earth Orbit (GEO) Satellite
• long latency
• transmission errors or channel unavailability
• Low Earth Orbit (LEO) Satellite
• relatively smaller delays
• delays more variable
• Problems?
• Long delay
• Large delay-bandwidth products
• Transmission errors

128
Improving TCP-over-Satellite

• Larger congestion window (window scale option)
• maximum window size up to 230
• Acknowledge every packet (do not delay acks)
• Selective acks
• fast recovery can only recover one packet loss
  per RTT
• SACKS allow multiple packet recovery per RTT

129
Larger Initial Window

• Allows initial window size of cwnd to be up to
  approximately 4 Kbyte
• Larger initial window results in faster window
  growth during slow start
• avoids wait for delayed ack timers (which will
  occur with cwnd 1 MSS)
• larger initial window requires fewer RTTs to
  reach ssthresh

130
Byte Counting

• Increase window by number of new bytes ackd in
  an acknowledgement, instead of 1 MSS per ack
• Speeds up window growth despite delayed or lost
  acks
• Need to reduce bursts from sender
• limiting size of window growth per ack
• rate control

131
Space Communications Protocol Standard-Transport
Protocol (SCPS-TP) Durst96

• Sender makes default assumption about source of
  packet loss
• default assumption can be set by network manager
  on a per-route basis
• default assumption can be changed due to explicit
  feedback from the network
• Congestion control algorithm derived from
  TCP-Vegas, to bound window growth, to reduce
  congestion-induced losses

132
Protocol (SCPS-TP)

• During link outage, TCP sender freezes itself,
  and resumes when link is restored
• outage assumed to occur in both directions
  simultaneously
• ground station can detect outage of incoming link
  (for instance, by low signal levels), and infers
  outage of outgoing link
• ground stations provide link outage information
  to any sender that attempts to send packets on
  the outgoing link
• sender does not unnecessarily timeout or
  retransmit until it is informed that link has
  recovered
• Selective acknowledgement protocol to recover
  losses quickly

133
Satellite Transport Protocol (STP)

• Uses split connection approach
• Protocol on satellite channel different from TCP
• selective negative acks when receiver detects
  losses
• no retransmission timer
• transmitter periodically requests receiver to ack
  received data
• reduces reverse channel bandwidth usage when
  losses are rare

134
Early Acks

• Spoofing
• Ground station acks packets
• Should take responsibility for delivering packets
• Early acks from ground station result in faster
  congestion window growth
• ACKprime approach Scott98
• Acks from ground station only used to grow
  congestion window
• Reliable delivery assumed only on reception of an
  ack from the receiver
• this is similar to the partial ack approach
  Biaz97

135
Impact of Mobility

• Hand-offs (in cellular wireless systems)
• If link layer performs hand-offs and guarantees
  reliability despite handoff, then TCP will not be
  aware of the handoff
• except for potential delays during handoff

136
Impact of Mobility

• If hand-off visible to IP
• Need Mobile IP Johnson96
• packets may be lost while a new route is being
  established reliability despite handoff
• We consider this case

137
Improving TCP in Presence of Mobility

• Hide mobility from the TCP sender
• Mobile IP
• Make TCP adaptive to mobility

138
Example Hand-Off Procedure

• Each base station periodically transmits beacon
• Mobile host, on hearing stronger beacon from a
  new BS, sends it a greeting
• changes routing tables to make new BS its default
  gateway
• sends new BS identity of the old BS

139
Hand-Off Procedure

• New BS acknowledges the greeting, and begins to
  route the MHs packets
• New BS informs old BS
• Old BS changes routing table, to forward any
  packets for the MH to the new BS
• Old BS sends an ack to new BS
• New BS sends handoff-completion message to MH

140
Hand-off

• Hand-offs may result in temporary loss of route
  to MH
• with non-overlapping cells, it may be a while
  before the mobile host receives a beacon from the
  new BS
• While routes are being reestablished during
  handoff, MH and old BS may attempt to send
  packets to each other, resulting in loss of
  packets

141
Using Fast Retransmits to Recover from Timeouts
during Handoff Caceres95

• During the long delay for a handoff to complete,
  a whole window worth of data may be lost
• After handoff is complete, acks are not received
  by the TCP sender
• Sender eventually times out, and retransmits
• If handoff still not complete, another timeout
  will occur
• Performance penalty
• Time wasted until timeout occurs
• Window shrunk after timeout

142
0-second Rendezvous Delay Beacon arrives as
soon as cell boundary crossed
Cell crossing beacon arrives
Retransmission timeout
Handoff complete Routes updated
Last timed transmit
1.0
0
0.15
0.8 sec
Packet loss
Idle sender
143
1-second Rendezvous Delay Beacon arrives 1
second after cell boundary crossed
Beacon arrives
Cell crossing
Retransmission timeout 2
Timeout 1
Handoff complete
Last timed transmit
2.0
1.0
2.8 sec
0
0.8
1.0
1.15
Packet loss
Idle sender
144
Performance Caceres95

• Four environments
• 1. No moves
• 2. Moves (once per 8 sec) between overlapping
  cells
• 3. Moves between non-overlapping cells, 0 sec
  delay
• 4. Moves between non-overlapping cells, 1 sec
  delay
• Experiments using 2 Mbps WaveLan

145
TCP Performance
146
TCP Performance

• Degradation in case 2 (overlapping cells) is due
  to encapsulation and forwarding delay during
  handoff
• Additional degradation in cases 3 and 4 due to
  packet loss and idle time at sender

147
Mitigation Using Fast Retransmit

• When MH is the TCP receiver after handoff is
  complete, it sends 3 dupacks to the sender
• this triggers fast retransmit at the sender
• instead of dupacks, a special notification could
  also be sent
• When MH is the TCP sender invoke fast retransmit
  after completion of handoff

148
0-second Rendezvous DelayImprovement using Fast
Retransmit
Cell crossing beacon arrives
Retransmission timeout does not occur
Handoff complete Routes updated
Fast retransmit
Last timed transmit
1.0
0
0.15
0.8
Packet loss
Idle sender
149
TCP Performance Improvement
150
TCP Performance Improvement

• No change in cases 1 and 2, as expected
• Improvement for non-overlapping cells
• Some degradation remains in case 3 and 4
• fast retransmit reduces congestion window

151
Improving Performance by Smooth Handoffs
Caceres95

• Provide sufficient overlap between cells to avoid
  packet loss
• Buffer packets at BS
• Discard the packets after a short interval
• If handoff occurs before the interval expires,
  forward the packets to the new base station
• Prevents packet loss on handoff

152
M-TCP Brown97

• In the fast retransmit scheme Caceres95
• sender starts transmitting soon after handoff
• BUT congestion window shrinks
• M-TCP attempts to avoid shrinkage in the
  congestion window

153
M-TCP UsesTCP Persist Mode

• When a new ack is received with receivers
  advertised window 0, the sender enters persist
  mode
• Sender does not send any data in persist mode
• except when persist timer goes off
• When a positive window advertisement is received,
  sender exits persist mode
• On exiting persist mode, RTO and cwnd are same as
  before the persist mode

154
M-TCP

• Similar to the split connection approach, M-TCP
  splits one TCP connection into two logical parts
• the two parts have independent flow control as in
  I-TCP
• The BS does not send an ack to MH, unless BS has
  received an ack from MH
• maintains end-to-end semantics
• BS withholds ack for the last byte ackd by MH

Ack 1000
Ack 999
FH
MH
BS
155
M-TCP

• Withheld ack sent with window advertisement 0,
  if MH moves away (handoff in progress)
• Sender FH put into persist mode during handoff
• Sender exits persist mode after handoff, and
  starts sending packets using same cwnd as before
  handoff

FH
MH
BS
156
M-TCP

• The last ack is not withheld, if BS does not
  expect any other ack from the MH
• this happens when the BS has no other unackd
  data buffered locally
• this is required to prevent a sender timeout at
  the end of a transfer (or end of a burst of data)

157
M-TCP

• Avoids reduction of congestion window due to
  handoff, unlike the fast retransmit scheme
• simulation-based performance results look good
• Important Question unanswered Is not reducing
  the window a good idea?
• When host moves, route changes, and new route
  may be more congested than before.
• It is not obvious that starting full speed after
  handoff is right.

158
FreezeTCP Goff99

• M-TCP needs help from base station
• Base station withholds ack for one byte
• The base station uses this ack to send a zero
  window advertisement when a mobile host moves to
  another cell
• FreezeTCP requires the receiver to send zero
  window advertisement (ZWA)

Mobile TCP receiver
FH
MH
BS
159
FreezeTCP Goff99

• TCP receiver determines if a handoff is about to
  happen
• determination may be based on signal strength
• Ideally, receiver should attempt to send ZWA
• 1 RTT before handoff
• Receiver sends 3 dupacks when route is
  reestablished
• No help needed from the base station
• an end-to-end enhancement

Mobile TCP receiver
FH
MH
BS
160
Using Multicast to Improve Handoffs
Ghai94,Seshan96

• Define a group of base stations including
• current cell of a mobile host
• cells that the mobile host is likely to visit
  next
• Address packets destined to the mobile host to
  the group
• Only one base station transmits the packets to
  the mobile host
• if rest of them buffer the packets, then packet
  loss minimized on handoff

161
Using Multicast to Improve Handoffs

• Static group definition Ghai94
• groups can be defined taking physical topology
  into account
• static definition may not take individual user
  mobility pattern into account
• Dynamic group definition Seshan96
• implemented using IP multicast groups
• each users group can be different
• overhead of updating the multicast groups is a
  concern with a large scale deployment

162
Using Multicast to Improve Handoffs

• Buffering at multiple base stations incurs memory
  overhead
• Trade-off between buffering overhead and packet
  loss
• Buffer requirement can be reduced by starting
  buffering only when a mobile host is likely to
  leave current cell soon

163
Issues for Further Investigation
164
Link Layer Protocols

• Pure link layer designs that support higher
  transport performance
• some recent work in this area as noted earlier
• Identifying scenarios where link layer solutions
  are inadequate
• If TCP-awareness is absolutely needed, provide an
  interface that can be used by other transport
  protocols too

165
End-to-End Techniques

• Existing techniques typically require cooperation
  from intermediate nodes.
• Such techniques often not applicable
• encrypted TCP headers
• TCP data and acks do not go through same base
  station
• End-to-end techniques would rely on information
  available only at end nodes
• Harder to design due to lack of complete
  information about errors
• Explicit Notifications may make that easier

166
Impact of Congestion Losses

• Past work typically evaluates performance in
  absence of congestion
• Relative performance improvement may change
  substantially when congestion occurs
• performance improvement may reduce if congestion
  is dominant, or if RTO becomes larger due to
  wireless errors

167
Multiple TCP Transfers

• Past work typically measures a single TCP
  connection over wireless
• TCP throughput is the metric of choice
• When multiple connections share a wireless link,
  other performance metrics may make sense
• fairness
• aggregate throughput
• Relative performance improvements of various
  schemes may change when multiple connections are
  considered

168
TCP Window RTO Settings After a Move

• Congestion window RTO size at connection open
  are chosen to be conservative
• When a route change occurs due to mobility, which
  values to use?
• Same as before route change ---- may be too
  aggressive
• Same as at connection open ---- may be too
  conservative
• Answer unclear
• some proposals attempt to use same values as
  before route change, but not clear if that is the
  best alternative