TCP over wireless links

Data Link Layer Deliver frames between nodes that are connected over a single link. Frame: a data unit delivered in the data link layer

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

Error control Error detection Error correction CRC Checksum Automatic Repeat Request (ARQ):retransmission Go-Back-N Selective Repeat(Request) Forward Error Correction (FEC)

Selective Repeat & Go-back-N (a) Selective Repeat (b) Go-Back-N I(0) I(1) I(2) I(3) I(4) I(5) I(6) I(7) I(0) I(1) I(2) I(3) I(4) I(5) I(6) I(7) I(23) ACK(1) ACK(1) 1 1 2 2 . . 3 3 Error on I(4) Error on I(4) NAK(4) 5 NAK(5) Retransmit all frames from I(4) 6 ACK(5) Retransmit only I(4) 4 4 7 5 6 7 sender는 window size 만큼의 프레임을 receiver의 응답없이 전송한다(sliding window flow control). 만약 receiver로 부터 전송된 프레임에 에러가 발생하였다는 신호를 받으면(NACK, REJECT 메세지) 에러가 발생한 프레임으로 다시 돌아가 그 프레임부터 이후의 프레임도 이미 전송을 했다고 하더라도 다시 재전송한다. Go-Back-N에서의 window size: 만약 3 bit의 sequence number를 사용할 경우 최대 sequence number는 8이 된다. 현재 frame 0을 전송하고 receiver로 부터 ACK 1을 받았다. 그리고 sender는 계속해서 1,2,3,4,5,6,7,0을 전송하고 receiver로 부터 ACK 1을 전송받았다면 이것이 방금 전송한 8 frame에 대한 응답인지 그전에 전송한 frame 0에 대한 duplicate 응답인지 구분할 수가 없다. 따라서 이러한 애매함을 해결하기위해서 다음과 같이 최대 window size를 사용한다. k bit의 sequence number를 사용한다면 최대 sequence number의 크기는 2k이지만, 최대 window size는 2k - 1이 된다. timeout ACK(2) Error on ACK(2) ACK(8) Error on ACK(8) timeout Retransmit from I(7) Retransmit only I(1) preserve frame order Frames out of order

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.

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 Ideal window size = max bandwidth(BW) * RTT

Ideal window size? RTT Window size W What if W < RTT*BW? Inefficiency (wasted bandwidth) What if W > RTT*BW? Queuing at intermediate routers and increasing RTT Potentially, packet loss RTT Window size W Amount of data To be transmitted

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.

Timeout results in Slow Start. Burst errors may cause timeouts. If a wireless link remains unavailable for extended duration, data of the window size will be lost. Ex, driving through a tunnel Timeout results in Slow Start. Slow Start reduces congestion window to 1 MSS, consequently decreasing throughput. Again, doing the Congestion Avoidance in response to errors is unnecessary.

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.

How to improve TCP performance over wireless links?

1st Approach: Simple Link Layer retransmission 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.

End-to-end TCP connection Link layer state End-to-end TCP connection wireless physical link network transport application rxmt In-order enforced

But, the problems… 1 Link layer buffer 1 bad link 2 2 2 1 2 base 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 1 bad link 2 2 2 1 2 base station

1 Link layer buffer 1 bad link 2 2 1 2 2 2 base station 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 1 bad link 2 2 1 2 2 2 base station

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.

2nd Approach: Simple LL retransmit + TL Delayed dupacks 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.

End-to-end TCP connection Link layer buffer End-to-end TCP connection physical link network transport application physical link network transport application physical link network transport application delay dupacks rxmt OOO permitted wireless BS MH

original ack 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. Link layer acks are not shown

BS buffer original ack 36 37 38 39 41 40 39 38 BS 34 36 original ack Removed from BS link layer buffer on receipt of a link layer ack (LL acks not shown in figure) 35

37 38 39 40 38 42 41 40 39 36 36 original ack dupack Duplicate acks are not delayed

37 38 39 40 38 41 39 43 42 41 40 Duplicate ack 1 Original ack 36 36 36 Duplicate ack 1 Original ack Duplicate ack 2

Base station retransmits 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.

37 38 40 39 41 42 40 43 41 45 44 42 37 dupacks Delayed dupacks 36 36

packet received before 37 41 42 43 44 46 45 43 42 36 41 Delayed dupacks are discarded if lost packet received before delay D expires TCP sender does not fast retransmit

Major characteristics It can allow out-of-order delivery at link layer, consequently avoiding HOL blocking at the link layer buffer. Right value of dupack delay D depends on the wireless link properties. In most cases this approach renders better performance than the 1st one.

3rd Approach: TCP-aware link layer 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.

End-to-end TCP connection Link layer buffer per TCP connection End-to-end TCP connection physical link network transport application physical link network transport application physical link network transport application rxmt wireless BS MH

Example assumes delayed ack - every other packet ack’d TCP state maintained at link layer 35 36 37 38 38 37 40 39 FH BS MH 34 36 Example assumes delayed ack - every other packet ack’d

35 36 37 38 39 41 40 39 38 34 36

Duplicate acks are not delayed 37 38 39 40 42 41 40 39 36 36 dupack Duplicate acks are not delayed

37 38 39 40 41 43 42 41 40 36 36 36 Duplicate acks

37 38 39 40 41 42 44 43 37 41 FH BS MH 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

37 38 39 40 41 42 43 45 44 42 37 36 36 36 36

37 38 39 40 41 42 43 44 46 45 43 42 36 41 TCP sender does not fast retransmit 36 36 36

37 38 39 40 41 42 43 44 45 47 46 44 43 41 TCP sender does not fast retransmit 36 36 36 36

42 43 44 45 46 48 47 45 44 FH BS MH 41 43 36 36 36 36

Major points 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.

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.

4th Split TCP connection End-to-end TCP connection is splitted into one connection on wired part and the other over wireless part. Split connection results in two different transport protocols for the two parts. flow, error control Packet size Timeout, etc

End-to-end TCP connection Per TCP connection End-to-end TCP connection physical link network transport application physical link network transport application physical link network transport application wireless BS MH

Certainly good performance can be achieved using appropriate BS-MH protocol.

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 36 40

Disadvantages(2) Hand-off latency increases due to state transfer. Packets that has been acked to sender must be moved to new base station. FH MH BS 40 39 37 38 36 New base station Hand-off

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.

5th Approach: Can TCP sender know the cause of dupacks? 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

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.

How can receiver know the cause? Receiver uses the inter-arrival time between consecutively received packets to guess the cause of packet loss.

Packet loss due to Congestion 12 10 FH BS MH 11 Packet loss due to transmission error 2 T 12 11 10 Error loss FH BS MH

Major points 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.

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

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.

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.

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

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.

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 Dupack with ELN set

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.

Partial ACK 37 BS 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 Cumulative ack