chapter 5 tcp handshakes, sliding window flow control professor rick han university of colorado at...

Chapter 5TCP Handshakes, Sliding

Window Flow Control

Professor Rick HanUniversity of Colorado at Boulder

[email protected]

Prof. Rick Han, University of Colorado at Boulder

Announcements

• Read Sections 5.1 and 5.2, skip 5.3 and 5.4

• Homework #3 on Web, due March 12• Solutions to HW #2 and #3 available by

March 12 evening

• Programming Assignment #2 due Friday March 22 by 11:59 pm

• Midterm March 14• Through Chapter 4 Network Layer• Excluding 2.9 (network adaptors), 3.4

(switching hardware), and 4.4 (multicast)

• Next, more on TCP


Recap of Previous Lecture• UDP: Unreliable Datagram Protocol

• Transport layer above IP• Unreliable best-effort packet delivery service• 8 bytes of header

• Checksum includes prepended IP pseudo-header

• TCP: Transmission Control Protocol• Reliable in-order (byte stream) service or “pipe”• TCP Header:

• Sequence #’s in both directions (full-duplex)• Flow control window• Checksum

• TCP Connection Setup• Three-way Handshake


Two-Way Handshake

Handshake pictures courtesy of UMass Amherst


Two-Way Handshake: Failure


Two-Way Handshake W/ Timers


3-way Handshake: Unique ID’s

• Both sender and receiver choose unique ID’s to label their (x,y) connection• x chosen by Sender, y by receiver• Prevents Failure scenario in two-way handshakes

w/o timers

Client:(active)

Server(passive)


3-way Handshake: Prevents FailureChoose x, Send req_conn(x)

Send “accept connection”,Choose y, ACK x

ACK y, Send data (x+1)

Req_conn(x)

Acc_conn(x,y)

Timeout, resendreq_conn(x)

Data(x+1,y)Receive data

Connection closes

Req_conn(x)

Timeout, resendData(x+1)

Acc_conn(x,y’)

Send acc_conn,Choose unique y’Drop data packet fromold (x,y) connection,Accept only (x+N,y’)

Data(x+1,y)


3-way Handshake: TCP SYN/ACK

Both A and B choose Unique ID’s for the connection:x is starting sequence # for A->B, y is starting sequence # for B->A

TCPClient(active)

TCPServer(passive)


TCP Client/Server Connection• Server listens passively

• Socket(), bind(), listen(), accept()

• Client conducts active open• Socket(), bind(), connect()

• TCP maintains a Transmission Control Block (TCB) per connection• State of connection

• Macro: current state in state transition diagram• Micro: RTT, congestion window size, …

• Buffers: pointers to send and receive buffers

• Name a connection or TCP session with a 4-tuple• <source IP, source port, dest IP, dest port>• In UDP, socket buffer named by <dest IP, dest

port>


TCP State Machine: Connection Setup Only

CLOSED

SYNSENT

SYNRCVD

ESTAB

LISTEN

active OPENcreate TCBSend SYN

create TCB

passive OPEN

delete TCB

Appl: CLOSE

delete TCB

Appl: CLOSE or timeout

send SYN

Appl: wants to SEND

send SYN ACKrcv SYN

Send FINCLOSE

rcv ACK of SYNSend ACK + data

Rcv SYN, ACK

rcv SYN

snd SYN + ACK

Courtesy: Srini Seshan


TCP SYN Denial of Service Attack• Malicious client rapidly generates a large

number of SYN requests• Source IP address is random and forged• TCP server creates connection queue of half-open

connections, allocates data structure• Run out of data structures for half-open conn.’s

• New TCP connections to server can’t be made – Denial of service !

• Solutions: • If firewall stops SYN’s from outside, then OK• If no firewall, then increase size of connection

queue, or timeout more quickly when waiting for ACK from SYN/ACK

• Source filtering of spoofed IP addresses


Detecting Half-open Connections

1. (CRASH)2. CLOSED3. SYN-SENT <SEQ=400><CTL=SYN>4. (!!) <SEQ=300><ACK=100><CTL=ACK>5. SYN-SENT <SEQ=100><CTL=RST>6. SYN-SENT7. SYN-SENT <SEQ=400><CTL=SYN>

(send 300, receive 100) ESTABLISHED (??) ESTABLISHED (Abort!!) CLOSED

TCP BTCP A

A TCP connection is half-open if one end has closed or abortedthe connection without the knowledge of the other end, e.g. by crash


TCP Connection Tear-down: two FIN/FIN-ACK’s

Sender ReceiverFIN

FIN-ACK

FIN

FIN-ACK

Data write

Data ack

Half-closedCLOSE_WAITState (passive)

Either server or client can be sender and initiate FIN tear-down

LAST_ACK state

FIN_WAIT1

FIN_WAIT2

TIME_WAIT


TCP State Machine: Connection Tear-down

Only

CLOSING

CLOSEWAIT

FINWAIT-1

ESTAB

TIME WAIT

snd FIN

CLOSE

send FIN

CLOSE

rcv ACK of FIN

LAST-ACK

CLOSED

FIN WAIT-2

snd ACK

rcv FIN

delete TCB

Timeout=2*msl

send FIN

CLOSE

send ACK

rcv FIN

snd ACK

rcv FIN

rcv ACK of FIN

snd ACK

rcv FIN+ACK

Courtesy: Srini Seshan

Rcv ACK


Sequence Numbers• Data is viewed as a stream of bytes

– Each byte in byte stream is numbered, 32-bit, wraps around

– Initial values selected at start up time

• TCP breaks up the byte stream into segments– Sequence # of a segment is byte-stream # of 1st

