chapter 5 tcp handshakes, sliding window flow control professor rick han university of colorado at...
Post on 15-Jan-2016
228 Views
Preview:
TRANSCRIPT
Chapter 5TCP Handshakes, Sliding
Window Flow Control
Professor Rick HanUniversity of Colorado at Boulder
rhan@cs.colorado.edu
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
Two-Way Handshake
Handshake pictures courtesy of UMass Amherst
Prof. Rick Han, University of Colorado at Boulder
Two-Way Handshake: Failure
Prof. Rick Han, University of Colorado at Boulder
Two-Way Handshake W/ Timers
Prof. Rick Han, University of Colorado at Boulder
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)
Prof. Rick Han, University of Colorado at Boulder
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)
Prof. Rick Han, University of Colorado at Boulder
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)
Prof. Rick Han, University of Colorado at Boulder
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>
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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!
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
RTT Retransmission Ambiguity
A B
ACK
SampleRTT
Original transmission
retransmission
RTO
A B
Original transmission
retransmissionSampleRTT
ACKRTOX
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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
top related