Chapter 4
Transport Layer
CIS 81 Networking Fundamentals
Rick Graziani
Cabrillo College
graziani@cabrillo.edu
Spring 2010
This Presentation
 For a copy of this presentation and access to my web site for other
CCNA, CCNP, and Wireless resources please email me for a
username and password.
 Email: graziani@cabrillo.edu
 Web Site: www.cabrillo.edu/~rgraziani
2
Note
 This presentation is not in the order of the book or online curriculum.
 This presentation also contains information beyond the curriculum.
3
Transport Layer Overview
Transport Layer
TCP UDP
 Transport Layer:
 Responsible for creating and maintaining a logical connection
between the endpoints
 What are the two protocols at the transport layer?
 TCP – Transmission Control Protocol
 UDP – User Datagram Protocol
5
TCP Header
UDP Header
What is the application
PDU called?
or
What is the transport
PDU called?
Application
Header + data
PDU: Data
PDU: Segment
6
UDP
TCP/UDP
TCP/UDP
TCP
 The Layer 4 data stream is a:
 Logical connection between the endpoints
 Provides transport services
 End-to-end service
7
Reminder of encapsulation/decapsulation
IP
Header
Data Link
Header
IP Packet
Data Link
Trailer
Data Link
Header
IP Packet
Data Link
Trailer
Data Link
Header
IP Packet
Data Link
Trailer
Data Link
Header
IP
Header
TCP
Header
TCP
Header
HTTP
Header
Data Link
Trailer
Data Link
Header
HTTP
Header
Data
Data
Data Link
Trailer
8
Focus on Transport Layer
TCP
TCP
9
Transport Layer
www.cisco.com
TCP Segment
TCP Segment
TCP Segment
TCP Segment
 Primary responsibilities:
 Tracking the individual communication between applications
 Who is the client? Which application? Which process?
 Identifying the different applications (HTTP, FTP, etc.)
 Segmenting data
 Managing each segment
 Reassembling the segments
10
segment
segment
 What two protocols are at the Transport Layer?
 TCP
 UDP
 IP is a best-effort delivery service. What does that mean?
 No guarantees
 Best-effort service
 “Unreliable service”
 TCP/UDP is responsible for extending IP’s delivery service between two
end systems.
11
TCP vs. UDP
Why would any application use UDP?
What is the “cost” of all this reliability
and flow control of TCP?
Streaming media, real-time multiplayer
games and voice over IP (VoIP)
applications that do not require
reliability mechanisms and may even
be hindered by them.
 TCP provides:
 UDP provides:
 Reliable delivery
 Unreliable delivery
 Error checking
 No error checking
 Flow control
 No flow control
 Congestion control
 No congestion control
 Ordered delivery
 No ordered delivery
 Connection establishment
 No connection establishment
 Applications:
 Applications
 HTTP
 DNS (usually)
 FTP
 DHCP
 SMTP
 RTP (Real-Time Protocol)
 Telnet
 VoIP
 MSN messenger
12
HTTP
HTTP
SMTP
FTP
Cabrillo
Web
Server
TCP
TCP
TCP
TCP
TCP
TCP
ISP’s
Email
and FTP
Server
TCP
TCP
 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)
13
Port Numbers: TCP and UDP
UDP Header
TCP Header
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
HTTP is Port 80
16-bit Urgent Pointer
Options (if any)
Data (if any)
 Both TCP and UDP use ports (or sockets) numbers to pass information to the
upper layers.
15
The application this TCP
segment came from.
The application this TCP
segment is going to.
The application this TCP
segment came from.
The application this TCP
segment is going to.
16
Port numbers are used to
by the sender to tell the
receiver which network
application it should use
for the “Data”.
Port numbers are used by
the receiver so it knows
which application it should
send the “Data” to.
Application
Header + data
Port Number
Application
Header + data
Port Number
17
http://www.iana.org/assignments/port-numbers
 The Internet Assigned Numbers Authority (IANA) assigns port
