Transmission Control Protocol TCP (in Mobile Networks)

Integrated Communication Systems GroupIlmenau University of Technology

Transmission Control Protocol TCP(in Mobile Networks)

Mobile Communication Networks (RCSE)Winter Semester 2011/12

Integrated Communication Systems Group

Internet Protocol Suite

TCP/IP = the “Internet protocol suite“ = a family of protocols for the “Internet”

Internet guesstimates 2003: – 800 million users (x 2 each two years), 200 million permanent hosts

Standardisation:

– ISOC: Internet Society

– IAB: Internet Architecture Board• IETF: Internet Engineering Task Force: http://www.ietf.org

– Standards & other information are published as RFCs: Requests for Comments

• IRTF: Internet Research Task Force

Mobile Communication Networks (RCSE) 2


Internet Protocol Suite

Implementations:

– De-facto standard: BSD 4.x implementations (Berkeley Software Distribution)

– Subsequent versions come with new TCP features, e.g. 4.3 BSD Tahoe (1988): slow start, congestion avoidance, fast

retransmit4.3 BSD Reno (1990): fast recovery

– Other TCP/IP stacks derived from BSD

– Implemented mechanisms, default parameter settings, and bugs are different on different operating systems (e.g. versions of MS Windows)!



TCP (Transmission Control Protocol)

PropertiesConnection-oriented, reliable byte-stream service:– Reliability by ARQ (Automatic Repeat reQuest):

• TCP receiver sends acknowledgements (acks) back to TCP sender to confirm delivery of received data

• Cumulative, positive acks for all contiguously received data• Timeout-based retransmission of segments

– TCP transfers a byte stream:• Segmentation into TCP segments, based on MTU• Header contains byte sequence numbers

Congestion avoidance + flow control mechanism

In the following examples: – Packet sequence numbers (instead of byte sequence numbers)– ack i acknowledges receipt of packets through packet i (instead of

bytes)Mobile Communication Networks (RCSE) 4


TCP Connection Establishment and Termination


Client Server

Segment 3: ACK

Three-way handshake

*ISN: initial sequence number(RFC 793)

Segment 1: SYN + ISN* + options, e.g. MSS

Active open:

Segment 2: SYN, ACK + ISN + options, e.g. MSS

Passive open:

Application close => Segment 1: FIN

Active close: Passive close:

=> Send EOF to application

Segment 2: ACK; application can still send data

Half-close #1

Application close => Segment 3: FINSegment 4: ACK Half-close #2

=> Connection establishment & termination take at least 1 RTT


Cumulative Acknowledgements

A new cumulative ack is generated only on receipt of a new in-sequence segment


i data acki

TCPsender

TCPreceiverRouter40 39 3738

received:...3536

41 40 3839

35 373634

received:...353637

timestep3533 3634


Delayed Acknowledgements

Delaying acks reduces ack trafficAn ack is delayed until

– another segment is received, or– delayed ack timer expires (200 ms typical)


40 39 3738

3533

received:...3536

New ack not producedon receipt of segment 36,

but on receipt of 37

41 40 3839

35 37

received:...353637


Duplicate Acknowledgements 1

A dupack is generated whenever an out-of-order segment arrives at the receiver (packet 37 gets lost)


40 39 3738

3634

received:...36

42 41 3940

36 36

received:...36x38

dupackon receipt of 38

2 timesteps

packet loss



Dupacks are not delayedDupacks may be generated when

– a segment is lost (see previous slide), or– a segment is delivered out-of-order:


40 39 3837

3634

41 40 3739

36 36

dupackon receipt of 38

received:...36x

38

received:...36

1 timestep




40 37 3839

3634

41 40 3937

36 36

dupack

34

received:...36x38

received:...36

42 41 3740

36 36 36

dupackdupack

received:...36x3839

43 42 4041

36 36 39

new ackdupack

received:...36373839

36

dupack

Number of dupacks depends on how much out-of-order a packet is

A series of dupacks allows the sender to guess that a single packet has been lost


Packet Loss Detection Based on Timeout

TCP sender starts a timer for a segment (only one segment at a time) If ack for the timed segment is not received before timer expires,

outstanding data are assumed to be lost and retransmitted => go-back-N ARQ

Retransmission timeout (RTO) is calculated dynamically based on measured RTT:

– RTO = mean RTT + 4 * mean deviation of RTT• Mean deviation average of |sample – mean| is easier to calculate than

