1
Wireless TCP Introduction
The problems of Standard TCP over wireless link and basic solution
Several implementations of wireless TCP I-TCP (Indirect TCP) Snoop Protocol Delayed duplicated ACK Multiple Acknowledgements Freeze TCP
Comments and discussion
2
The problems of standard TCP in wireless networks
Standard TCP assume that the packet losses are due to the congestion.(99%)
This not valid considering the characteristic of wireless link sporadic high bit-error rate, high latencies temporary disconnection due to handoff
Misinterpretation packet loss for congestion
3
Basic ideas to overcome the problem in wireless network
Hide any non-congestion-related losses from TCP Split TCP connection Local retransmissions
IP LayerLink layer
Let TCP aware the non-congestion-related losses and not apply congestion control
4
Basics topology
Figure 1 Topology
5
I-TCP: Indirect TCP
Breaks the TCP connection between FH and MH into two connections at MSR
Connection between FH and MSR is regular TCP
Connection between MSR and MH is any transport layer protocol tuned for wireless links.
6
I-TCP indirect TCP (Cont.)
BS cache packets from FH and send back ACK for MH.
if MH switches to another cell the center point of the connection moves to the new MSR, no need of reconnection.
FH is completely unaware of the indirection and is not affected even when the MH switches cells.
7
Figure 2 I-TCP setup and handoff
8
I-TCP Result in LAN
TABLE 1 I-TCP Throughput Performance over Local Area
9
I-TCP Result in WAN
Table 2 I-TCP Throughput Performance over Wide Area
10
Snoop Protocol
Basic idea Modify the IP layer in the BS, and let BS
cache the TCP packets sent from FH before route it to the MH.
If packet lost on wireless link, IP layer on the BS will retransmit the packet .
BS suppress DUPACKs sent from MH to FH. BS use shorter local timer for local timeout.
11
Three kinds of data packets from FH
A new packet in the normal TCP sequence. (common case)
An out-of-sequence packet that has been cached earlier. (sender retransmission)
An out-of-sequence packet that has not been cached earlier. (congestion loss)
12
Flowchart for snoop_data
New Packets?
Packet arrives
1. Forward Packet2. Reset local rexmit counter
In sequence? 1. Mark as cong. loss2. Forward packet
1. Cache packet2. Forward to mobile host
Figure 3. Flowchart for snoop_data()
Sender rexmition
Congestion loss
Common case
No
No
Yes
Yes
Acknowledged Send back lasted ACK
Yes
No
13
Process three kinds of ACKs
A new ACK from MHA spurious ACK, sequence number
less than the lasted acknowledged one
A duplicate ACK (DUPACK)
14
Flowchart for snoop_ack
Ack arrives
New ACK?
Dup ACK?
First one?
1. Free buffers2. Update RTT3. Propagate ACK to sender
Retransmit lostpackets with high priority
Discard
Discard
Yes
No
Yes
Yes
No
No
Spurious Ack
Later dup Acks, for lost packet Next packet lost
Common case
Figure 4. Flowchart for snoop_ack
15
Data from MH to FH
Can not differentiate between BER loss or Congestion loss.
Using SACK (selective acknowledge)BS keep track packet losses in a
transmit window.BS send NACK to MH with SACK
option indicate the boundary of the lost packets.
16
Routing in snoop protocol
Similar to Mobile IP.Using multicast and intelligent
buffering in nearby base stations.One prime BS forward packetsSeveral nearby BS cache the last
several packets
17
Figure: Intelligent cache
18
Handoff process in snoop protocol
Initiated by mobile hostMH send control messages to the
various BS, request them either begin or end forwarding and buffering of packets
The activated forwarding BS synchronizing its buffer using information in the control message
19
Handoff process Cont.
since snoop module does not change any of the end-to-end semantics of TCP, it is resistant the random packet losses when handoff.
20
Handoff processBS_OLD MH BS_NEW
packet1
beaconStronger beacon
Buffer requestForward request
packet2
packet3
packet4
packet5
Handoff latency
21
Topology for experiment
Transmitter
BS1 BS2
Home Agent
MH
AT&T Wavelan
2Mbits/s
Ethernet
22
Throughput: Snoop vs. Regular TCP
23
Sequence number: Snoop vs. Regular TCP
24
Delayed Duplicate ACK
Motivations TCP may be encrypted ACK may go different paths from that of
data.Basic ideas
The idea is to delay the third and subsequent duplicate acknowledgments for some time, let BS link layer do local retransmissions.
25
Delayed Duplicate ACK (cont.)
TCP not changed in BS , only changed in MH
BS data link layer re-transmission triggered by link level acknowledgements.
Performance depend on the ratio of BER loss and congestion loss.
26
Reduce interference
FH timer is very coarse (multiple of 200 or 500ms), link layer timer in BS is much smaller. Interference is small.
Reduce interference between fast retransmission and local retransmission by delay the third dupack for a time interval T.
27
Delay interval T
If T = 0, regular TCP. All congestion loss
If T = infinity, regular TCP without fast retransmission. All BER loss
Appropriate T should be a function of RTT of the wireless link, and relate to BER and congestion loss rate.
28
Simulation Result
Use ns-2 simulatorWired network with 10Mbps
bandwidth and delay of 20ms.Wireless network with 2Mbps
bandwidth and delay of 1ms - 40mspacket data size is 1000 byte.T ranges from 0 to 0.2 second
31
Multiple Acknowledgements Protocol
Distinguish the losses on the wired portion from the losses on the wireless link.
ACKp: partial acknowledgment that inform the sender the packet is received by BS.
ACKc: complete acknowledgment has the same semantics as the normal TCP.
RTT: round trip time between the sender and the receiver. (end to end)
32
Multiple Acknowledgements protocol (Cont.)
RTTB: round trip time between the base station and the mobile host.
RTO: timer value for end-to-end acknowledgement.
RTOB: maximum time which can elapse between the reception of a packet at the base station and its acknowledgement by the mobile host
33
Figure : Multiple Acknowledgement
34
TCP on sender and receiver
Sender When receive a ACKp, reset timer RTO to
avoid time out while BS is retranslating. Update RTT when receive ACKp, suitable
for transit bandwidth drop Update RTT when receive ACKc, reflect
the real round trip timeNo change is made to Receiver TCP
35
Snoop protocol on BS
Snoop data On receiving new packet, cache it and start
RTOB On receiving out of order and cached packet,
S > Sa, and packet still in cache, send ACKp to FHS > Sa, and packet not in cache, as new packetS < Sa, generate a fake ACKc to FH
On receiving out of order and un-cached packet, cache it and forward
36
Snoop protocol on BS (Cont.)
Retransmissions When RTOB expires, the packet must be
retransmitted and ACKp is sent back to the to the sender if all packets before it have been received by the base station. (important difference from Berkley Snoop Protocol)
Snoop ACK is the exactly the same with the Berkeley Snoop Protocol
37
Implementation of ACKp and ACKc
For ACKc, it is the normal TCP ACKFor ACKp, An option is implemented
with the a type byte, length byte and a 4 bytes sequence number, total of 6 bytes.
38
Freeze-TCP
Motivations Most wireless TCP implementations do
not handle frequent handoff or long temporary disconnection properly.
Freeze-TCP can handle it efficiently. Freeze-TCP can be integrated with other
existing solutions. Only change TCP on the mobile client
side
39
Handle frequent handoff
ZWP - zero window probesWhen advertise window become zero,
sender send ZWP.If ZWP is lost, the sender does not
shrink congestion window, but exponentially back off.
Sender resume transmission after receive a non-zero advertised window
40
Handle frequent handoff (cont.)
Mobile client sense the strength of signal to judge if there will be a handoff or disconnection.
Send ZWA (Zero Window Advertisement) to sender before handoff.
Warning period choose as RTT.
41
Avoid long freeze time
The interval between successive ZWPs grow exponentially.
Long freeze time if reconnect immediately after a ZWP lost.
Use TR-ACK to avoid long unnecessary freeze time, send 3 copies of ACKs for the last data segment it received prior to the disconnection.
Illustration of throughput
Freeze vs Regular TCPIn LAN
Freeze vs Regular TCP In WAN
45
Comments and discussion
I-TCP Well performed in most of the wireless
links, no change in FH Change semantics of end-to-end ACK,
Berkeley Snoop Well performed in wireless LAN, keep
semantics of end-to-end ACK
46
Comments and discussion Cont.
Not perform well in wireless links with long latency, fail when TCP is encrypted.
Multiple Acknowledgement Can be used in high bit-error rate
environment, keep ACK semantics Fail when TCP is encrypted
47
Comments and discussion Cont.
Delayed Acknowledgement Can be used when TCP is encrypted Use link layer retransmission, must
have reliable link layer support
Comparison between different protocols
SNOOP I-TCP MTCP DelayedDupacks
FreezeTCP
Need intermediatenode?
Yes Yes Yes No No
Handle encryptedtraffic
No No No Yes Yes
End-to-end TCPsemantics
Yes No No Yes Yes
Handle longdisconnection
No Costly Costly No Yes
Frequentdisconnection
No Costly Costly No Yes
Handle high BER Yes Yes Yes No No
49
TCP propagation delay introduction
Long RTTs are now becoming prevalent in the Internet with the introduction of paths crossing satellite links.
At long RTT, TCP congestion mechanism may result in an inefficient utilization of network resources.
Since TCP is based on the ACK clock, the congestion window increase rate is lower because of long RTT.
50
Effect of propagation delay
The performance that suffer the most is during congestion avoidance at a low slow start threshold.
Slow start requires more time to achieve in long RTT link. Therefore TCP performance degrades.
It is more critical for small file transfer and WWW browsing.
51
Solutions overview for propagation delay
Many propositions have been suggested to increase window growing rate at the beginning of the connection.
These propose try to reduce RTTs required to reach network capacity. But the absence of any kind of bandwidth estimation may result in bursts which can cause losses of packets.
This problem is exacerbated in the presence of ack loss.
52
Solutions for propagation delay
TCP level solutionsApplication level solutionsNetwork level solutions
53
TCP level solutions for propagation delay
The first proposition: Use a window larger than one segment at the
beginning of slow start. (proposed maximum 4 segments)
After Timeout, the network is supposed to be severely congested so that a transmission at a small initial window is required.
The second proposition:Byte Counting It increases the window by the number of bytes
covered by an ack rather than number of acks. This decouples the window increase algorithm from
ack clock which may result in burstiness when acks are lost.
54
Application level solutions for propagation delay
The solution is to establish many simultaneous TCP connections for the transfer of a single file.
This increases the growth rate of resultant window during slow start, and makes the recovery algorithm more efficient due to distribution of losses on many connections.
However, this solution increases the aggressiveness of the transfer.
55
Network level solutions for propagation delay
TCPConnection 1
TCPConnection 2
OptimizedTransportProtocol
No Slow Start
A B
Source DestinationLong Delay Link
Suppression ofDestination ACKs
Generation of ACKs
56
Network level solutions for propagation delay (contd)
TCP spoofing In order to decrease the RTT of the connection,
the acks are generated by the router at the input of this link.
Because packets have already acknowledged (by router A), any loss between the input and destination must be retransmitted on behalf the source.
Also, acknowledgements from the receiver must be silently discarded so as not to confuse the source.
57
Network level solutions for propagation delay (contd.)
The main gain in performance comes from not using slow start.
Drawbacks it breaks the end-to-end semantics of
TCP. It doesn’t work when encryption is
accomplished at the IP layer and it introduce a heavy overload on intermediate routers.
58
TCP bandwidth asymmetry introduction
The asymmetric network is motivated by technological and economic considerations as well as by the popularity of applications such as Web access which involve a substantially larger data flow towards the client (the forward direction) and from it (the reverse direction).
Example: Direct Broadcast Satellite networks, Cable Modem, Asymmetric Digital Subscriber Loop (ADSL)
59
Asymmetry network topology
60
Effect of bandwidth asymmetry
TCP assumes that forward channel and reverse channel have the same bandwidth. That means the source can rely on the ACK clock to guess what is happening on the forward channel.
If the reverse channel has lower bandwidth, the TCP congestion algorithm may miscalculate RTT and has lower throughput.
If reverse channel is also used for data, the problem of asymmetry will be exacerbated.
61
Solution for asymmetry effect in one-way transfer
Definition: data transfer in forward link and acks transfer in reverse link.
Receiver: Ack Congestion Control (ACC) Ack Filtering (AF)
Sender: TCP Sender Adaptation (SA) Ack Reconstruction (AR)
62
Ack Congestion Control (ACC) - decrease frequency of acks
Use Random Early Detection (RED) algorithm at the gateway of the reverse link to aid congestion control.
The gateway detects incipient congestion by tracking the average queue size over a time in the recent past.
If the average exceed a threshold, the gateway set an Explicit Congestion Notification (ECN) bit using the RED algorithm. This notification is reflected to data packets (forward link) and acks (reverse link).
63
Ack Congestion Control (ACC) (contd.)
Once sender receives the packet, the sender reduces its sending rate.
The TCP receiver maintains a dynamically varying delayed-ack factor d, and send one ack for every d data packets.
When it receives a packet with ECN bit set, it increases d multiplicatively.
When it does not receive an ECN, it linearly decrease the factor d.
Conclusion: the receiver mimics the standard congestion control behavior of TCP sender.
64
Ack Filtering (AF) - decrease the number of acks
Based on the fact that TCP acks are cumulative.
When an ack from the receiver is about to be enqueued, the router traverses its queue to check if any previous acks belonging to the same connection are already in the queue.
It so, then it removes some fraction of acks and frees up bandwidth.
The acks dropping policy can be deterministic or random.
65
The drawback of receiver solution
Fact: ACC and AF acknowledge several data packets in one ack.
It can cause problem such as sender burstiness, a slowdown in window growth, and a decrease in the effectiveness of the fast retransmission algorithm.
66
TCP Sender Adaptation (SA)
sender burstiness solution: put a upper bound on the number of packets the sender can transmit, even if the window allows the transmission of more data.
The sender can avoid a slowdown in window growth by simply taking into account the amount of data acknowledged by each ack, rather than the number of acks.
67
TCP Sender Adaptation (SA) (contd.)
Fast retransmission degrading problem solution: solve by not requiring the sender to count the number of duplicate acks.
With ACC, when receiver observers a threshold number of out-of-order packets, it marks all of the subsequent duplicate acks with a bit to request a fast retransmission.
With AF, the reverse channel router request fast retransmission when it has filtered out a threshold number of duplicate acks. The receipt of even one such marked packet causes the sender to do a fast retransmission.
68
Ack Reconstruction (AR)
A technique to reconstruct the ack stream after it has traversed the reverse direction bottleneck link.
This enables us to use schemes such as ACC and AF without having to modify sources and perform SA, which is asymmetric network providers may able to locally deploy.
The main idea is for the reconstructor to fill in the gaps in the ack sequence to “smooth out” the ack stream seen by the sender.
69
Ack Reconstruction (AR) (contd.)
AR interspersing acks to provide the sender with a larger number of acks at a consistent rate.
When an ack arrives at B, all the missing acks between the sequence number it carries and that of the ack received at B are generated.
Example: Suppose 2 acks a1 and a2 arrive at the reconstructor after traversing the constrained reverse link. Let a2-a1 = a >1
When a2 reaches the sender, at least a packets are sent by sender. Congestion window increases by at most 1.
AR remedies this situation by interspersing acks to provide to sender with large number of acks.
It reduces degree of burstiness and causes the congestion window to increase faster.
70
Asymmetry effect in two-way transfer
Definition: both data and acks transfer in forward and reverse link.
In this case, a single FIFO queue for both data and acks could cause problems.
For example, an 1KB sized data packet takes 280ms to go through 28.8kbps dialup line. If more such data packets get queued ahead of ack packets, it would block out the ack packets for a long time.
71
Solution for asymmetry effect in two-way transfer
Acks-first scheduling. This algorithm always gives higher priority to acks over data packets. By combining with header compression techniques, the transmission time of acks becomes small enough that it affects subsequent data packets very little.
At the same time, it minimizes the idle time for the forward link by minimizing the amount of time acks remain queued behind data packets.
72
Asymmetry effect summary
ACC and AF are schemes to reduce the frequency of acks on the reverse channel.
SA and AR are schemes to overcome the adverse effects of reduced ack feedback.
In experiments, we use ACC conjunction with SA, and AF in conjunction with SA or AR.
Acks-first scheduling scheme is designed to prevent the forward transfer from being starved by data packets of the reverse transfer.
73
Figure: one-way transfer comparison
74
Figure: one-way throughput
75
Figure: congestion window
76
Figure: two-way transfer comparison
77
References
Chadi Barakat, Eitan Altman,Walid Dabbous, “On TCP Performance in an Heterogeneous Network: A Survey”, INRIA-France, Research Report N=3737, July 1999
H. Balakrishnan, V. Padmanabhan, and R. Katz, “The Effects of Asymmetry on TCP Performance”, in ACM MobiCom, Sep 1997.
T. V. Lakshman, U. Madhow, and B. Suter, “Window-based error recovery and flow control with a slow acknowledgment channel: a study of TCP/IP performance”, INFO-COM’97.
D. Lin and R. Morris, “Dynamics of Random Early Detection”, in ACM SIGCOMM, Cannes, France, Sep 1997.
L. Zhang, S. Shenker, and D.D. Clark, “Observations on the Dynamics of a Congestion Control Algorithm: The Effects of Two-Way Traffic”, in ACM SIGCOMM, Sep 1991.
78
Reference (contd)
A comparison of Mechanisms for Improving TCP Performance over Wireless Links, IEEE/ACM TRANSACTIONS ON NETWORKING VOL.5 NO.6 1997 IEEE
TCP Extensions for Wireless Networks, http://www.cis.ohio-state.edu/~deshpand
Badrinath B R, Bakre A "I-TCP :Indirect TCP for mobile hosts”, Proc. 15th Int'l Conference on Distributed Computing, May 1995, 18 pages. ftp://paul.rutgers.edu/pub/badri/itcp-tr314.ps.Z
Balakrishna H, Katz, Seshan S "Improving reliable Transport and handoff performance in cellular wireless networks”, Wireless Networks,1(4), Dec 95, 19 pages, http://www.cs.berkeley.edu/~ss/papers/winet/html/winet.html
79
Reference (contd)
Vaidya N, Mehta M "Delayed duplicate acknowledgements: A TCP-unaware approach to improve performance of TCP over wireless" Texas A&M University, Technical Report 99-003, February 1999, 16 pages. http://www.cs.tamu.edu/faculty/vaidya/papers/mobile-computing/99-003.ps
Biaz S, Vaidya N et al "TCP over wireless networks using multiple acknowledgements” , Texas A&M University, Technical Report 97-001, January 1997, 10 pages. http://www.cs.tamu.edu/faculty/vaidya/papers/mobile-computing/97-001.ps
Freeze-TCP: A True End-to-End TCP Enhancement Mechanism for Mobile Environments http://www.ieee-infocom.org/2000/papers/501.pdf
RFC2581 "TCP congestion control", The Internet Society 1999