numbers.
18
Well Known or Registered
Port Number
 Well Known Ports (Numbers 0 to 1023)
 Reserved for common services and
applications
 Client: TCP destination port
 Server: TCP source port
Well Known or Registered
Port Number
19
Well Known or Registered
Port Number
 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).
Well Known or Registered
Port Number
20
Private/Dynamic Port
Number
Well Known or Registered
Port Number
Well Known or Registered
Port Number
Private/Dynamic Port
Number
 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)
21
Client
Server
Telnet
22
Client TCP Header
0
15 16
1028
16-bit Source Port Number
31
16-bit Destination Port Number
23
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data for Telnet
Data (if any)
Client
 Client sends TCP segment with:
 Destination Port: 23 (Well known port number)
 Source Port: 1028 (Dynamic Port assigned by client)
Server
23
Server TCP Header
15 16
0
23
16-bit Source Port Number
31
16-bit Destination Port Number
1028
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data for Telnet
Data (if any)
Client
 Server responds with TCP segment with:
 Destination Port: 1028 (Dynamic Port assigned by client)
 Source Port: 23 (Well known port number)
Server
24
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)
25
49888
49890
 Same client to same server - Two different HTTP sessions
 Client: Same destination port
 Client: Different source ports to uniquely identify this web session.
26
49888
49890
C:\Users\rigrazia>netstat -n
Active Connections
TCP
or
UDP
Proto
TCP
TCP
Source Port
Local Address
192.168.1.101:49888
192.168.1.101:49890
C:\Users\rigrazia>
Destination Port
Foreign Address
198.133.219.25:80
198.133.219.25:80
Source IP
Connection State
State
TIME_WAIT
TIME_WAIT
Destination IP
27
192.168.1.101
Source
Port
49888
49890
Destination
Port
198.133.219.25
80
80
80
172.16.5.5
Source
Port
49888
www.cisco.com
What makes each connection unique? How does the server know
which source port 49888 is who?
 Connection defined by the pair of numbers:
 Source IP address, Source port (From Client to Server)
 Destination IP address, Destination port (From Server to
Client)
 Different connections can use the same destination port on server
host as long as the source ports or source IPs are different.
28
TCP
or
UDP
Connection State
Source IP
Destination IP
Source Port
Destination Port
www.google.com
www.cisco.com
netstat –n
 Note: When downloading a web document and its objects it is common that
there will be several TCP sessions created.
29
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.
30
Connectionless Transport: UDP
UDP
0
15
16-bit Source Port Number
16-bit UDP Length
16
?
31
16-bit Destination Port Number
16-bit UDP Checksum
Data (if any)
 What do you notice looking at the UDP protocol?
 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
32
UDP
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)





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
33
UDP
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)
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
34
UDP
0
Client
15
16
Server
31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Time
Data (if any)
 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.
35
UDP
0
Client
15
16
Server
31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Time
Data (if any)
 No connection state
 UDP does not maintain connection state as does TCP (coming)
 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
36
Note on 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.
37
Online Gaming
Question: Do the World
of Warcraft servers
use TCP or UDP?
Answer: TCP for game
data, UDP for voice
chat.
Why?
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.
38
UDP Checksum (FYI)
0
15
16
Client
Server
31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Time
Data (if any)
Cumulative Sum: 1100101011001010
1s complement:
0011010100110101
Total:
1111111111111111
 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.
39
UDP Checksum (FYI)
0
15
16
Client
Server
31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Time
Data (if any)
Cumulative Sum: 1100101011001010
1s complement:
0011000100110101
Total:
1111101111111111
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.
40
41
Connection-oriented Transport: TCP
TCP
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
 TCP provides reliable delivery on top of unreliable IP
 TCP provides:
 Reliable delivery
 Error checking
 Flow control
 Congestion control
 Ordered delivery
 Connection establishment
43
0
15 16
16-bit Source Port Number
TCP
31
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
 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
44
TCP: Connection Establishment
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
 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.
