View
62
Download
0
Category
Preview:
Citation preview
End-to-End Protocols:
UDP and TCP
Hui Chen, Ph.D.
Dept. of Engineering & Computer Science
Virginia State University
Petersburg, VA 23806
11/14/2016 1CSCI 445 – Fall 2016
Acknowledgements
� Some pictures used in this presentation were obtained from
the Internet
� The instructor used the following references
� Larry L. Peterson and Bruce S. Davie, Computer Networks: A Systems
Approach, 5th Edition, Elsevier, 2011
� Andrew S. Tanenbaum, Computer Networks, 5th Edition, Prentice-
Hall, 2010
� James F. Kurose and Keith W. Ross, Computer Networking: A Top-
Down Approach, 5th Ed., Addison Wesley, 2009
� Larry L. Peterson’s (http://www.cs.princeton.edu/~llp/) Computer
Networks class web site
11/14/2016 CSCI 445 – Fall 2016 2
Acknowledgements
� Animations in the PDF version of the slides is
produced using
� PPspliT
� http://www.dia.uniroma3.it/~rimondin/downloads.php
11/14/2016 CSCI 445 – Fall 2016 42
Network Applications
Network
• Users make use of networks via network applications at hosts
• A hosts can run many network applications simultaneously
• Each application is one or more running programs (processes)
• Q: How processes share the underlying network layers?
11/14/2016 4CSCI 445 – Fall 2016
Transport Layer Services and Protocols
� provide logical communicationbetween application processes running on different hosts
� transport protocols run in end systems
� send side� breaks app messages
into segments, passes to network layer
� receive side: � reassembles segments
into messages, passes to app layer
� more than one transport protocol available to applications
� Internet: TCP and UDP
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
11/14/2016 5CSCI 445 – Fall 2016
Transport vs. Network Layer (1)
� network layer: logical
communication between
hosts
� transport layer: logical
communication between
processes
� relies on, enhances,
network layer services
Household analogy:
12 kids sending letters among
themselves via their parents
� processes = kids
� application messages = letters
in envelopes
� hosts = houses
� transport protocol = Ann and
Bill (parents)
� network-layer protocol = postal
service
11/14/2016 6CSCI 445 – Fall 2016
Transport vs. Network Layer (2)� Network layer: Underlying best-
effort network
� drop messages
� re-orders messages
� delivers duplicate copies of a given message
� limits messages to some finite size
� delivers messages after an arbitrarily long delay
� Transport Layer: Common end-to-end services
� guarantee message delivery
� deliver messages in the same order they are sent
� deliver at most one copy of each message
� support arbitrarily large messages
� support synchronization
� allow the receiver to flow control the sender
� support multiple application processes on each host
11/14/2016 7CSCI 445 – Fall 2016
Internet Transport-Layer Protocols
� Reliable, in-order delivery
(TCP)
� congestion control
� flow control
� connection setup
� Unreliable, unordered
delivery: UDP
� no-frills extension of
“best-effort” IP
� Services not available:
� delay guarantees
� bandwidth guarantees
applicationtransportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
applicationtransportnetworkdata linkphysical
11/14/2016 8CSCI 445 – Fall 2016
Multiplexing/Demultiplexing
Host-to-host delivery �� process-to-process delivery
11/14/2016 9CSCI 445 – Fall 2016
Multiplexing/Demultiplexing
= process= socket
delivering received segmentsto correct socket
Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data with
header (later used for demultiplexing)
Multiplexing at send host:
application
transport
network
link
physical
P1 application
transport
network
link
physical
application
transport
network
link
physical
P2P3 P4P1
host 1 host 2 host 3
Host-to-host delivery �� process-to-process delivery
11/14/2016 9CSCI 445 – Fall 2016
Simple Demultiplexer (1)
� Need to know to or from which process the data is
sent or come
� Identify processes on hosts
� How to identify processes on hosts?
� Introduce concept of “port”
� Q: why not to use process id?
11/14/2016 10CSCI 445 – Fall 2016
Simple Demultiplexer (2)
� How to identify processes on hosts?
� Q: why not to use process id?
� Introduce concept of “port”
� Endpoints identified by ports
� servers have well-known ports
� see /etc/services on Unix/Linux
� see C:\WINDOWS\system32\drivers\etc\services on MS Windows
Process 8
Host 1
Process 3
Host 2
Process 3 Process 8
11/14/2016 13CSCI 445 – Fall 2016
Simple Demultiplexer: UDP� Adds multiplexing to Internet Protocol
� Endpoints identified by ports (UDP ports)
� Demultiplex via ports on hosts
� Nothing more is added
� Unreliable and unordered datagram service
� No flow control
� User Datagram Protocol (UDP)
� A process is identified by <host, port>
� Connectionless model
� Header format
� Optional checksum
� psuedo header + UDP header + data
� pseudo header = protocol number + source IP address and destination IP address + UDP length field
From IP header
From UDP header
11/14/2016 14CSCI 445 – Fall 2016
Exercise L15-1
� Q1: How many UDP ports are there?
� Q2: How big are UDP headers?
� Q3: How much data does a UDP datagram can carry?
11/14/2016 15CSCI 445 – Fall 2016
Transmission Control Protocol (TCP)
� Connection-oriented
� Byte-stream
� applications writes bytes
� TCP sends segments
� applications reads bytes
� Full duplex
� Flow control: keep sender from overrunning receiver
� Congestion control: keep sender from overrunning network
11/14/2016 16CSCI 445 – Fall 2016
Data Link Versus Transport� Potentially connects many different hosts
� need explicit connection establishment and termination
� Potentially different RTT
� need adaptive timeout mechanism
� Potentially long delay in network
� need to be prepared for arrival of very old packets
11/14/2016 17CSCI 445 – Fall 2016
� Potentially different capacity at destination
� need to accommodate different node capacity
� Potentially different network capacity
� need to be prepared for network congestion
Segment Format (2)� Each connection identified with 4-tuple:
� (SrcPort, SrcIPAddr, DsrPort, DstIPAddr)
� Sliding window + flow control
� acknowledgment, SequenceNum, AdvertisedWinow
� Flags
� SYN, FIN, RESET, PUSH, URG, ACK
� Checksum
� pseudo header + TCP header + data
11/14/2016 19CSCI 445 – Fall 2016
Sequence and Acknowledgement
Numbers (1)
� Host A sends a file of 500,000 bytes over a TCP
connection with Maximum Segment Size (MSS) as
1,000 bytes to host B
� How many segments? 500,000/1,000 = 500
� Sequence number assignments
� Sequence number of 1st segment? 0
� Sequence number of 2nd segment? 1,000
� Sequence number of 3rd segment? 2,000
� ……
11/14/2016 20CSCI 445 – Fall 2016
Sequence and Acknowledgement
Numbers (2)� Scenario 1
� Host B received all bytes numbered 0 to 1,999 from host A
� What would host B put in the acknowledgement number field of the segment it sends to A?
� 2,000: the sequence number of the next byte host B is expecting
� Scenario 2
� Host B received two segments containing bytes from 0-999, and 2,000-2,999, respectively?
� What would host B put in the acknowledgement number field of the segment it sends to A?
� 1000: TCP only acknowledges bytes up to the first missing byte in the stream, and it is the next byte host B is expecting
� Scenario 3
� Host B received 1st segment containing bytes from 0-999. Somehow, next it received 3rd segment containing bytes from 2,000-2,999.
� What does host B in this case that the segments arrive out of order?� TCP does not specify how to deal with this situation. Hence, it is up to the implementation.
� Option 1: Host B immediately discards out-of-order segment � simple receiver design
� Option 2: Host B keeps the out-of-order segment and waits for missing bytes to fill in the gaps � more efficient on bandwidth utilization � taken in practice
11/14/2016 21CSCI 445 – Fall 2016
TCP is Connection-Oriented
� Keep track of states of receiver and sender
� Connection Establishment
� Connection Termination
� TCP finite state machine and state transition
11/14/2016 22CSCI 445 – Fall 2016
Connection Termination
client server
close
close
closed
tim
ed w
ait
11/14/2016 24CSCI 445 – Fall 2016
client
Connection Establishment and State Transition
server
client11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client server11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client
closed
server11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client
closed
server
closed
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client
closed
server
closedAction: passive open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client
closed
server
listenAction: passive open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client
closed
server
listenAction: passive openAction: active open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client
closed
server
listenAction: passive openAction: active open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client server
listenAction: passive open
SYN_SENT
Action: active open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client server
listenAction: passive open
SYN_SENT
Action: active open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client server
SYN_SENT
SYN_RECV
Action: active open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client server
SYN_SENT
SYN_RECV
Action: active open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client server
SYN_SENT
SYN_RECV
Action: active open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client server
SYN_RECV
Established
Action: active open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client server
SYN_RECV
Established
Action: active open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client server
SYN_RECV
Established
Action: active open
11/14/2016 CSCI 445 – Fall 2016 26
client
Connection Establishment and State Transition
server
client server
Established
Established
Action: active open
11/14/2016 CSCI 445 – Fall 2016 26
Connection Termination and State Transition (1)server
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition (1)server
close
close
closed
client
tim
ed w
ait
Client closes first
11/14/2016 CSCI 445 – Fall 2016 27
Connection Termination and State Transition
(2)
� This side closes first
� ESTABLISHED � FIN_WAIT_1 � FIN_WAIT_2 �
TIME_WAIT
� Other side closes first
� ESTABLISHED � CLOSE_WAIT � LAST_ACK � CLOSED
� Both sides close at the same time
� ESTABLISHED � FIN_WAIT_1 � CLOSING � TIME_WAIT
� CLOSED
11/14/2016 28CSCI 445 – Fall 2016
TCP Sliding Window: Why Different?
� Potentially connects many different hosts
� need explicit connection establishment and termination
� Potentially different RTT
� need adaptive timeout mechanism
� Potentially long delay in network
� need to be prepared for arrival of very old packets
11/14/2016 29CSCI 445 – Fall 2016
� Potentially different capacity at destination� need to accommodate different node
capacity
� Potentially different network capacity� need to be prepared for network
congestion
TCP Sliding Window: Reliable and
Ordered Delivery
� Sending side
� LastByteAcked ≤ LastByteSent
� LastByteSent ≤ LastByteWritten
� buffer bytes between LastByteAcked and LastByteWritten
Receiving sideLastByteRead < NextByteExpected
NextByteExpected ≤ LastByteRcvd +1buffer bytes betweenNextByteRead and
LastByteRcvd
TCP uses cumulative acknowledgements to acknowledge receiving of all the bytes up to the first missing byte
11/14/2016 30CSCI 445 – Fall 2016
TCP Flow Control (1)� receive side of TCP connection has
a receive buffer
� app process may be slow at reading from buffer
� speed-matching service: matching the send rate to the receiving app’s drain rate
sender won’t overflowreceiver’s buffer by
transmitting too much,too fast
flow control
11/14/2016 31CSCI 445 – Fall 2016
TCP Flow Control (2)� Send buffer size: MaxSendBuffer
� Receive buffer size: MaxRcvBuffer
� Receiving side
� LastByteRcvd - LastByteRead ≤ MaxRcvBuffer
� AdvertisedWindow = MaxRcvBuffer – ((NextByteExpected -1) -LastByteRead)) � maximum possible free space remaining in the buffer
� Sending side
� LastByteSent - LastByteAcked ≤ AdvertisedWindow� LastByteSent – LastByteAcked: unacknowledged bytes sender has put in TCP
� Otherwise, the sender may overrun the receiver
� EffectiveWindow = AdvertisedWindow - (LastByteSent -LastByteAcked) � how much data it can sent
� LastByteWritten - LastByteAcked ≤ MaxSendBuffer
� If the sender tries to write y bytes to TCP� block sender if (LastByteWritten - LastByteAcked) + y > MaxSenderBuffer
� Always send ACK in response to arriving data segment
� Persist when AdvertisedWindow = 0
11/14/2016 32CSCI 445 – Fall 2016
Flow Control and Buffering (3)
Dynamic buffer allocation. The arrows show the direction of transmission. An ellipsis (…) indicates a lost TCP segment
11/14/2016 33CSCI 445 – Fall 2016
Adaptive Retransmission: Original
Algorithm
� Measure SampleRTT for each segment/ACK pair
� Compute weighted average of RTT
� EstimatedRTT = α x EstimatedRTT + β x SampleRTT
� where α + β = 1
� α between 0.8 and 0.9
� β between 0.1 and 0.2
� Set timeout based on EstimatedRTT
� TimeOut = 2 x EstimatedRTT
11/14/2016 34CSCI 445 – Fall 2016
Example RTT estimation:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RT
T (
mil
lise
con
ds)
SampleRTT Estimated RTT
11/14/2016 35CSCI 445 – Fall 2016
Adaptive Retransmission: Karn/Partridge
Algorithm
� Do not sample RTT when retransmitting
� Double timeout after each retransmission
� Congestion is the most likely cause of lost segments � TCP should not react too aggressively to a timeout
Problem with original algorithmACK does not really acknowledge a transmission, it acknowledges the receipt of data � can not distinguish an ACK is for which transmission/retransmission of a
segment
11/14/2016 36CSCI 445 – Fall 2016
Jacobson/ Karels Algorithm� Previous approaches did not take the variance of the sample RTT into account
� If no variance, Estimated RTT is good enough, 2 × Estimated RTT is too pessimistic
� If variance large, timeout value should not be too dependent on Estimated RTT
� New Calculations for average RTT
� Difference = SampleRTT – EstimtaedRTT
� EstimatedRTT = EstimatedRTT + (δ x Difference)
� Deviation = Deviation + δ( |Difference| - Deviation)
� where δ is a factor between 0 and 1
� Consider variance when setting timeout value
� TimeOut = μ x EstimatedRTT + φ x Deviation
� where μ = 1 and φ = 4
� Notes
� algorithm only as good as granularity of clock (500ms on Unix)
� accurate timeout mechanism important to congestion control
11/14/2016 37CSCI 445 – Fall 2016
Solution: TCP Extensions
� Implemented as header options
� Store timestamp in outgoing segments � measure RTT
� Extend sequence space with 32-bit timestamp � protected against sequence number wrap-around
� Shift (scale) advertised window �keep the pipe full
� Selective acknowledgement (SAC) � acknowledge any additional (out-of-order) blocks of received data
TCP Extensions for High Performancehttp://tools.ietf.org/html/rfc1323
11/14/2016 40CSCI 445 – Fall 2016
Summary
� User Datagram Protocol
� Multiplexer/Demultiplexer for IP
� Transmission Control Protocol
� Reliable Byte Stream� Connection-oriented
� Connection establishment
� Connection termination
� Automatics Repeated-Request: ACKs and NACKs
� Flow-control
� Timeout value estimation
� Extensions
� Congestion control (future discussions)
11/14/2016 41CSCI 445 – Fall 2016
Recommended