Upload
nguyenanh
View
248
Download
2
Embed Size (px)
Citation preview
Chapter 4
Transport Layer
João José
http://w3.ualg.pt/~jjose/cisco/
Based on:
Graziani, R. (2008) CIS 81 Networking Fundamentals
Cisco CCNA 1 Exploration - Networking
Transport Layer Overview
Transport Layer
The Layer 4 data stream is a:
logical connection between the endpoints of a network,
provides transport services from a host to a destination.
End-to-end service.
The transport layer also provides two protocols
TCP – Transmission Control Protocol
UDP – User Datagram Protocol
PDU: Segment
TCP UDP
TCP Header UDP Header
DataHTTP
Header
TCP
Header
IP
Header
Data Link
Header
Data Link
Trailer
IP PacketData Link
Header
Data Link
TrailerIP PacketData Link
Header
Data Link
Trailer
IP PacketData Link
Header
Data Link
TrailerIP PacketData Link
Header
Data Link
Trailer
IP PacketData Link
Header
Data Link
TrailerIP PacketData Link
Header
Data Link
Trailer
Reminder of encapsulation/decapsulation
DataHTTP
Header
TCP
Header
IP
Header
Data Link
Header
Data Link
Trailer
Transport Layer
Primary responsibilities:
Tracking the individual communication between applications
Segmenting data
Managing each segment
Reassembling the segments
Identifying the different applications
Transport Layer
Protocols:
TCP
UDP
IP is a best-effort delivery service
No guarantees
Best-effort service
“Unreliable service”
TCP/UDP is responsible for extending IP‟s delivery service between two
end systems.
Known as transport layer multiplexing and demultiplexing.
segment segment
TCP vs. UDP
TCP provides:
Reliable delivery
Error checking
Flow control
Congestion control
Ordered delivery
(Connection establishment)
Applications:
HTTP
FTP
Telnet
MSN messenger
UDP provides:
Unreliable delivery
No error checking
No flow control
No congestion control
No ordered delivery
(No connection establishment)
Applications
DNS (usually)
SMTP
DHCP
RTP (Real-Time Protocol)
VoIP
A single client may have multiple transport connections with multiple servers.
Notice that TCP is a connection-oriented service (two-way arrow) between the hosts, whereas UDP is a connectionless service (one-way arrow) . (later)
TCP
TCP
TCP
TCP
TCP
TCP
HTTPHTTP
FTP
UDP
SMTP
UDP
Cabrillo
Web
Server
ISP’s
and FTP
Server
Port Numbers: TCP and UDP
Both TCP and UDP use ports (or sockets) numbers to pass information to the
upper layers.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
TCP Header
HTTP is Port 80
UDP Header
Application
Header + dataPort numbers are used to
know which application
the receiving host should
send the “Data”.
Application
Header + dataPort numbers are used to
know which application
the receiving host should
send the “Data”.
http://www.iana.org/assignments/port-numbers
The Internet Assigned Numbers Authority (IANA) assigns port
numbers.
Well Known Ports (Numbers 0 to 1023)
Reserved for common services and applications.
HTTP (web server), POP3/SMTP (e-mail server) and Telnet.
Client: TCP destination port
Server: TCP source port
Registered Ports (Numbers 1024 to 49151)
Assigned to user processes or applications.
Non-common applications.
Client: TCP destination port
Server: TCP source port
May also be used as dynamic or private port (next).
Dynamic or Private Ports (Numbers 49152 to 65535)
Also known as Ephemeral Ports
Usually assigned dynamically to client applications when initiating a
connection.
Client: TCP source port
Server: TCP destination port
May also include the range of Registered Ports (Numbers 1024 to
49151)
Note: Some peer-to-peer file sharing programs use these ports as
Register Ports. (previous slide)
Client sends TCP segment with:
Destination Port: 23 (Well known port number)
Source Port: 1028 (Dynamic Port assigned by client)
Client TCP Header0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
231028
Data for Telnet
Client Server
Server responds with TCP segment with:
Destination Port: 1028 (Dynamic Port assigned by client)
Source Port: 23 (Well known port number)
Server TCP Header0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
102823
Data for Telnet
Client Server
Notice the difference in how source and destination port numbers are used with clients and servers:
Client (initiating Telnet service):
Destination Port = 23 (telnet)
Source Port = 1028 (dynamically assigned)
Server (responding to Telnet service):
Destination Port = 1028 (source port of client)
Source Port = 23 (telnet)
Same client to same server - Two different HTTP sessions
Client: Same destination port
Client: Different source ports to uniquely identify this web session.
4989049888
C:\Users\rigrazia>netstat -n
Active Connections
Proto Local Address Foreign Address State
TCP 192.168.1.101:49888 198.133.219.25:80 TIME_WAIT
TCP 192.168.1.101:49890 198.133.219.25:80 TIME_WAIT
C:\Users\rigrazia>
TCP
or
UDP
Source Port
Destination IP
Destination Port Connection State
Source IP
4989049888
What makes each connection unique?
Connection defined by the pair of numbers:
Source IP address, Source port
Destination IP address, Destination port
Different connections can use the same destination port on server host as long as the source ports or source IPs are different.
192.168.1.101
172.16.5.5
Destination
Port
80
80
80
Source
Port
49890
49888
Source
Port
198.133.219.2549888
www.cisco.com
Note: When downloading a web document and its objects it is common that
there will be several TCP sessions created.
netstat –n www.cisco.comwww.google.com
TCP
or
UDP Source Port
Destination IP
Destination Port
Connection StateSource IP
Using NetStat
Open a web browser.
Open a command prompt window (Start->Run->cmd)
Enter a URL of your choice.
Type netstat –n in the command window.
Questions:
What is/are the source ports on your client?
What is/are the destination ports on your client?
What would be the source port(s) on the server?
What would be the destination port(s) on the server?
What application layer protocol is being used? How can you tell?
What transport layer protocol is being used?
Trying more at home:
Use netstat to look at other networking applications such as FTP
or Telnet.
Connectionless Transport: UDP
UDP
No frills, barebones transport protocol.
Destination and Source Ports
Length and Checksum (used for error checking)
RFC 768
Connectionless transport
No “handshaking” (no connection establishment) as with TCP (coming)
Unreliable delivery
No error checking
No flow control
No congestion control
No ordered delivery
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
UDP
source port -- the number of the calling port
destination port -- the number of the called port
UDP length -- the length of the UDP header
checksum -- the calculated checksum of the header and data fields
data -- upper-layer protocol data
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
UDP
Why would an application developer choose UDP rather than TCP?
Finer application-layer control
TCP will continue to resend segments that are not acknowledged.
Applications that use UDP can tolerate some data loss:
Streaming video
VoIP (Voice over IP)
Application decides whether or not to resend entire file: TFTP
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
UDP
No connection establishment
TCP uses a three-way handshake to establish a connection (coming)
UDP does not – it just blasts away the data to the sender.
No delay to establish connection.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
Time
Client Server
UDP
No connection state
UDP does not maintain connection state as does TCP (coming)
Connection state is used for reliability and flow control.
Server can support more active clients when not maintaining state
information
Small packet header overhead
TCP header has 20 bytes of overhead.
UDP header has only 8 bytes of overhead
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
Time
Client Server
UDP
Note: Multimedia Applications and UDP
There is an issue (controversy) with multimedia applications over UDP.
UDP offers no congestion control (as we will see with TCP)
Congestion control is needed to prevent the network from entering and staying in a congested state.
If all applications were using UDP, because of congestion, very few UDP packets would be delivered and this would also cause TCP traffic rates to dramatically decrease.
Many applications give you a choice of TCP or UDP.
Online Gaming
Game data – Server and client need make sure all data (moves,
actions, etc) reach the other end reliably.
Voice chat – Some missing data can be tolerated (up to a point).
Retransmission would cause delay.
Question: Do the World
of Warcraft servers
use TCP or UDP?
Answer: TCP for game
data, UDP for voice
chat.
Why?
UDP Checksum (FYI)
UDP checksum provides error detection, any changed bits or missing segments.
Simplified explanation (see RFC 1071 for more details):
Sender
UDP adds 16 bit „words‟ keeping a cumulative sum.
Performs one's complement of the sum of all the 16-bit words in the segment.
Convert 0‟s to 1‟s and 1‟s to 0‟s
This result is put in the checksum field of the UDP segment.
Receiver
UDP adds 16 bit „words‟ keeping a cumulative sum
Adds 1’s (ones) complement
If no errors are introduced into the segment, then the Total at the receiver will be 1111111111111111.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
Time
Client Server
Cumulative Sum: 1100101011001010
1s complement: 0011010100110101
Total: 1111111111111111
UDP Checksum (FYI)
What if there is an error?
UDP does nothing to recover the error.
It is up to the application layer protocol (example TFTP) to decide what to do, such as prompt the user to download/upload the entire file again.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
Time
Client Server
Cumulative Sum: 1100101011001010
1s complement: 0011000100110101
Total: 1111101111111111
Connection-oriented Transport: TCP
TCP
TCP provides reliable delivery on top of unreliable IP
TCP provides:
Reliable delivery
Error checking
Flow control
Congestion control
Ordered delivery
Connection establishment
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
TCP
source port -- the number of the calling port
destination port -- the number of the called port
sequence number -- the number used to ensure correct sequencing of the arriving data
acknowledgment number -- the next expected TCP octet
HLEN -- the number of 32-bit words in the header
reserved -- set to 0
code bits -- the control functions (e.g. setup and termination of a session)
window -- the number of octets that the sender is willing to accept
checksum -- the calculated checksum of the header and data fields
urgent pointer -- indicates the end of the urgent data
option -- one currently defined: maximum TCP segment size
data -- upper-layer protocol data
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
TCP: Connection Establishment
For a connection to be established, the two end stations must synchronize
on each other's TCP initial sequence numbers (ISNs).
Sequence numbers :
Track the order of packets
Ensure that no packets are lost in transmission.
The initial sequence number is the starting number used when a TCP
connection is established.
Exchanging beginning sequence numbers during the connection sequence
ensures that lost data can be recovered.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
Three-way
Handshake
Step 1:
The three-way handshake happens before any data, HTTP Request (GET), is sent by the client.
A TCP client begins the three-way handshake by sending a segment with the SYN (Synchronize Sequence Number) control flag set, indicating an initial value in the sequence number field in the header.
The sequence number is the Initial Sequence Number (ISN), is randomly chosen and is used to begin tracking the flow of data from the client to the
server for this session.
Client
SYN, SEQ=8563
SYN Received
Web
Server
Note: ISNs do not start a 0 or 1.
There are several reasons for
this including segments that may
still be in buffers and also
security issues. (Beyond the
scope of this presentation.)
Three-way
Handshake
Step 2:
The TCP server needs to acknowledge the receipt of the SYN segment.
Server sends a segment back to the client with:
ACK flag set indicating that the Acknowledgment number is significant.
The value of the acknowledgment number field is equal to the client initial sequence number plus 1.
This is called an expectational acknowledgement – the next byte this host expects to receive (more soon).
SYN flag is set with its own random ISN for the Sequence number
Client
SYN, SEQ=8563
SYN, ACK,
SEQ=1678
ACK=8564
SYN Received
SYN, ACK Received
Web
Server
Three-way
Handshake
Step 3:
TCP client responds with a segment containing an ACK that is the
response to the TCP SYN sent by the server.
The value in the acknowledgment number field contains one more than the
initial sequence number received from the server.
The client can now send application data encapsulated in TCP segment.
HTTP Request (GET)
Client
SYN, SEQ=8563
SYN, ACK,
SEQ=1678
ACK=8564ACK,
SEQ=8564
ACK=1679
SYN Received
SYN, ACK Received
ACK Received
Web
Server
HTTP Request
(GET)
Step 1: Client sends ISN, SEQ=8563 (last four digits)
Step 2: Server responds with ACK=8564, own ISN, SEQ=1678
Step 3: Client sends ACK=1679
Client now sends HTTP Request (GET) to Web Server
TCP: Connection Termination
1. When the client has no more data to send in the stream, it sends a segment
with the FIN flag set.
2. The server sends an ACK to acknowledge the receipt of the FIN to terminate
the session from client to server.
3. The server sends a FIN to the client, to terminate the server to client session.
4. The client responds with an ACK to acknowledge the FIN from the server.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
Packet Tracer Exercise: TCP Connection and
Termination
Download the file: PT-DHCP-DNS-HTTP.pkt
Open Packet Tracer (wait for green lights then click on Simulation mode)
Edit Filters: TCP, DNS, HTTP
On a client, open a web browser and type www.cabrillo.edu
Click Capture/Forward to watch the packets and examine the protocols.
Why didn‟t a TCP 3-way handshake happen before the client sent a DNS
request to the DNS server?
Why did a TCP 3-way handshake happen before the client sent a HTTP
Request message to the web server?
Flow Control and Reliability
Reliability
Guaranteed delivery - making sure all the data was received.
If missing data, determining which bytes need to be retransmitted.
Flow Control
Each host has a receive buffer for the TCP connection.
Flow control makes sure these buffers do not receive more data than the connection can handle.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
Flow Control and Reliability
The receiving host's TCP layer reports a window size to the sending
host's TCP layer.
This window size specifies the number of bytes, starting with the
acknowledgment number, that the receiving host's TCP layer is currently
prepared to receive.
Window size is included in every TCP segment sent from client or server
starting with three-way handshake.
TCP is a full duplex service, client and server specify their own window
sizes.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
Receive Window
The TCP Receive Window size: Amount of receive data (in bytes) that can be buffered by this host, at one time on a connection.
Sending host can send only that amount of data before getting an acknowledgment and window update from this (the receiving) host.
Send Window (not a TCP field)
The TCP Receive Window size of the other host.
How much data (in bytes) that can be sent by this host before receiving an acknowledgement from the other host.
Client Example
Receive Window Size=5,000 bytes – Server can only send 5,000 bytes before it receives an acknowledgement.
Send Window Size = 10,000 bytes – Server told the client that it can send the server 10,000 bytes before receiving an acknowledgment.
Server‟s Send
Window: 10,000
My Receive
Window: 10,000My Receive
Window: 5,000
Client‟s Send
Window: 5,000
“I can send 10,000
bytes without hearing
an ACK, and I can
only receive 5,000
bytes at a time.”
“I can send 5,000
bytes without hearing
an ACK, and I can
only receive 10,000
bytes at a time.”
Flow Control and Reliability
Application Data (100,000 bytes)
1-1000 1001-2000 2001-3000 3001-4000 4001-5000
Flow control and reliability are intertwined .
When TCP has a large file (such an image) it breaks it into equal chunks, with
the last chunk typically smaller.
Each chunk of data with TCP header is known as a segment.
The size of the chunk is known as the MSS (Maximum Segment Size)
TCP Options field (later)
In the following example:
Web Server has a:
MSS of 1000 bytes
Client
Window Size of 5,000 bytes
…
TCP 1-1000 TCP Segment
Sequence Number and Acknowledgements
Remote host sends TCP segments with a Sequence Number.
Note: This is the first byte in the of data in the segment.
The receiving host:
Determines the number of bytes in the segment (FYI later).
Sends an ACK (Acknowledgement) back to the remote host, with the last byte received + 1.
The sending host cannot send any data past the Send Window (the window size sent by the receiving host) until it receives an ACK from the receiver.
This is an expectational acknowledgments, meaning that the acknowledgment number refers to the next byte that the sender of the acknowledgement expects to receive.
A larger window size allows more data to be transmitted pending acknowledgment.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
This is known as a
Stop-and-Wait
windowing protocol.
Server must wait for
acknowledgment
before continuing to
send data.
A better method?
Sliding Windows
Next!
Send Window Byte:
This is the last byte
that can be sent
before receiving an
ACK
Client
SEQ=1,001 (to 2,000)
Web
Server
SEQ=2,001 (to 3,000)
SEQ=3,001 (to 4,000)
SEQ=4,001 (to 5,000)
ACK=5,001
SEQ=1 (to 1,000)
SEQ=6,001 (to 7,000)
SEQ=7,001 (to 8,000)
SEQ=8,001 (to 9,000)
SEQ=9,001 (to 10,000)
ACK=10,001
SEQ=5,001 (to 6,000)
….
Send Window:
Byte 10,000
Send Window:
Byte 15,000
SEQ=10,001 (to 11,000)
Send
Window=5,000
Client has a
Window Size of
5,000 bytes
MSS of 1,000 bytes
TCP Window Size
TCP provides full-duplex service, which means data can be flowing in each direction, independent of the other direction.
Receiver sends acceptable window size to sender during each segment transmission (flow control)
If too much data being sent, acceptable window size is reduced
If more data can be handled, acceptable window size is increased
Client
SEQ=1,001 – 2,000
Web
Server
SEQ=2,001 – 3,000
SEQ=3,001 – 4,000
SEQ=4,001 – 5,000
ACK=5,001
SEQ=1 – 1,0001
SEQ=6,001 – 7,000
SEQ=7,001 – 8,000
SEQ=8,001 – 9,000
SEQ=9,001 – 10,000
ACK=10,001
SEQ=5,001 – 6,000
….
Send Window:
Byte 10,000
Send Window:
Byte 15,000
SEQ=10,001 – 11,000
Send
Window=5,000
Sliding Window Protocol
Sliding window algorithms are a method of flow control for network data transfers using the receivers Window size.
The sender computes its usable window, which is how much data it can immediately send.
Over time, this sliding window moves to the rights, as the receiver acknowledges data.
The receiver sends acknowledgements as its TCP receive buffer empties.
The terms used to describe the movement of the left and right edges of this sliding window are:
1. The left edge closes (moves to the right) when data is sent and acknowledged.
2. The right edge opens (moves to the right) allowing more data to be sent. This happens when the receiver acknowledges a certain number of bytes received.
3. The middle edge open (moves to the right) as data is sent, but not yet acknowledged.
Octets sent
Not ACKed
Usable Window
Can send ASAP
Working Window size
Usable Window
Can send ASAP
Initial Window size
Sliding Windows
1 2 3 4 5 6 7 8 9 10 11 12 13
2
3
Host B gives Host A a window size of 6 (octets).
Host A begins by sending octets to Host B: octets 1, 2, and 3 and slides it‟s
window over showing it has sent those 3 octets.
Host A will not increase its usable window size by 3, until it receives an
ACKnowldegement from Host B that it has received some or all of the octets.
Host B, not waiting for all of the 6 octets to arrive, after receiving the third octet
sends an expectational ACKnowledgement of “4” to Host A.
ACK 4
Octets sent
Not ACKed
Usable Window
Can send ASAP
Window size = 6 Octets received
1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
1
Host A - Sender Host B - Receiver
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
TCP Header
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
2
3
ACK 4
Host A does not have to wait for an acknowledgement from Host B to keep
sending data, not until the window size reaches the window size of 6, so it
sends octets 4 and 5.
Host A receives the acknowledgement of ACK 4 and can now slide its window
over to equal 6 octets, 3 octets sent – not ACKed plus 3 octets which can be
sent asap.
4
5
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
ACK 6
Octets sent
Not ACKed
Usable Window
Can send ASAP
Window size = 6
1
1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
Host B - ReceiverHost A - Sender
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
2
3
ACK 4
More sliding windows
4
5
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
ACK 6
Octets sent
Not ACKed
Usable Window
Can send ASAP
1 2 3 4 5 6 7 8 9 10 11 12 13
7
6
9
8
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
1
Host B - ReceiverHost A - Sender
Window size = 6
Client
SEQ=1,001 – 2,000
Web
Server
SEQ=2,001 – 3,000
SEQ=3,001 – 4,000
SEQ=4,001 – 5,000
ACK=2,001
SEQ=1 – 1,000
SEQ=6,001 – 7,000
SEQ=7,001 – 8,000
SEQ=8,001 – 9,000
SEQ=9,001 – 10,000
Etc.
SEQ=5,001 – 6,000
ACK=6,001
Web Server has a:
MSS of 1000 bytes
Client has a
Window Size of
5,000 bytes
SEQ=10,001 – 11,000
Send Window: Byte 5,000
Send Window:
Byte 7,000
2,001 to 7,000
Send Window:
Byte 11,000
6,001 to 11,000
Server can now continue sending without having to wait for an
acknowledgement.
Send Window Byte: This is the last byte that can be sent before receiving
an ACK
Send
Window=5,000
Reliable Data Transfer
TCP‟s reliable data service is on top of IP‟s unreliable, best-effort service.
TCP uses a single retransmission timer for all of it‟s segments within a
TCP connection.
How this timer is calculated is beyond the scope of this presentation
(too many slides already )
See RFC 2988
The TCP retransmission timer is associated with the oldest
unacknowledged segment sent.
We will use three simple examples to explain how this works.
Client Web
Server Web Server sends data.
Starts TCP retransmission
timer.
Client:
Segment received
Sends ACK
But ACK from Client gets
lost (dropped somewhere)
Web Server
Waiting for ACK.
TCP Retransmission
Timer expires.
Retransmits segment.
Client
Receives segment but
discards it.
Resends ACK
Web Server
Receives ACK
X (loss)
Timeout
(TCP
Retransmission
Timer)
Scenario 1: Loss of an ACK
Client Web
Server Web Server:
Sends 2 segments
Starts timer for oldest segment, SEQ=92
Waits for ACK
Client:
Receives both segments
Sends 2 separate ACKs
Web Server:
Neither ACK has arrived yet
Timer for SEQ=92 expires
Resends segment SEQ=92
Restarts timer for SEQ=92
As long as the ACK for the second segment arrives before the new timeout expires, the second segment will not be retransmitted.
Client:
Receives retransmitted SEQ=92 segment.
Discards segment
Re-sends ACK=120 for next byte needed
seq 92
Timeout
seq 92
Timeout
(TCP
Retransmission
Timer)
This ACK tells
the Web Server
that both
segments have
been received.
Scenario 2: ACK arrives after timer expires
Client Web
Server Web Server:
Sends 2 segments
Starts timer for oldest segment, SEQ=92
Waits for ACK
Client:
Receives both segments
Sends 2 separate ACKs
ACK for first segment, ACK=100, is lost
Web Server:
Before timer expires for SEQ=92 ACK
(ACK=100), receives ACK=120
Web Server knows that Client has
received everything up to byte 119.
Does not need to resend either of the two
segments.
seq 92
Timeout
(TCP
Retransmission
Timer)
Scenario 3: Loss of first ACK
X (loss)
A few more notes on Window Size, Timers, etc.
Both hosts in the TCP connection constantly advertise their Window Size to the
remote host in each segment sent.
Remember, TCP is a full duplex service – data can be sent and received in
both directions.
Receive Window Size may be increased or decreased due to flow control
(buffers) or congestion (network).
The effects on TCP are very similar.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
A few more notes on Window Size, Timers, etc.
The host may reduce it‟s Window Size if:
ACKs not arriving before retransmission timer expires or not arriving at all.
This may also cause the host to increase it‟s retransmission timer
interval.
Receive buffers are decreasing, filling up.
The host may increase it‟s Window Size if:
ACKs are received before retransmission timer expires
Receive buffers are increasing, less bits to process.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
Client
SEQ=1,001 – 2,000
Web
Server
SEQ=2,001 – 3,000
SEQ=3,001 – 4,000
SEQ=4,001 – 5,000
ACK=2,001
Window=7,000
SEQ=1 – 1,000
SEQ=6,001 – 7,000
SEQ=7,001 – 8,000
SEQ=8,001 – 9,000
SEQ=9,001 – 10,000
Etc.
SEQ=5,001 – 6,000
ACK=6,001
Window=9,000
Web Server has a:
MSS of 1000 bytes
Client has an initial
Window Size of
5,000 bytes
SEQ=10,001 –
11,000
Send Window:
Byte 5,000
Send Window:
Byte 9,000
2,001 to 9,000
(Win=7,000)
Send Window:
Byte 15,000
6,001 to 15,000
(Win=9,000)
Client increases its Window Size.
Send Window Byte: This is the last byte that can be sent before receiving
an ACK
Send
Window=5,000
TCP MSS = 1460
Data = 1460 octets
20 octets 20 octets 1460 octets
1500 octets
Determining TCP MTU
Typically, an end system uses the "outgoing interface MTU" minus 40 as its reported MSS.
For example, an TCP over IP over Ethernet MSS value is 1460 (1500 - 40 = 1460).
When a host (usually a PC) initiates a TCP session with a server, it negotiates the TCP segment size by using the maximum segment size (MSS) option field in the TCP SYN packet. (curriculum say IP segment).
The value of the MSS field is determined by the maximum transmission unit (MTU) configuration on the host.
The default Ethernet MTU value for a PC is 1500 bytes. (curriculum says MSS)
TCP MSS defines the
maximum size of the data
in the TCP segment.
Ethernet MTU defines the
maximum size of the data in
the Ethernet frame.
The host using Ethernet, MTU of 1500
octets so I will set my MSS to 1460.
This presentation is available at:
http://w3.ualg.pt/~jjose/cisco/
Original presentations from:
http://www.cabrillo.edu/~rgraziani/
Cisco curriculum available at:
http://cisco.netacad.net (Internet Explorer recommended)
After login, under: “Course Materials”