standard deviation (and larger, i.e. more conservative)– Large variations in the RTT increase the deviation, leading to larger RTO– 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



Exponential Backoff

Double RTO on successive timeouts:

Total time until TCP gives up is up to 9 minRationale: Allow an intermediate, congested router to recoverProblem: If ack is lost, TCP (sender) just waits for the next timeout


Segmenttransmitted

Timeout occursbefore ack received,

segment retransmitted

Timeout interval doubled

T1=RTO T2 = 2 * T1


Packet Loss Detection Based on Dupacks:Fast Retransmit Mechanism

TCP sender considers timeout as a strong indication that there is a severe link problem

On the other hand, continuous reception of dupacks indicates that following segments are delivered, and the link is ok

=> TCP sender assumes that a (single) packet loss has occurred if it receives three dupacks consecutively

=> Only the (single) missing segment is retransmitted => selective-repeat ARQ

Note: 3 dupacks are also generated if a segment is delivered at least 3 places out-of-order => Fast retransmit useful only if lower layers deliver packets “almost ordered” - otherwise, unnecessary fast retransmit



Window Based Flow Control 1

Sliding window protocol

Window size W is minimum of– receiver’s advertised window - determined by available buffer

space at the receiver and signaled with each ack– congestion window - determined by the sender, based on received

acksTCP’s window based flow control is “self-clocking”:

– New segments are sent when outstanding segments are ack’d


2 3 4 5 6 7 8 9 10 11 131 12

Sender’s window

Acks received Not transmitted


Window Based Flow Control 2

Optimum window size: – W = data rate * RTT = “bandwidth-delay product”

(optimum use of link capacity: “pipe is full”)


What if window size is too large? Queuing at intermediate routers (e.g. at wireless access point)

=> increased RTT due to queuing delays=> potential of packet loss

What if window size is too small? Inefficiency: unused link capacity

38 373940

3335

3436

TCPsender

TCPreceiverRouter

W = 8 segments (33...40)

packet dimensions:

rate

transmit time

size


Flow Control by the Sender


Slow StartInitially, congestion window size (cwnd) = 1 MSS Increment cwnd by 1 MSS on each new ackSlow start phase ends when cwnd reaches ssthresh (slow-start

threshold)=> cwnd grows exponentially with time during slow start (in theory)

– Factor of 1.5 per RTT if every other segment is ack’d– Factor of 2 per RTT if every segment is ack’d– In practice: increase is slower because of network delays

Congestion AvoidanceOn each new ack, increase cwnd by 1/cwnd segments=> cwnd grows linearly with time during congestion avoidance (in

theory)– 1/2 MSS per RTT if every other segment ack’d– 1 MSS per RTT if every segment ack’d


Slow Start & Congestion Avoidance – Theory

• Theoretical assumption: after sending n segments, n acks arrive within one RTT

• Note that Slow Start starts slowly, but speeds up quicklyMobile Communication Networks (RCSE) 17

02468

101214

0 1 2 3 4 5 6 7 8 9

Time / RTT

cwnd

(seg

men

ts)

Slow Start

CongestionAvoidance

ssthresh

Receiver’sadvertised window = 12


Congestion Control after Packet Loss

Packet loss detected by timeout (=> severe link problem):Retransmit lost segmentsGo back to Slow Start:

– Reduce cwnd to initial value of 1 MSS– Set ssthresh to half of window size before packet loss:

• ssthresh = max((min(cwnd, receiver’s advertised window)/2), 2 MSS)Packet loss detected by 3 dupacks (=> single packet loss, but link is ok):Fast Retransmit single missing segmentInitiate Fast Recovery:

– Set ssthresh and cwnd to half of window size before packet loss:• ssthresh = max((min(cwnd, receiver’s advertised window)/2), 2 MSS)• cwnd = ssthresh + number of dupacks

– When a new ack arrives: continue with Congestion Avoidance:• cwnd = ssthresh



Packet Loss Detected by Timeout


0

5

10

15

20

25

0 3 6 9 12 15 20 22 25

Time / RTT

cwnd

(seg

men

ts)

ssthresh = 8ssthresh = 10

cwnd = 20

Timeout

cwnd = 1


Packet Loss Detected by 3 Dupacks

• After fast retransmit and fast recovery window size is reduced in half

• Multiple packet losses within one RTT can result in timeoutMobile Communication Networks (RCSE) 20

0

2

4

6

8

10

0 2 4 6 10 12 14Time / RTT

cwnd