45
Three-way
Handshake
Web
Server
Client
SYN, SEQ=8563
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.)
SYN Received
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
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.
46
Three-way
Handshake
Web
Server
Client
SYN, SEQ=8563
SYN Received
SYN, ACK Received
0
15 16
16-bit Source Port Number
31
SYN, ACK,
SEQ=1678
ACK=8564
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
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
47
Three-way
Handshake
Client
Web
Server
SYN, SEQ=8563
SYN Received
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
SYN, ACK Received
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
ACK,
SEQ=8564
ACK=1679
SYN, ACK,
SEQ=1678
ACK=8564
ACK Received
Options (if any)
Data (if any)
HTTP Request
(GET)
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)
48
 Step 1: Client sends ISN, SEQ=8563 (last four digits)
49
 Step 2: Server responds with ACK=8564, own ISN, SEQ=1678
50
 Step 3: Client sends ACK=1679
51
 Client now sends HTTP Request (GET) to Web Server
52
TCP: Connection Termination
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
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.
53
Packet Tracer Exercise: TCP Connection and
Termination






Use your file for the Packet Tracer lab: PT-DHCP-DNS-HTTP
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?
54
Flow Control and Reliability
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
 Reliability
 Guaranteed delivery
 Flow Control
 Flow control makes sure these buffers do not receive more data than
the connection can handle.
55
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
Flow Control and Reliability
 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.
 Included in every TCP segment starting with three-way handshake.
 TCP is a full duplex service
 Client and server specify their own window sizes.
56
My Receive
Window: 5,000
Server’s Send
Window: 10,000
“I can send 10,000
bytes without hearing
an ACK, and I can
only receive 5,000
bytes at a time.”
My Receive
Window: 10,000
Client’s Send
Window: 5,000
“I can send 5,000
bytes without hearing
an ACK, and I can
only receive 10,000
bytes at a time.”
Receive Window
 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.
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.
57
Flow Control and Reliability
Application Data (100,000 bytes)
1-1000
TCP
1-1000
1001-2000
2001-3000
3001-4000
4001-5000
…
TCP Segment
 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 (To be completely accurate in the diagram the MSS would
include the data plus the TCP header.)
 Client
58
 Window Size of 5,000 bytes
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
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.
59
Client has a
Window Size of
5,000 bytes
MSS of 1,000 bytes
Web
Server
Client
Send
Window=5,000
SEQ=1 (to 1,000)
SEQ=1,001 (to 2,000)
SEQ=2,001 (to 3,000)
SEQ=3,001 (to 4,000)
SEQ=4,001 (to 5,000)
Send Window:
Byte 10,000
SEQ=5,001 (to 6,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)
Send Window:
Byte 15,000
….
 This is known as a
ACK=5,001
Stop-and-Wait
windowing protocol.
 Server must wait for
acknowledgment
before continuing to
send data.
 A better method?
 Sliding Windows
 Next!
 Send Window Byte: ACK=10,001
This is the last byte
that can be sent
before receiving an
ACK
SEQ=10,001 (to 11,000)
60
Send
SEQ=1 – 1,0001
SEQ=1,001 – 2,000
SEQ=2,001 – 3,000
SEQ=3,001 – 4,000
SEQ=4,001 – 5,000
Send Window:
Byte 10,000
SEQ=5,001 – 6,000
SEQ=6,001 – 7,000
SEQ=7,001 – 8,000
SEQ=8,001 – 9,000
SEQ=9,001 – 10,000
Send Window:
Byte 15,000
….
Client
TCP Window Size
 TCP provides fullduplex service,
which means data
can be flowing in
each direction,
independent of the
other direction.
 Receiver sends
acceptable
window size to
ACK=5,001
sender during
each segment
transmission (flow
control)
 If too much data
being sent,
acceptable
window size is
reduced
 If more data can
