Download TCP Connection: 3-way Handshake, Sequence Prediction, and State Machine and more Summaries Design in PDF only on Docsity!

TCP connection establishment (3-way handshake):

A (^) B

SYN = 1, Seq. No. = X

SYN = 1, Seq. No. = Y ACK = 1, Ack. No. = X + 1

ACK = 1, Ack. No. = Y + 1

• X, Y are chosen randomly → sequence number prediction
• piggybacking

2-person consensus problem: are A and B in agreement about the state of affairs after 3-way handshake?

−→ in general: impossible −→ can be proven −→ “acknowledging the ACK problem” −→ also TCP session ending −→ lunch date problem

Call Collision:

A (^) B

SYN = 1, Seq. No. = X

SYN = 1, Seq. No. = Y

SYN = 1, Seq. No. = Y Ack. No. = X + 1

SYN = 1, Seq. No. = X Ack. No. = Y + 1

−→ only single TCB gets allocated −→ unique full association

TCP connection termination:

.

..

A (^) B

Ack. No. = Y

Ack. No. = X + 1

Ack. No. = Y + 1

FIN = 1, Seq. No. = Y

FIN = 1, Seq. No. = X

Seq. No. = X + 1

• full duplex
• half duplex

More generally, finite state machine representation of TCP’s control mechanism:

−→ state transition diagram

Features to notice:

• Connection set-up:
  • client’s transition to ESTABLISHED state without ACK
  • how is server to reach ESTABLISHED if client ACK is lost?
  • ESTABLISHED is macrostate (partial diagram)
• Connection tear-down:
  • three normal cases
  • special issue with TIME WAIT state
  • employs hack

Basic TCP data transfer:

0K

0K

A (^) B

Ack = 1024, Win = 1024

Seq = 1024

Ack = 2048, Win = 0

Seq = 1024

Seq =

Seq = 0

Timer Expires;Retransmit

1K

1K

0K

2K

Ack = 2048, Win = 0 Ack = 2048, Win = 1024

TCP’s sliding window protocol

StreamByte

StreamByte

Receiver: NextByteExpected

LastByteRead LastByteRcvd

Sender:

LastByteAcked

LastByteSent

LastByteWritten

• sender, receiver maintain buffers MaxSendBuffer, MaxRcvBuffer

Note asynchrony between TCP module and application.

Sender side: maintain invariants

• LastByteAcked ≤ LastByteSent ≤ LastByteWritten
• LastByteWritten−LastByteAcked < MaxSendBuffer

−→ buffer flushing (advance window) −→ application blocking

• LastByteSent−LastByteAcked ≤ AdvertisedWindow

Thus,

EffectiveWindow = AdvertisedWindow− (LastByteSent − LastByteAcked)

−→ upper bound on new send volume

Actually, one additional refinement:

−→ CongestionWindow

EffectiveWindow update procedure:

EffectiveWindow = MaxWindow− (LastByteSent − LastByteAcked)

where

MaxWindow = min{ AdvertisedWindow, CongestionWindow }

How to set CongestionWindow.

−→ domain of TCP congestion control

Receiver side: maintain invariants

• LastByteRead < NextByteExpected ≤ LastByteRcvd + 1
• LastByteRcvd − NextByteRead < MaxRcvBuffer

−→ buffer flushing (advance window) −→ application blocking

Thus,

AdvertisedWindow = MaxRcvBuffer− (LastByteRcvd − LastByteRead)

Issues:

How to let sender know of change in receiver window size after AdvertisedWindow becomes 0?

• trigger ACK event on receiver side when AdvertisedWindow becomes positive
• sender periodically sends 1-byte probing packet

−→ design choice: smart sender/dumb receiver −→ same situation for congestion control

Silly window syndrome: Assuming receiver buffer is full, what if application reads one byte at a time with long pauses?

• can cause excessive 1-byte traffic
• if AdvertisedWindow < MSS then set AdvertisedWindow ← 0

Do not want to send too many 1 B payload packets.

Nagle’s algorithm:

• rule: connection can have only one such unacknowl- edged packet outstanding
• while waiting for ACK, incoming bytes are accumu- lated (i.e., buffered) ... compromise between real-time constraints and effi- ciency.

−→ useful for telnet-type applications

Sequence number wrap-around problem: recall sufficient condition

SenderWindowSize < (MaxSeqNum + 1)/ 2

−→ 32-bit sequence space/16-bit window space

However, more importantly, time until wrap-around im- portant due to possibility of roaming packets.

bandwidth time until wrap-around † T1 (1.5 Mbps) 6.4 hrs Ethernet (10 Mbps) 57 min T3 (45 Mbps) 13 min F/E (100 Mbps) 6 min OC-3 (155 Mbps) 4 min OC-12 (622 Mbps) 55 sec OC-24 (1.2 Gbps) 28 sec

Even more importantly, “keeping-the-pipe-full” consider- ation.

bandwidth delay-bandwidth product † T1 (1.5 Mbps) 18 kB Ethernet (10 Mbps) 122 kB T3 (45 Mbps) 549 kB FDDI (100 Mbps) 1.2 MB OC-3 (155 Mbps) 1.8 MB OC-12 (622 Mbps) 7.4 MB OC-24 (1.2 Gbps) 14.8 MB

−→ 100 ms latency

Also, throughput limitation imposed by TCP receiver window size.

−→ e.g., high-performance grid apps

RTT estimation

... important to not underestimate nor overestimate.

Karn/Partridge: Maintain running average with precau- tions

EstimateRTT ← α · EstimateRTT + β · SampleRTT

• SampleRTT computed by sender using timer
• α + β = 1; 0. 8 ≤ α ≤ 0 .9, 0. 1 ≤ β ≤ 0. 2
• TimeOut ← 2 · EstimateRTT or TimeOut ← 2 · TimeOut (if retransmit)

−→ need to be careful when taking SampleRTT −→ infusion of complexity −→ still remaining problems

Hypothetical RTT distribution:

RTT

Samples

RTT

Samples

−→ need to account for variance −→ not nearly as nice

Jacobson/Karels:

• Difference = SampleRTT − EstimatedRTT
• EstimatedRTT = EstimatedRTT + δ · Difference
• Deviation = Deviation+δ(|Difference|−Deviation)

Here 0 < δ < 1.

Finally,

• TimeOut = μ · EstimatedRTT + φ · Deviation

where μ = 1, φ = 4.

−→ persistence timer −→ how to keep multiple timers in UNIX