(seg

men

ts)

After Fast Recovery

ssthresh = 4

3 Dupacks

cwnd = 8

cwnd = 4


Influence of wireless transmission on TCP

• TCP assumes congestion if packets are dropped– typically wrong in wireless networks, here we often have packet loss

due to transmission errors– furthermore, mobility itself can cause packet loss, if e.g. a mobile

node roams from one access point (e.g. foreign agent in Mobile IP) to another while there are still packets in transit to the wrong access point and forwarding is not possible

• The performance of an unchanged TCP degrades severely– however, TCP cannot be changed fundamentally due to the large

base of installations in the fixed network, TCP for mobility has to remain compatible

– TCP on server does not know whether peers are mobile or not– the basic TCP mechanisms keep the whole Internet together



Indirect TCP – Principle

• Indirect TCP (I-TCP) segments the connection– no changes to the TCP protocol for hosts connected to the wired

Internet, millions of computers use (variants of) this protocol– optimized TCP protocol for mobile hosts– splitting of the TCP connection at, e.g., the foreign agent into 2 TCP

connections, no real end-to-end connection any longer– hosts in the fixed part of the net do not notice the characteristics of

the wireless part


mobile hostaccess point (foreign agent) „wired“ Internet

„wireless“ TCP standard TCP


Indirect TCP – Socket and state migration due to handover


mobile hostaccess point2

Internet

access point1

socket migrationand state transfer

A handover between access points requires the migration of the TCP socketsand the TCP state!


Indirect TCP – Discussion

• Advantages– no changes in the fixed network necessary, no changes for the hosts

(TCP protocol) necessary, all current optimizations to TCP still work– transmission errors on the wireless link do not propagate into the fixed

network– simple to control, mobile TCP is used only for one hop between, e.g., a

foreign agent and mobile host– therefore, a very fast retransmission of packets is possible, the short

delay on the mobile hop is known• Disadvantages

– loss of end-to-end semantics, an acknowledgement to a sender does now not any longer mean that a receiver really got a packet, e.g. wireless link may drop or foreign agent might crash

– higher latency possible due to buffering of data within the access point and forwarding to a new access point

– access point needs to be involved in security mechanisms (e.g. IPsec)



Snooping TCP – Principle

• „Transparent“ extension of TCP within the foreign agent– buffering of packets sent to the mobile host– lost packets on the wireless link (both directions!) will be retransmitted

immediately by the mobile host or foreign agent, respectively (so called “local” retransmission)

– the foreign agent therefore “snoops” the packet flow and recognizes acknowledgements in both directions, it also filters ACKs

– changes of TCP only within the foreign agent


„wired“ Internet

buffering of data

end-to-end TCP connection

local retransmission correspondenthostaccess

point

mobilehost

snooping of ACKs


Snooping TCP

• Data transfer to the mobile host– AP buffers data until it receives ACK of the MH, AP detects packet loss

via duplicated ACKs or timeout– fast retransmission possible, transparent for the fixed network

• Data transfer from the mobile host– AP detects packet loss on the wireless link via sequence numbers, AP

answers directly with a NACK to the MH– MH can now retransmit data with only a very short delay

• Integration of the link layer– link layer often has similar mechanisms to those of TCP

• Problems– snooping TCP does not isolate the wireless link as good as I-TCP– snooping might be useless depending on encryption schemes, e.g. does

not work with IPsec due to encryption of IP payload (including TCP segment number)



Mobile TCP

• Special handling of lengthy and/or frequent disconnections• M-TCP splits as I-TCP does

– unmodified TCP fixed network to supervisory host (SH)– optimized TCP between SH and MH (no slow start)

• Supervisory host (SH)– no caching, no retransmission (different from Indirect-TCP)– monitors all packets, if disconnection detected

• set sender window size to 0• sender automatically goes into persistent mode

– old or new SH reopens the window (set to old size)• Advantages

– maintains semantics, supports disconnection, no buffer forwarding• Disadvantages

– loss on wireless link propagated into fixed network (no buffering)– adapted TCP on wireless link



Forced fast retransmit/fast recovery

• Change of foreign agent often results in packet loss – TCP reacts with slow-start although there is no congestion

• Forced fast retransmit– as soon as the mobile host has registered with a new foreign agent

(Mobile IP), the MH sends duplicated acknowledgements on purpose– this forces the fast retransmit mode at the communication partners

(instead of slow start)– additionally, the TCP on the MH is forced to continue sending with the

