end-to-end protocols (udp, tcp, connection management)
DESCRIPTION
End-to-End Protocols (UDP, TCP, Connection Management). Demultiplexing: delivering received segments to correct app layer processes. Multiplexing/demultiplexing. 32 bits. - PowerPoint PPT PresentationTRANSCRIPT
1
End-to-End Protocols(UDP, TCP, Connection Management)
2
Multiplexing/demultiplexing
Multiplexing: gathering data from multiple app processes, enveloping data with header (later used for demultiplexing)
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
Demultiplexing: delivering received segments to correct app layer processes
3
Multiplexing/demultiplexing: Example
Web clienthost A
Webserver B
Web clienthost C
Source IP: CDest IP: B
source port: x
dest. port: 80
Source IP: CDest IP: B
source port: y
dest. port: 80
Web server
Source IP: ADest IP: B
source port: x
dest. port: 80
4
UDP: User Datagram Protocol [RFC 768]
Often used for streaming multimedia apps loss tolerant rate sensitive
Other UDP uses DNS SNMP
Reliable transfer over UDP: add reliability at application layer application-specific
error recover!
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksumLength, in
bytes of UDPsegment,including
header
5
UDP Checksum
Sender: treat segment contents
as sequence of 16-bit integers
checksum: addition (1’s complement sum) of segment contents
sender puts checksum value into UDP checksum field
Receiver: compute checksum of
received segment check if computed checksum
equals checksum field value: NO - error detected YES - no error detected.
But maybe errors nonethless? More later ….
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
6
TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581
A sliding window protocol providing reliable, in-order byte steam: no “message
boundaries” Flow controlled:
set window size according to the buffer size at the receiver
Congestion controlled set window size
according to the status of the network
End-to-end full duplex data transfer: one sender, one receiver bi-directional data flow
using the same connection
MSS: maximum segment size
Connection-oriented: Connection management
socketdoor
T C Psend buffer
T C Preceive buffer
socketdoor
segm ent
applicationwrites data
applicationreads data
7
TCP Segment Structure
source port # dest port #
32 bits
applicationdata
(variable length)
sequence number
acknowledgement numberrcvr window size
ptr urgent datachecksum
FSRPAUheadlen
notused
Options (variable length)RST, SYN, FIN:connection
management(reset, setup
teardowncommands)
# bytes rcvr willingto accept
ACK: ACK #valid
countingby bytes of data(not segments!)
Also in UDP
URG: urgent data (generally not used)
PSH: push data now(generally not used)
8
TCP Terminology: Seq. #’s and ACKs
Seq. #’s: byte stream
seq# of the first byte of a segment
ACKs: seq# of the next
byte expected from other side
cumulative ACK
If no data to send:Use the seq# of the next byte.
Host A Host B
Seq=42, ACK=79, data = ‘C’
Seq=43, ACK=80
Usertypes
‘C’
host ACKsreceipt
of echoed‘C’
host ACKsreceipt of
‘C’, echoesback ‘C’Seq=79, ACK=43, data = ‘C’
timesimple telnet scenario
Seq=80, ACK=43, data = ‘X’
Seq=43, ACK=81
Assume Host BSends data ‘x’Back to Host A
host ACKsReceipt
of echoed‘x’
9
Connection Management: Setup
The previous protocols assume we start with sequence number 0. Is there any problem with this approach?
The objectives of connection setup agree on initial sequence numbers agree on other initial parameters
10
Three Way Handshake (TWH) [Tomlinson 1975]
Host A
SYN(seq=x)
Host B
ACK(seq=x+1), SYN(seq=y)
ACK(seq=y+1)
DATA(seq=x+1)
SYN: indicates connection setup
11
Scenarios with Duplicate Request
Host A Host B
ACK(seq=x+1), SYN(seq=y)
REJECT(seq=y+1)
SYN(seq=x)
accept?
no suchrequest
reject
12
Scenarios with Duplicate Request/Reply
Host A Host B
ACK(seq=x+1), SYN(seq=y)
REJECT(seq=y+1)
SYN(seq=x)
accept?
no suchrequest
reject
ACK(seq=z)
13
Connection Management: Close
FIN: indicates connection close
Host A Host B
FIN
DATA
DATA
no data is deliveredafter FIN
14
The First Attempt: Agreeing on Connection Close
client
I am done. Are you done too?
server
I am done too. Goodbye!
init. close
close
close
Is this approach right?
15
Four Way Teardown
Host A
FIN
Host B
ACK
ACK
FIN
close
close
closed
tim
ed w
ait
16
%netstat --tcp -a CLOSED
LISTEN
SYN RCVD
SYN
SYN/ACK
ACK
CLOSED
SYN SENT
ESTABLSIHED
ESTABLSIHED
FIN
ACK
ACK
FINWAIT 1
ESTABLSIHED ESTABLSIHED
CLOSEWAIT
FINLASTACK
FINWAIT 2
TIMEWAIT
17
00 sendbase = initial_sequence number agreed by TWH01 nextseqnum = initial_sequence number by TWH
02 loop (forever) { 03 switch(event) 04 event: data received from application above05 if (window allow send)06 create TCP segment with sequence number nextseqnum06 start timer for segment nextseqnum 07 pass segment to IP08 nextseqnum = nextseqnum + length(data)
else put packet in buffer09 event: timer timeout for segment with sequence number y 10 retransmit segment with sequence number y 11 compute new timeout interval for segment y 12 restart timer for sequence number y13 event: ACK received, with ACK field value of y 14 if (y > sendbase) { /* cumulative ACK of all data up to y */ 15 cancel all timers for segments with sequence numbers < y 16 sendbase = y17 while (there are segments and window allow)18 sent a segment as in line 04;18 } 19 else { /* y==sendbase, duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */
TCP: reliable data transfer
SimplifiedTCPsender
18
TCP Receiver: ACK Generation [RFC 1122, RFC 2581]
Event
in-order segment arrival, no gaps,everything else already ACKed
in-order segment arrival, no gaps,one delayed ACK pending
out-of-order segment arrivalhigher-than-expect seq. #gap detected
arrival of segment that partially or completely fills gap
TCP Receiver action
delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK (this called delayed ACK)
immediately send singlecumulative ACK
send duplicate ACK, indicating seq. #of next expected byte
immediate ACK if segment startsat lower end of gap
Discussion: Why delayed ACKs?
19
TCP: Retransmission Scenarios
Host A
Seq=92, 8 bytes data
ACK=100
loss
tim
eout
time lost ACK scenario
Host B
X
Seq=92, 8 bytes data
ACK=100
Host A
Seq=100, 20 bytes data
ACK=100
Seq=
92
tim
eout
premature timeout,cumulative ACKs
Host B
Seq=92, 8 bytes data
ACK=120
Seq=92, 8 bytes data
Seq=
10
0 t
imeou
t
ACK=120
20
TCP Timeout
Q: how to set TCP timeout value?
too short: premature timeout unnecessary
retransmissions too long: slow reaction
to segment loss even worse: RTT
fluctuates
Q: how to estimate RTT? SampleRTT: measured time from
segment transmission until ACK receipt ignore retransmissions,
cumulatively ACKed segments
SampleRTT will vary, want a “smoother” estimated RTT use several recent
measurements, not just current SampleRTT
Using the average of SampleRTT will generate many timeouts due to network variations consider variance as well
RTT
RTT
freq.
21
TCP Timeout: Initial Timeout
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT exponential weighted moving average influence of given sample decreases exponentially fast typical value of x: 0.125
Estimate the variance of RTT
Timeout = EstimatedRTT + 4*Deviation
Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|
Estimate the average of RTT
Set initial timeout value
22
An Example of Initial Timeout
timeout value
per packet round-trip time
23
TCP Timeout: Repeated Retransmission
Exponential backoff: Double timeout value after each retransmission Max 64 seconds Max 12 restransmits Discussion: why exponential backoff?