byte– Variably sized, with Maximum Segment Size (MSS)– Segments passed down to IP– Segments are retransmitted

segment 13450

segment14950

segment 16050

13450 14950 16050 17550


Sequence Numbers (2)• Acknowledgements also have sequence #’s

– Cumulative ACK’s list the sequence # of the next byte they’re expecting

• if sequence # 13449 has been received, then put 13450 in cumulative ACK

• TCP resembles Go-Back N when using cumulative ACK’s

– Also, have semi-selective ACK’s • SACK-TCP


Sequence Numbers (3)• Finite Sequence # Wrap-Around

– Sequence # space (32 bits) must be greater than twice the window size – satisfied

– Sequence #’s must not be wrap around too quickly on high bandwidth Gbps links

• This is a problem, so there’s a TCP extension

– Advertised window must be greater than typical bandwidth*delay product, to fill pipe

• This is a problem, so there’s a TCP extension


Segments• When does a TCP sender know it should

send?– When MSS bytes have been accumulated– Application can force sending via PUSH– Periodic timer that forces transmission

• What does TCP do with out-of-order segments at receiver?– Could discard – inefficient– Could keep, introducing additional pointers at

receiver– TCP doesn’t specify!


TCP Flow Control• TCP is a sliding window protocol

– For window size n, can send up to n bytes without receiving an acknowledgement

– When the data is acknowledged then the window slides forward

• Each ACK advertises receiver’s window size in TCP header– Indicates number of bytes the receiver has

space for starting from the highest sequence # of ACK’ed data


Window Flow Control: Send Side

Sent but not acked Not yet sent

Flow control windowAdvertised by receiver

LastByteSent

Sent and acked

LastByteACKedby receiver

LastByteWritten

Window slidesAs data is ACK’ed


acknowledged sent to be sentoutside window

Source PortSource Port Dest. PortDest. Port

Sequence NumberSequence Number

AcknowledgmentAcknowledgment

HL/FlagsHL/Flags WindowWindow

D. ChecksumD. Checksum Urgent PointerUrgent Pointer

Options..Options..

Source PortSource Port Dest. PortDest. Port

Sequence NumberSequence Number

AcknowledgmentAcknowledgment

HL/FlagsHL/Flags WindowWindow

D. ChecksumD. Checksum Urgent PointerUrgent Pointer

Options..Options..

Packet Sent Packet Received

App write

Window Flow Control: Send Side


Acked but notdelivered to user

Rcvd notacked

Receive buffer

Flow control windowAdvertised to sender

Window Flow Control: Receive Side

LastByteRead NextByteExpected

ACKedanddelivered

LastByteReceived

Window slidesAs data is ACK’ed


TCP Persist• Flow control: slow receiver advertises 0

window, stopping a fast sender– Sender cannot send until it receives ACK from

receiver advertising window size > 0– What if this ACK is lost?

• Sender waits forever

• TCP Persist state– Sender periodically sends 1 byte packets to

force a new ACK– Receiver responds with ACK even if it can’t

store the packet– Sender no longer waits forever


TCP Adaptive Retransmission

• TCP achieves reliability by retransmitting segments after:– A Timeout– Receiving 3 duplicate cumulative ACK’s

• Two out-of-order segments arrive at receiver, but lowest unacknowledged segment has yet to arrive

• Receiver repeats its highest received cumulative sequence # -- hence duplicate cumulative ACK’s

• Doesn’t wait for timeout : “fast retransmit”

• Choosing the value of the Timeout – If too small, retransmit unnecessarily– If too large, poor throughput– Make this adaptive, to respond to changing congestion

delays in Internet


Initial Round-trip Estimator• Round trip times exponentially averaged:

– New RTT estimate = (old RTT estimate) + (1 - ) (new RTT)

– Recommended value for : 0.8 - 0.9• 0.875 for most TCP’s

• Retransmission Timeout RTO = RTT, where = 2– Thought to be large enough to provide enough

cushion to prevent spurious retransmissions– …and small enough to keep throughput high– Every time timer expires, retransmit segment


RTT Retransmission Ambiguity

A B

ACK

SampleRTT

Original transmission

retransmission

RTO

A B

Original transmission

retransmissionSampleRTT

ACKRTOX


Karn/Partridge’s modified RTT Estimator

• Basic problem: – If a sender has retransmitted a segment, then ACK

for that segment may correspond to any of the retransmissions

• Is RTT for first transmission or retransmission?

• Solution:– Each time a segment is retransmitted:

• Don’t average the RTT estimate with the current RTT sample

• Also, Double the RTO – exponential backoff like Ethernet

– If a segment has been transmitted only once and ACK’ed

• Recalculate RTT estimate


Jacobson/Karel’s Retransmission

Timeout• Key observation:

– Original smoothed RTT can’t keep up with wide/rapid variations in RTT

• Solution:– Base RTO on both the average RTT and

variance/standard deviation of RTT estimate– Objectives:

• When stddev is large, want RTO to stay above the fray and not timeout too often

– i.e. set RTO = Average RTT + N*stddev

• When stddev is small, stay close to average RTT


Jacobson/Karel’s Retransmission Timeout

(2)Err = current RTT – Ave RTT A

Next A = old A + g*Err, g=0.125

Next Std Dev D = old D + h*(|Err|-old D), h=0.25

RTO = A + 4 * Next D

chapter 5 tcp handshakes, sliding window flow control professor rick han university of colorado at...

Documents

boulder3way handshake

data x

failurechoose x

y connectionx

ack xack y

tcp handshakes

data structurerun

bouldertcp state machine