be handled,
ACK=10,001
acceptable
window size is
increased
Web Window=5,000
Server
SEQ=10,001 – 11,000
61
Sliding Windows
Initial Window size
Usable Window
Working Window size
Octets sent Usable Window
Can send ASAP
Not ACKed Can send ASAP
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.
62
0
15 16
31
16-bit Source Port Number
TCP Header
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
Host A - Sender
Host B - Receiver
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
Window size = 6
Octets sent
Usable Window
Not ACKed
Can send ASAP
Octets received
3
1
2
3
4
5
6
7
8
9
10
11
12
13
ACK 4

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.
63
Host A - Sender
Host B - Receiver
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
1
2
3
4
5
6
7
8
9
10
11
12
13
1
ACK 4
2
3
4
5
6
7
8
9
10
11
12
13
4
5
1
2
3
4
5
6
7
8
9
10
11
12
13
1
Window size = 6
Octets sent
Usable Window
Not ACKed
Can send ASAP


2
3
4
5
6
7
8
9
10
11
12
13
ACK 6
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.
64
Host A - Sender
Host B - Receiver
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
Window size = 6
1
2
Octets sent
Usable Window
Not ACKed
Can send ASAP
3
1
2
3
4
5
6
7
8
9
10
11
12
13
1
ACK 4
2
3
4
5
6
7
8
9
10
11
12
13
4
5
1
2
3
4
5
6
7
8
9
10
11
12
13
1
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
ACK 6
6
7
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
8
9
More sliding windows
1
2
3
4
5
6
7
8
9
10
11
12
13
65
 Default 8K for Windows, 32K for Linux,
 There are various unix/linux/microsoft programs that allow you to modify the default
window size.
 I do not recommend that you mess around with this unless you know what you are doing.
 “Disclaimer: Modifying the registry can cause serious problems that may
require you to reinstall your operating system. We cannot guarantee that
problems resulting from modifications to the registry can be solved. Use the
information provided at your own risk.”
 NOTE: I take no responsibility for this software or any others!
66
Web
Server
Client
Web Server has a:
MSS of 1000 bytes
Send
Window=5,000
Send Window: Byte 5,000
SEQ=1 – 1,000
Client has a
Window Size of
5,000 bytes ACK=2,001
SEQ=1,001 – 2,000
SEQ=2,001 – 3,000
SEQ=3,001 – 4,000
SEQ=4,001 – 5,000
SEQ=5,001 – 6,000
Send Window:
Byte 7,000
2,001 to 7,000
SEQ=6,001 – 7,000
ACK=6,001
SEQ=7,001 – 8,000
SEQ=8,001 – 9,000
SEQ=9,001 – 10,000
Send Window:
Byte 11,000
6,001 to 11,000
Etc.
 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
67
Reliable Data Transfer
My reliable puppy Luigi
 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 see three simple examples to explain how this works.
 The last two examples are FYI.
68
Scenario 1: Loss of an ACK
 Web Server sends data. Client
 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
Web
Server
Timeout
X
(loss)
(TCP
Retransmission
Timer)
69
FYI Scenario 2: ACK arrives after timer expires
Client
 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
Web
Server
seq 92
Timeout
(TCP
Retransmission
Timer)
seq 92
Timeout
This ACK tells
the Web Server
that both
segments have
been received.
70
FYI Scenario 3: Loss of first ACK
Web
Server
Client
 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
X
(TCP
Retransmission
Timer)
(loss)
71
A few more notes on Window Size, Timers, etc.
0
15 16
16-bit Source Port Number
4-bit Header
Length
6-bit
(Reserved)
31
16-bit Destination Port Number
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32-bit Sequence Number
32 bit Acknowledgement Number
32 bit Acknowledgement Number
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Options (if any)
Data (if any)
Data (if any)
 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.
72
A few more notes on Window Size, Timers, etc.
0
15 16
16-bit Source Port Number
4-bit Header
Length
6-bit
(Reserved)
31
16-bit Destination Port Number
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32-bit Sequence Number
32 bit Acknowledgement Number
32 bit Acknowledgement Number
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Options (if any)
Data (if any)
Data (if any)
 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.
 Could be a sign of congestion.
 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.