actual window size and not to go into slow-start after registration

• Advantage– simple changes result in significant higher performance

• Disadvantage– focus on problems due to (fast) handover, not on temporarily poor

wireless link quality– mix of Mobile IP and TCP, no transparent approach



Transmission/timeout freezing

• Mobile hosts can be disconnected for a longer time– no packet exchange possible, e.g.,

discontinued communication in a tunnel disconnection due to overloaded cells preemption by higher priority traffic (scheduling)

– TCP disconnects after time-out completely• TCP freezing

– PHY/MAC layer is often able to detect interruption in advance– PHY/MAC can inform TCP layer of upcoming loss of connection– TCP stops sending, but does now not assume a congested link – PHY/MAC layer signals again if reconnected

• Advantage: scheme is independent of data • Disadvantage:

– TCP on mobile host has to be changed– mechanism depends on lower layers



Selective retransmission

• TCP acknowledgements are often cumulative– ACK n acknowledges correct and in-sequence receipt of packets up to n– if single packets are missing quite often a whole packet sequence

beginning at the gap has to be retransmitted (go-back-n), thus wasting bandwidth

• Selective retransmission as one solution– RFC2018 allows for acknowledgements of single packets, not only

acknowledgements of in-sequence packet streams without gaps– sender can now retransmit only the missing packets– mechanism is supported by newer TCP implementations

• Advantage– much higher efficiency

• Disadvantage– more complex software in a receiver, more buffers needed at the receiver



Transaction-oriented TCP

• TCP phases– connection setup, data transmission, connection release – using 3-way-handshake needs 3 packets for setup and release,

respectively– thus, even short messages need a minimum of 7 packets!

• Transaction oriented TCP– RFC1644, T-TCP, describes a TCP version to avoid this overhead– connection setup, data transfer and connection release can be

combined– thus, only 2 or 3 packets are needed

• Advantage– efficiency for TCP short connections

• Disadvantage– requires changed TCP on all hosts



Comparison of different approaches for a “mobile” TCP


Approach Mechanism Advantages Disadvantages Indirect TCP splits TCP connection

into two connections isolation of wireless link, simple

loss of TCP semantics, higher latency at handover

Snooping TCP “snoops” data and acknowledgements, local retransmission

transparent for end-to-end connection, MAC integration possible

problematic with encryption, bad isolation of wireless link

M-TCP splits TCP connection, chokes sender via window size

maintains end-to-end semantics, handles long term and frequent disconnections

bad isolation of wireless link, processing overhead due to bandwidth management

Fast retransmit/ fast recovery

avoids slow-start after roaming

simple and efficient mixed layers, not transparent

Transmission/ time-out freezing

freezes TCP state at disconnect, resumes after reconnection

independent of content or encryption, works for longer interrupts

changes in TCP required, MAC dependant

Selective retransmission

retransmit only lost data very efficient slightly more complex receiver software, more buffer needed

Transaction oriented TCP

combine connection setup/release and data transmission

efficient for certain applications

changes in TCP required, not transparent


References

• Jochen Schiller: Mobile Communications (German and English), Addison-Wesley, 2005 (chapter 9 provides an overview on different approaches)

• Ramjee Prasad, Marina Ruggieri: Technology Trends in Wireless Communications, Artech House, 2003

• The bible: W. Richard Stevens, “TCP/IP Illustrated, Volume 1: The Protocols“• Douglas E. Comer: Computernetzwerke und Internets. 3. Auflage, Pearson

Studium, Prentice Hall, 2002• Standards (RFCs): http://www.ietf.org/• Selected papers on TCP over wireless:

– Balakrishnan et al, “A comparison of mechanisms for improving TCP performance over wireless links”, IEEE/ACM Transactions on Networking, Dec. 1997

– Xylomenos et al, “TCP performance issues over wireless links”, IEEE Communications Magazine, April 2001

– Balakrishnan et al, “How network asymmetry affects TCP”, IEEE Communications Magazine, April 2001



Visitors address:Technische Universität IlmenauHelmholtzplatz 5Zuse Building, room 1066D-98693 Ilmenau

fon: +49 (0)3677 69 2788fax: +49 (0)3677 69 1226e-mail: [email protected]

www.tu-ilmenau.de/ics


PD Dr. rer. nat. habil. Oliver Waldhorst

Contact

Transmission Control Protocol TCP (in Mobile Networks)

Documents

Transcript of Transmission Control Protocol TCP (in Mobile Networks)