Get documents about "CSE-538-TCP over wireless
Description
mobile computing
Document Sample
TCP over wireless
Data Link Layer
• Deliver frames
between nodes that
are connected over a
single link.
– Frame: a data unit
delivered in the data
link layer
8/9/2012 2
What should Data Link Layer do?
• Delimit a frame.
– Framing
• If DLL should provide reliable service to upper layers, it will
do
– error control
– flow control
– in-order delivery, etc
8/9/2012 3
Error control
• Error detection
– CRC
– Checksum
• Error correction
– Automatic Repeat Request
(ARQ):retransmission
• Go-Back-N
• Selective Repeat(Request)
– Forward Error Correction (FEC)
8/9/2012 4
Go-back-N
Selective Repeat &(b) Go-Back-N(GBN)
(a) Selective Repeat(SR)
I(0) I(0)
I(1) ACK(1) 0 I(1) ACK(1) 0
I(2) . 1 I(2) . 1
I(3) . 2 I(3) . 2
I(4) . 3
Error
I(4) . 3
Error
I(5) NAK(4) Retransmit
I(5) NAK(5) on I(4)
I(6) ACK(5) 5 on I(4) I(6)
6 all frames
Retransmit I(4) I(4)
from I(4)
only I(4)
I(7) 4 I(5) 4
I(0) 7 I(6) 5
I(1) 0 I(7) 6
I(2) ACK(2) Error I(0) ACK(8) 7 Error
timeout timeout
I(3) on ACK(2) I(1) on ACK(8)
I(4) I(7)
Retransmit
Retransmit I(1) from I(7) I(0)
only I(1) I(5) I(1)
I(6) I(2
8/9/2012 I(7) 3) preserve 5
Frames out of order frame order
I(4)
Is the TCP retransmission GBN or SR?
• The TCP receiver retransmits the packet
selectively for which the ack has timed out
or dupacks arrived.
– Similar to SR
• But unlike SR, the TCP receiver
acknowledges cumulatively the last packet
correctly received.
8/9/2012 6
Delay-Bandwidth product
• Congestion window size bounds the amount of
data that can be sent per round-trip time (RTT).
• Throughput: amount of data sent per time
– It is equivalent to the bandwidth used for actual
transmission
W
throughput
RTT
Ideal window size = max bandwidth(BW) * RTT
8/9/2012 7
Ideal window size?
• What if W < RTT*BW?
– Inefficiency (wasted
bandwidth)
RTT
• What if W > RTT*BW? W Window size
Amount of data
– Queuing at intermediate To be transmitted
routers and increasing
RTT
– Potentially, packet loss
8/9/2012 8
The problem of TCP in wireless links
• Random errors may cause Fast
Retransmit.
• The Fast Retransmit results in
– Retransmission of lost packet
– And the Fast Recovery reduces congestion
window.
– Reducing congestion window decreases
throughput.
• Reducing congestion window in response
to errors is unnecessary.
8/9/2012 9
Continued …
• Burst errors may cause timeouts. If a wireless
link remains unavailable for extended duration,
data of the window size will be lost.
– Example, driving through a tunnel
• Timeout results in Slow Start.
• Slow Start reduces congestion window to 1 MSS
(maximum segment size) , consequently
decreasing throughput.
• Again, doing the Congestion Avoidance in
response to errors is unnecessary.
8/9/2012 10
Continued …
• Fundamental question: How to distinguish
loss due to congestion from loss due to
other wireless/mobility reasons?
• Hard to do: TCP is fundamentally end-to-end.
– We just know that packet is lost, not why it is lost.
• Existing solutions break the end-to-end
principle to some extent.
– Also must be compatible with existing TCP.
8/9/2012 11
maximum segment size
• TCP and IPv4 headers are 20 bytes long each, whereas an IPv6 header is
40 bytes long, so the MSS is equal to MTU minus 40 when using IPv4, and
MTU minus 60 when using IPv6 (typical MTU for IPv4 is 1500 bytes).
• As data is routed over the Internet, it must pass through multiple gateway
routers.
• Ideally, each TCP segment can pass through every router without being
fragmented.
• If the data segment size is too large for any of the routers through which the
data passes, the oversized segments are fragmented.
• This slows down the connection speed as seen by the computer user. In
some cases the slowdown is dramatic.
• The likelihood of such fragmentation can be minimized by keeping the
MSS as small as reasonably possible.
• For most computer users, the MSS is set automatically by the operating
system.
8/9/2012 12
Continued …
• Thus, if the IP datagrams carrying the segments are as large as
possible, we use the optimum segment size to avoid
fragmentation.
• Although this may be difficult to achieve, it can be beneficial
for the system to run smoothly without delayed performances
or slow connection.
• Thus, in order to achieve this goal, three considerations must
be made:
– Make sure the implemented TCP has a mechanism for this.
– Check the dynamic route changes of the routers to make sure that the
datagrams does not dynamically change into a size that needs to be
fragmented.
– Observe the lower-level protocol headers.
8/9/2012 13
Continued …
• The selection of the MSS is based on the need to balance competing
performances and implementation issues in the transmission of data being
passed around on the TCP/IP.
• For example, let us take the definition of overhead management to
consideration. Since the TCP header takes up 20 bytes, the IP header must
also use 20 bytes or more, requiring a minimum of 40 bytes to be placed for
the headers.
• A low MSS setting would lead to an inefficient use of network bandwidth,
since a larger percentage of each segment would consist of TCP and IP
header information.
• Another example is IP fragmentation when the TCP is packaged into IP
packets.
• If the TCP segment is too large, it will lead the IP packet to be too large,
and then cause fragmentation. Since fragmentation reduces efficiency and
increases the chance of data loss, such an event can potentially lead to the
need to retransmit the entire segment.
8/9/2012 14
Ideal TCP behavior
• Ideally, TCP sender should only retransmit a
packet lost due to transmission errors without
any congestion control actions.
• So, transmission errors should be hidden from
the TCP sender.
• Therefore we can say that the goal of the work
for improving TCP performance in wireless links
is to differentiate packet loss due to transmission
errors from due to congestion.
•
8/9/2012 15
Broad Approaches
• Two broad approaches to run TCP over wireless
links.
– Mask wireless loss from the TCP sender: Then TCP sender will
not reduce congestion window.
– Explicitly notify the TCP sender about cause of packet loss: TCP
sender will not reduce congestion window for wireless losses.
• Some additional approaches designed to explicitly
handle mobility.
• Solutions may be at the TCP sender, at the TCP
receiver, or at an intermediate node (typically,
wireless base station or WLAN access point).
8/9/2012 16
Techniques to Mask Wireless Losses
from TCP Sender
• Split connection approach
– I-TCP [Bakre-Badrinath-ICDCS-95]
• Snoop TCP [Balakrishnan-et-al-ACM-Winet-95].
• These solutions assume that the wireless
part is just one hop (traditional cellular or
WLAN network).
• All losses on wireless side assumed not
connected with congestion.
– Note that this may not true always; e.g., losses due to
collision is because of congestion. But such subtleties
are ignored. Assume that link layer is able to
overcome congestion losses.
8/9/2012 17
Indirect TCP (I-TCP)
• Segment the TCP connection into two.
• No changes to the TCP protocol for hosts connected to
the wired Internet (correspondent host or CH).
• Split the TCP connection at AP into 2 TCP connections,
one between CH and AP, the other between AP and MH.
No real end-to-end connection.
• The connection between AP and MH does not need to be
a real TCP. Can be a custom transport protocol that is
tuned for the wireless hop. For example, selective repeat
over UDP.
8/9/2012 18
I-TCP Socket and State Migration
• On handoff, connection state must be
migrated.
8/9/2012 19
I-TCP Critique
• Advantages
– No changes in the fixed network necessary.
– Transmission errors on the wireless link do not propagate into
the fixed network. Local recovery from errors.
– Possibility of using custom (optimized) transport protocol for the
AP-MH hop.
• Disadvantages
– Loss of end-to-end semantics, an ACK to sender does now not
any longer mean that a receiver really got a packet. Problem if
there is a crash at AP.
– Large buffer space may be needed at AP.
– AP must maintain per-TCP connection state.
– State must be forwarded to new AP on handoff. May cause
higher handoff latency.
8/9/2012 20
Disadvantages(1)
• End-to-end semantics violated
– Ack may be delivered to sender before the packet is
delivered to the receiver.
• BS failure can result in loss of packets.
39
40
38 37
FH BS MH
40 36
8/9/2012 21
Disadvantages(2)
• Hand-off latency increases due to state
transfer. Packets that has been acked to
sender must be moved to new base
station. 39
40 38 37
FH BS MH
40 36
39
40 MH Hand-off
8/9/2012 22
New base station
Disadvantages(3)
• Buffers at BS are needed for each TCP
connection, and buffers tend to become
full when wireless link is slower.
• Extra copying of packets at BS
– Copying from FH-BS socket buffer to BS-MH
socket buffer
• It may not be useful if data and acks
traverse different paths.
8/9/2012 23
Snoop TCP: Simple LL retransmit
+ TL Delayed dupacks
• Removes the limitation of I-TCP
– No more split connection.
– Single end-to-end connection like regular
TCP.
• Only access-point (AP) modified for a
base implementation.
– Modification on MH improves over the base
implementation. But not mandatory.
• AP “snoops” on all TCP packets. It
buffers packets for the MH.
8/9/2012 24
Continued …
• Data transfer to MH
– AP buffers data until it receives ACK from MH, AP
detects packet loss via dupacks or time-out, and
retransmits packet.
– CH unaware of loss or retransmission. No reduction
in congestion window.
• Data transfer from MH
– AP detects packet loss on the wireless link via
missing sequence numbers, AP answers directly with
a NACK to the MH.
– MH can now retransmit data with only a very short
delay.
– This requires modification on the MH.
8/9/2012 25
Continued …
• It is also “Make transmission errors transparent
to TCP” approach.
• Link layer retransmits frames if errors occur.
• TCP receiver delays third and subsequent
dupacks for interval D when it receives out-of-
order packets
• Delayed dupacks gives link layer retransmission
time to succeed without triggering Fast Transmit
from the TCP sender.
8/9/2012 26
Snoop : Example
Link layer buffer
End-to-end TCP connection
application application delay application
dupacks
transport transport transport
network network network
rxmt
link link link
OOO
physical physical permitted physical
BS MH
wireless
8/9/2012 27
Snoop : Example
35
Link layer state
36
37
38
40 39 38 37
34 36
original ack
Example assumes delayed ack - every other packet ack’d
Sequence number is TCP number.
Ack number is for the packet received correctly.
8/9/2012 Link layer acks are not shown 28
: buffer
Snoop BS Example
36
37
38
39
41 40 39 38
BS
34 36
original ack
35 Removed from BS link layer buffer on receipt of a
link layer ack (LL acks not shown in figure)
8/9/2012 29
Snoop : Example
37
38
39
40
42 41 40 39 38
36 36
original ack dupack
Duplicate acks are not delayed
8/9/2012 30
Snoop : Example
37
38
39
40
38
41
39
43 42 41 40
36 36 36
Original ack Duplicate ack 1
Duplicate ack 2
8/9/2012 31
Snoop : Example
37
39
40
38
41
39
42
40
44 43 37 41
36 36
36
dupack 1 dupacks 2
Delayed
dupack 3
Base station retransmits 37.
8/9/2012 32
Snoop : Example
37
38
40
41 39
42 40
43 41
45 44 42 37
36 36
36
dupacks 36
Delayed dupacks
8/9/2012 33
Snoop : Example
37
41
42
43
44
46 45 43 42
36 41
Delayed dupacks are
discarded if lost
TCP sender does not packet received before
fast retransmit delay D expires
8/9/2012 34
Critique of Snoop TCP
• Advantages:
– Can work without modification on MH.
– Preserves end-to-end semantics. Crash does not affect
correctness, only performance.
– After handoff, new AP does not need to understand snoop TCP
for communication to continue. Can automatically fall back on to
regular TCP.
– No state needs to be migrated. But if done, this can improve
performance.
• Note such “state” is called soft state. Good if available. But can work
if not available.
• Disadvantages:
– For the NACK scheme to work MH still needs to be modified.
– Does not work with encrypted TCP headers.
– Does not work for asymmetric routes.
8/9/2012 35
Explicit Notification-Based Approach
• Send notification to the TCP sender about
wireless packet loss.
• Upon notification, TCP sender retransmits
packet, but does not reduce congestion
window.
• Motivated by the Explicit Congestion
Notification (ECN) Approach [Floyd-94].
• Many design options: Who sends
notification? How? How notification is
interpreted at sender?
8/9/2012 36
Explicit Loss Notification (ELN)
Approach
• Assume MH is the TCP sender.
• AP keeps track of holes in the packet sequence received
from the sender
• When a dupack is received from the receiver (CH), AP
compares the dupack sequence number with the
recorded holes
– if there is a match, an ELN bit is set in the dupack
• When sender (MH) receives dupack with ELN set, it
retransmits packet, but does not reduce congestion
window.
8/9/2012 37
Impact of Mobility on TCP Performance
• Handoff can be either at the link layer (IP does not
know) or at the network layer (IP is aware).
• Link layer handoff may not impact TCP much.
– Other than a transient increase in RTT.
• Network layer handoff (e.g., Mobile IP) is slow. This
is because routing must be updated.
– Packets can be lost.
– TCP is impacted.
– We are interested in such handoffs.
8/9/2012 38
Fast Retransmit-Based Solution
• During the long delay for a mobile-IP handoff
to complete, a whole window worth of
packets may be lost.
– Assuming no buffering/forwarding.
• 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.
8/9/2012 39
Illustrative Timeline
8/9/2012 40
Fast Retransmit-Based Solution
• Assumption: MH is aware of handoff process
• When MH is the TCP receiver: after handoff is
complete, it sends 3 dupacks to the sender
– this triggers fast retransmit at the sender.
• When MH is the TCP sender: invoke fast retransmit after
completion of handoff.
• Advantages
– no slow start after handoff.
– Retransmissions immediately after handoff instead of waiting for
timeout.
– Very minor change on TCP on MH only.
• Disadvantages
– Only handles losses due to handoff.
– Retransmitted packets will still traverse the entire network.
– Congestion window still reduces upon handoff.
8/9/2012 41
Mobile TCP (M-TCP)
• The fast-retransmit based solution can
start retransmission immediately after
handoff is complete. But it cannot
prevent reduction in congestion
window.
• M-TCP also prevents reduction in
congestion window.
• How? Using persist mode of TCP.
8/9/2012 42
M-TCP Uses TCP’s Persist Mode
• TCP fact: When a new ACK is received with
receiver’s advertised window = 0 (in TCP
header), the sender enters persist mode.
• Means receiver does not have space to accept
more packets.
• Sender does not send any data in persist
mode.
• When a positive window advertisement is
received again, sender exits persist mode.
• On exiting persist mode, retransmit
timeout (RTO) and Congestion
Avoidance and Control (cwnd) are same
as
8/9/2012 before the persist mode. 43
M-TCP Details
• Similar to split connection approach (I-TCP).
– But maintains end-to-end semantics. AP forwards ACK only after
it receives ACK.
• When the AP detects handoff or disconnection
– AP advertises zero receiver window to sender.
– This forces sender into persist mode.
– After handoff is complete (connectivity is regained) new AP
advertises correct receive window size.
• How is the zero window advertisement is sent?
– AP withholds the ACK for the last byte.
– This ACK carries the zero window advertisement on handoff.
8/9/2012 44
Critiquing M-TCP
• Some argue that not reducing the
congestion window may not always be
a good idea.
– Level of congestion on new route is unknown!
• M-TCP needs help from AP for zero
window advertisement.
– It is possible for the receiver to do this, when it
is the MH.
8/9/2012 45
Simple Link Layer retransmission:
Approach
• Make transmission errors transparent to TCP
• If link layer is reliable,
– It provides in-order delivery.
– It retransmits frames whenever errors occur.
• If TCP timeout is large enough to tolerate
additional delay due to link layer retransmission,
• then transmission errors are transparent to TCP.
Thus TCP does not need to be modified,
keeping the end-to-end semantics.
8/9/2012 46
Continued …
Link layer state
End-to-end TCP connection
application application application
transport transport transport
network network network
rxmt
link link link
In-order
physical physical enforced physical
wireless
8/9/2012 47
But, the problems…
• Link layer is unaware of TCP connections. So it cannot
differentiate frames per TCP connection.
• Link layer transmission can cause head-of-line(HOL)
blocking in the link layer buffer.
• Actually the example below is somewhat exaggerating
reality, since the seq number are TCP not link layer
numbers.
1
Link layer buffer bad link
2 2 2 1
base 2
8/9/2012 station 48
Continued …
• Furthermore, retransmission can cause frame
loss due to buffer overflow.
• If the link layer buffer is full, packets may be lost,
indicating congestion to the TCP sender.
1
Link layer buffer bad link
22
2 1
2
base 2
8/9/2012 station 49
In reality
• Most HDLC-like link layer protocols provide
reliability.
– Go-Back-N retransmission: in-order delivery
• If the wireless link is single hop which is the
case in most current wireless application
environment, the retransmission delay may
be small fraction of end-to-end TCP RTT
(TCP Round Trip Time) Round .
8/9/2012 50
TCP-aware link layer: Approach
• If link layer has different buffer per TCP
connection, then it can avoid the HOL blocking.
• The base station(BS) buffers frames. When it
receives dupacks from mobile host(MH), it
retransmit if the frame is still in buffer.
• BS prevents Fast Retransmit at the TCP sender
by dropping the dupacks.
• Snoop protocol is one that takes this approach.
8/9/2012 51
Continued …
Link layer buffer
per TCP connection
End-to-end TCP connection
application application application
transport transport transport
network network network
rxmt
link link link
physical physical physical
BS MH
wireless
8/9/2012 52
Continued …
TCP state
35
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
8/9/2012 53
Continued …
35
36
37
38
39
41 40 39 38
34 36
8/9/2012 54
Continued …
37
38
39
40
42 41 40 39
36 36
dupack
Duplicate acks are not delayed
8/9/2012 55
Continued …
37
38
39
40
41
43 42 41 40
36 36 36
Duplicate acks
8/9/2012 56
Continued … 37
38
39
40
41
42
44 43 37 41
FH BS MH
36 36
Discard
Dupack triggers retransmission dupack
of packet 37 from base station
36
BS needs to be TCP-aware to
be able to interpret TCP headers
8/9/2012 57
Continued … 37
38
39
40
41
42
43
45 44 42 37
36 36
36
36
8/9/2012 58
37
Continued … 38
39
40
41
42
43
44
46 45 43 42
36 41
TCP sender does not
36
fast retransmit
36
36
8/9/2012 59
37
38
Continued …
39
40
41
42
43
44
45
47 46 44 43
41
TCP sender does not 36
fast retransmit
36
36
8/9/2012 36 60
Continued …
42
43
44
45
46
48 47 45 44
FH BS MH
41 43
36
36
36
8/9/2012 36 61
Advantages
• It prevents Fast Retransmission despite
transmission error, and out-of-order
delivery on the wireless link.
– Selective Repeat can be used.
• If delay-bandwidth product in the wireless
link is less than 4 frames, a simple link
layer retransmission can be sufficient.
• End-to-end TCP semantics is preserved.
• Requires modification to only BS.
8/9/2012 62
Disadvantages
• Link layer at BS needs to be TCP-aware.
• It is not useful if TCP headers are
encrypted like using IPsec.
• It can be used if TCP data and TCP acks
traverse different paths, since both of them
do not go through the base station.
8/9/2012 63
Can TCP sender know the cause of
dupacks? Approach
• If the TCP sender can know that dupacks
are due to errors, it does not need to
reduce congestion window.
• Then is there any way of letting the sender
know the cause?
• Who guess the cause?
– Receiver-based
– Sender-based
– Wireless node-based
8/9/2012 64
Receiver-based approach
• The TCP receiver uses a heuristics to
guess the cause of packet loss.
• If the receiver guess that packet loss is
due to errors, it sends a notification to the
sender.
• The sender, on receiving the notification,
retransmits the lost packet, not reducing
congestion window.
8/9/2012 65
How can receiver know the cause?
• Receiver uses the inter-arrival time
between consecutively received packets to
guess the cause of packet loss.
8/9/2012 66
Packet loss due to Congestion
T
12 10
FH BS MH
11
Packet loss due to transmission error
2T
12 11 10
Error loss
FH BS MH
8/9/2012 67
Advantages
• It does not need any modification to TCP
at base station.
• But, obviously it has limited applicability,
since queuing delay for packets is not so
uniform.
8/9/2012 68
Sender-based approach
• The TCP sender guess the cause, using
statistics based on the information he can gather.
– RTT
– Congestion Window size(W)
– Loss pattern, etc
• Define condition C=f(RTT, W)
• If (C==True), reduces congestion window.
• C is calculated heuristically.
– Several proposals for condition C
8/9/2012 69
Disadvantages
• Unfortunately, correlation between RTT
and W is often weak.
• Statistics collected by the sender can be
garbled by other traffic on the network.
• The condition C should be changed
depending on the network states.
8/9/2012 70
Wireless node-based
• Wireless nodes determines that packets
are lost due to errors and informs the
sender using an explicit notification.
• The question is how the nodes can
determine that packets are lost due to
errors or congestion.
8/9/2012 71
Space Communication Protocol Standards-
Transport Protocol(SCPS-TP)
• The receiving ground station keeps track of how
many packets with errors are received.
• When error rate exceeds a threshold, the ground
station sends corruption-experienced messages
to the destinations.
Satellite wireless
TCP destinations
Ground station
8/9/2012 72
Continued …
• Then the TCP destination tag acks with
corruption-experienced bit.
• TCP sender receiving this bit does not
back off until it receives and ack without
this bit even if timeout or fast retransmit
occurs.
8/9/2012 73
When MH is 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, BS
compares the dupack sequence number with the
recorded holes. If there is a match, an ELN bit is et in the
dupack.
• When sender receives dupack with ELN bit 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
8/9/2012 Dupack with ELN set 74
When MH is TCP receiver
• If packet cannot be delivered using a small
number of retransmission, BS sends a
Explicit Bad State Notification(EBSN)
message to TCP sender.
– Ex, MH is passing through a tunnel.
• When TCP sender receives EBSN, it
resets its timer.
– Timeout delayed when wireless channel is in
bad state.
8/9/2012 75
Partial ACK
• Send two types of acks.
• A partial ack informs the sender that a packet was
received by BS.
• When a packet for which a partial ack is received is
detected to be lost, the sender does not reduce its
congestion window.
37 37
BS
37 37
Partial ack
8/9/2012 Cumulative ack 76
Concluding Remarks
• Need extra knowledge on wireless side to detect loss
due to wireless/mobility effects that is unconnected
to congestion.
• MH and/or AP may know such information.
• Approaches modify TCP on MH or introduce a
support protocol on AP (or do both).
– Doing anything on AP contradicts end-to-end principle.
• Some approaches only provide specific help. For
example, improvements only when MH is TCP
receiver or sender, but not both.
•
8/9/2012 77