73
Web
Server
Client
Web Server has a:
MSS of 1000 bytes
Send
Window=5,000
SEQ=1 – 1,000
Client has an initial
Window Size of
5,000 bytes
SEQ=1,001 – 2,000
Send Window:
Byte 5,000
SEQ=2,001 – 3,000
ACK=2,001
Window=7,000
SEQ=3,001 – 4,000
SEQ=4,001 – 5,000
SEQ=5,001 – 6,000
SEQ=6,001 – 7,000
ACK=6,001
Window=9,000
Send Window:
Byte 9,000
2,001 to 9,000
(Win=7,000)
SEQ=7,001 – 8,000
SEQ=8,001 – 9,000
Send Window:
Byte 15,000
SEQ=9,001 – 10,000
6,001 to 15,000
SEQ=10,001 –
(Win=9,000)
11,000
Etc.
 Client increases its Window Size.
 Send Window Byte: This is the last byte that can be sent before receiving
an ACK
74
Last few notes
Whew!
 This has been a very brief look at TCP.
 TCP has many components, some of which we have started to become
familiar with.
 Some other TCP topics which may be of interest to you:
 Slow Start
 SACK
 NAK
 Timer calculations
 Congestion algorithms and windows
75
UDP and TCP
TCP
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
UDP
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
 UDP provides:
 Unreliable delivery
 No error checking
 No flow control
 No congestion control
 No ordered delivery
 (No connection
establishment)
 TCP provides:
 Reliable delivery
 Error checking
 Flow control
 Congestion control
 Ordered delivery
 (Connection establishment)
76
Note of Interest – TCP Reset
Hey, I’m sending segments
but I’m not getting any
Acks. I’m going to reset this
connection.
0
15 16
16-bit Source Port Number
31
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header
Length
6-bit
(Reserved)
U A P R S F
R C S S Y I
G K H T N N
16-bit TCP Checksum
16-bit Window Size
16-bit Urgent Pointer
Options (if any)
Data (if any)
 If a station involved in a TCP session notices that it is not receiving
acknowledgements for anything it sends, the connection is now
unsynchronized, and the connection should send a reset.
 Issues:
 TCP Reset Attacks: http://kerneltrap.org/node/3072
 ISP’s resetting user sessions:
http://www.youtube.com/watch?v=FrmS19ej73E
77
Computer Networking
TCP/IP Illustrated, Vol. 1
W. Richard Stevens
Addison-Wesley Pub Co
ISBN: 0201633469
 Although, published in 1994, written
by the late Richard Stevens, it is still
regarded as the definitive book on
TCP/IP.
James Kurose and Keith Ross
ISBN 0321227352

University level text book
 Variety of networking topics.
 An excellent extension to CIS
81 material
78
Tech Note (FYI)
 Sender: The value in the sequence number is the first byte in the data stream.
 So, how does the receiver know how much data was sent, so it knows what value to send
in the acknowledgement?
 Receiver: Using the sender’s IP packet and TCP segment information, the value of the
ACK is:
IP Length: (IP header) Total length - Header length
- TCP header length (TCP header): Header length
------------------------------------------------Length of data in TCP segment
ACK = Last Sequence Number acked + Length of data in TCP
segment
 Check Sequence Number to check for missing segments and to
sequence out-of-order segments.
 Remember that the ACK is for the sequence number of the byte you
expect to receive. When you ACK 101, that says you've received all
79
bytes through 100. This ignores SACK.
TCP MSS defines the
maximum size of the data
in the TCP segment.
20 octets 20 octets
1460 octets
Ethernet MTU defines the
maximum size of the data in
the Ethernet frame.
TCP MSS = 1460
Data = 1460 octets
1500 octets
The host using Ethernet, MTU of 1500
octets so I will set my MSS to 1460.
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)80
Chapter 4
Transport Layer
CIS 81 Networking Fundamentals
Rick Graziani
Cabrillo College
graziani@cabrillo.edu