Cis81 E1 4 TransportLayer

Chapter 4 Transport Layer
CIS 81 Networking Fundamentals Rick Graziani Cabrillo College graziani@cabrillo.edu Last Updated: 3/2/2008
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
Note
This presentation is not in the order of the book or online curriculum. This presentation also contains information beyond the curriculum.
Transport Layer Overview
Transport Layer
TCP UDP
The Layer 4 data stream is a logical connection between the endpoints of a network, and provides transport services from a host to a destination. This service is sometimes referred to as end-to-end service. The transport layer also provides two protocols TCP Transmission Control Protocol UDP User Datagram Protocol
TCP Header
UDP Header
or
Application Header + data
UDP
TCP/UDP
TCP/UDP
TCP
Reminder of encapsulation/decapsulation
Data Link Header IP Header TCP Header HTTP Header
Data
Data Link Trailer
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
HTTP Header
Data
Data Link Trailer
Focus on Transport Layer

TCP
TCP
Transport Layer
The Transport layer provides for the segmentation of data and the control necessary to reassemble segments. Primary responsibilities: Tracking the individual communication between applications on the source and destination hosts Segmenting data Managing each segment Reassembling the segments into streams of application data Identifying the different applications
10
segment
segment
Transport Layer Protocols: TCP UDP Transport layer referred to as a segment IP is a best-effort delivery service No guarantees Best-effort service Unreliable service TCP/UDP is responsible for extending IPs delivery service between two end systems to a delivery service between two process running on the end systems. Known as transport layer multiplexing and demultiplexing.
11
TCP vs. UDP
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 SMTP Telnet RTP (Real-Time Protocol) MSN messenger VoIP
12
HTTP
HTTP SMTP FTP Cabrillo Web Server TCP TCP TCP TCP TCP UDP TCP UDP
ISPs Email and FTP Server
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 16-bit Source Port Number 15 16 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 Window Size
HTTP is Port 80
16-bit Urgent Pointer
16-bit TCP Checksum
Options (if any)
Data (if any)
Both TCP and UDP use ports (or sockets) numbers to pass information to the upper layers.
15
Port numbers are used to know which application the receiving host should send the Data.
Port numbers are used to know which application the receiving host should send the Data.
16
17
http://www.iana.org/assignments/port-numbers
The Internet Assigned Numbers Authority (IANA) assigns port numbers.

18
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 Client applications can be programmed to request a connection to that specific port and its associated service.
19
Registered Ports (Numbers 1024 to 49151) Assigned to user processes or applications. Primarily individual applications that a user has chosen to install rather than common applications that would receive a Well Known Port. When not used for a server resource, these ports may also be used dynamically selected by a client as its source port.
20
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 It is not very common for a client to connect to a service using a Dynamic or Private destination port (although some peer-to-peer file sharing programs do). May also include the range of Registered Ports (Numbers 1024 to 49151)
21
Client
Server
Telnet
22
Client TCP Header

0 15 16 16-bit Source Port Number 31 16-bit Destination Port Number
1028
23

16-bit Window Size
16-bit TCP Checksum
Options (if any)
Data for Telnet
Data (if any)
Client
Server
Client sends TCP segment with: Destination Port: 23 (Well known port number) Source Port: 1028 (Dynamic Port assigned by client)
23
Server TCP Header 15 16

16-bit Source Port Number 32-bit Sequence Number
31
23
16-bit Destination Port Number
1028

16-bit Window Size
16-bit TCP Checksum
Options (if any)
Data for Telnet
Data (if any)
Client
Server
Server responds with TCP segment with: Destination Port: 1028 (Dynamic Port assigned by client) Source Port: 23 (Well known port number)
24
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)
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
Source Port
Destination Port
Connection State
TCP or UDP
Proto TCP TCP
Local Address 192.168.1.101:49888 192.168.1.101:49890
Foreign Address 198.133.219.25:80 198.133.219.25:80
State TIME_WAIT TIME_WAIT
C:\Users\rigrazia>
Source IP
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? 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.
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
Connectionless Transport: UDP
UDP
0 16-bit Source Port Number 15 16 16-bit Destination Port Number 31 16-bit UDP Length 16-bit UDP Checksum
Data (if any)
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
31
UDP
0 16-bit Source Port Number 15 16 16-bit Destination Port Number 31
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
32
UDP
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
33
UDP
Client
Server
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.
34
UDP
Client
Server
Time
Data (if any)
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
35
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.
36
UDP Checksum (FYI)

Client
Server
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 0s to 1s and 1s to 0s This result is put in the checksum field of the UDP segment. Receiver UDP adds 16 bit words keeping a cumulative sum Adds 1s (ones) complement If no errors are introduced into the segment, then the Total at the receiver will be 1111111111111111.
37
UDP Checksum (FYI)

Client
Server
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.
38
39
Connection-oriented Transport: TCP
TCP
0 16-bit Source Port Number 15 16 31 16-bit Destination Port Number 32-bit Sequence Number

16-bit Window Size
16-bit TCP Checksum
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
41
0 16-bit Source Port Number
15 16
31 16-bit Destination Port Number
TCP
4-bit Header Length 6-bit (Reserved)
32 bit Acknowledgement Number

16-bit Window Size
16-bit TCP Checksum
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
42
TCP: Connection Establishment


16-bit Window Size
16-bit TCP Checksum
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.
43
Three-way Handshake
Client
SYN, SEQ=8563
Web Server
SYN Received
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.)
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.
44
Three-way Handshake
Client
SYN, SEQ=8563
Web Server
SYN Received SYN, ACK, SEQ=1678 ACK=8564
SYN, ACK Received
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
45
Three-way Handshake
Client
SYN, SEQ=8563
Web Server
SYN Received SYN, ACK, SEQ=1678 ACK=8564
SYN, ACK Received ACK, SEQ=8564 ACK=1679 HTTP Request (GET)
ACK Received
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)
46
Step 1: Client sends ISN, SEQ=8563 (last four digits)
47
Step 2: Server responds with ACK=8564, own ISN, SEQ=1678
48
Step 3: Client sends ACK=1679
49
Client now sends HTTP Request (GET) to Web Server
50
TCP: Connection Termination


16-bit Window Size
16-bit TCP Checksum
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.
51
Flow Control and Reliability


16-bit Window Size
16-bit TCP Checksum
Options (if any)
Data (if any)
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.
52
15 16

16-bit Window Size
16-bit TCP Checksum
Options (if any)
Data (if any)
Flow Control and Reliability To govern the flow of data between devices, TCP uses a peer-to-peer flow control mechanism. 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. 53 TCP is a full duplex service, client and server specify their own window sizes.
15 16

16-bit Window Size
16-bit TCP Checksum
Options (if any)
Data (if any)
Receive Window The TCP Receive Window size is the amount of receive data (in bytes) that can be buffered by this host, at one time on a connection. The other (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. 54
Flow Control and Reliability

Application Data (100,000 bytes)
1-1000
1001-2000
2001-3000
3001-4000
4001-5000
TCP
1-1000
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 Client 55 Window Size of 5,000 bytes
15 16

16-bit Window Size
16-bit TCP Checksum
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. 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.
56
Client has a Window Size of 5,000 bytes
Client
Web Server
MSS of 1,000 bytes 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)
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
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 SEQ=10,001 (to 11,000) 57
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 Send Server Window=5,000

SEQ=1 SEQ=1,001 SEQ=2,001 SEQ=3,001 SEQ=4,001 Send Window: Byte 5,000
SEQ=5,001 SEQ=6,001 SEQ=7,001 SEQ=8,001 SEQ=9,001
Send Window: Byte 10,000
SEQ=10,001
Send Window: Byte 15,000 58
Sliding Windows
Initial Window size Usable Window Can send ASAP Working Window size Octets sent Usable Window 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.
59
15 16
TCP Header

16-bit Window Size
16-bit TCP Checksum
Options (if any)
Data (if any)
Host A - Sender
1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4
Host B - Receiver
5 6 7 8 9 10 11 12 13
10
11
12
13
1 2
Window size = 6 Octets sent Not ACKed Usable Window Can send ASAP
3
1 2 3
Octets received
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 its 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.
60
Host A - Sender
1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4
Host B - Receiver
5 6 7 8 9 10 11 12 13
10
11
12
13
1 2 3
1 2 3 4 5 6 7 8 9 10 11 12 13
ACK 4 4 5
10
11
12
13
10
11
12
13 1 2 3 4 5 6 7 8 9 10 11 12 13
Window size = 6 Octets sent Usable Window
ACK 6
Not ACKed
Can send ASAP
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.
61
Host A - Sender
1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4
Host B - Receiver
5 6 7 8 9 10 11 12 13
10
11
12
13
Window size = 6
1 2 3
Octets sent Not ACKed
Usable Window Can send ASAP
10
11
12
13
ACK 4 4 5
10
11
12
13
10
11
12
13
1 2 3 4 5 6 7 8 9 10 11 12 13
10
11
12
13
ACK 6 6 7
10
11
12
13
1 2 3 4 5 6 7 8 9 10 11 12 13
10
11
12
13
8 9
More sliding windows
10
11
12
13
62
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!
63
Client
Web Server has a: MSS of 1000 bytes Client has a Window Size of 5,000 bytes
Web Server
SEQ=1 SEQ=1,001 SEQ=2,001 SEQ=3,001
Send Window=5,000 Send Window: Byte 5,000
ACK=2,001
SEQ=4,001 Send Window: Byte 7,000 SEQ=5,001 SEQ=6,001 ACK=6,001 SEQ=7,001 SEQ=8,001 Send Window: Byte 11,000 SEQ=9,001 SEQ=10,001 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
64
Reliable Data Transfer
My reliable puppy Luigi
TCPs reliable data service is on top of IPs unreliable, best-effort service. TCP uses a single retransmission timer for all of its 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.
65
Scenario 1: Loss of an ACK

Client
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
Web Server
Timeout
X
(loss)
(TCP Retransmission Timer)
66
Scenario 2: ACK arrives after timer expires

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
Client
Web Server
seq 92 Timeout
seq 92 Timeout
This ACK tells the Web Server that both segments have been received.
67
Scenario 3: Loss of first ACK

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.
Client
Web Server
seq 92 Timeout
X
(loss)
68
A few more notes on Window Size, Timers, etc.

15 16


16-bit Window Size
16-bit Window Size
16-bit TCP Checksum
16-bit TCP Checksum
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.
69
A few more notes on Window Size, Timers, etc.

15 16


16-bit Window Size
16-bit Window Size
16-bit TCP Checksum
16-bit TCP Checksum
Options (if any)
Options (if any)
Data (if any)
Data (if any)
The host may reduce its Window Size if: ACKs not arriving before retransmission timer expires or not arriving at all. This may also cause the host to increase its retransmission timer interval. Receive buffers are decreasing, filling up. The host may increase its Window Size if: ACKs are received before retransmission timer expires Receive buffers are increasing, less bits to process.
70
Client
Web Server has a: MSS of 1000 bytes Client has an initial Window Size of 5,000 bytes ACK=2,001 Window=7,000
Web Server
SEQ=1 SEQ=1,001
Send Window=5,000
Send Window: Byte 5,000
SEQ=2,001
SEQ=3,001 SEQ=4,001 Send Window: Byte 9,000 SEQ=5,001 SEQ=6,001
ACK=6,001 Window=9,000
SEQ=7,001 SEQ=8,001 Send Window: Byte 15,000 SEQ=9,001 SEQ=10,001 Etc.
Client increases its Window Size. Send Window Byte: This is the last byte that can be sent before receiving an ACK
71
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
72
UDP and TCP

UDP
TCP
0 16-bit Source Port Number 15 16 31 16-bit Destination Port Number 32-bit Sequence Number 32 bit Acknowledgement Number 4-bit Header Length 6-bit (Reserved)
16-bit Window Size
16-bit TCP Checksum
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)
73
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.
Computer Networking James Kurose and Keith Ross ISBN 0321227352
University level text book Variety of networking topics. An excellent extension to CIS 81 material
74
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 senders 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 75 bytes through 100. This ignores SACK.
TCP MSS defines the maximum size of the data in the TCP segment. 20 octets 20 octets Ethernet MTU defines the maximum size of the data in the Ethernet frame. 1460 octets
TCP MSS = 1460
Data = 1460 octets

The host using Ethernet, MTU of 1500 octets so I will set my MSS to 1460.
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) 76
Chapter 4 Transport Layer

CIS 81 Networking Fundamentals Rick Graziani Cabrillo College graziani@cabrillo.edu Last Updated: 3/2/2008

Cis81 E1 4 TransportLayer

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cis81 E1 4 TransportLayer

Uploaded by

Copyright:

Available Formats

Chapter 4 Transport Layer

Transport Layer Overview

Application Header + data

Data Link Trailer

Data Link Header

Data Link Trailer

Data Link Header

Data Link Trailer

Data Link Header

Data Link Trailer

Data Link Header

Data Link Trailer

Focus on Transport Layer

TCP vs. UDP

ISPs Email and FTP Server

Port Numbers: TCP and UDP

32-bit Sequence Number

32 bit Acknowledgement Number 4-bit Header Length 6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

Application Header + data

Application Header + data

The Internet Assigned Numbers Authority (IANA) assigns port numbers.

Client TCP Header

32-bit Sequence Number

32 bit Acknowledgement Number 4-bit Header Length 6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

16-bit Urgent Pointer

Options (if any)

Data for Telnet

Data (if any)

Server TCP Header 15 16

16-bit Destination Port Number

32 bit Acknowledgement Number 4-bit Header Length 6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

16-bit Urgent Pointer

Options (if any)

Data for Telnet

Data (if any)

C:\Users\rigrazia>netstat -n Active Connections

Proto TCP TCP

Local Address 192.168.1.101:49888 192.168.1.101:49890

Foreign Address 198.133.219.25:80 198.133.219.25:80

State TIME_WAIT TIME_WAIT

Source Port 49888 49890

Destination Port 198.133.219.25 80 80

Source Port 49888

Connection State Source IP Destination IP Source Port Destination Port

Connectionless Transport: UDP

Data (if any)

16-bit UDP Length

16-bit UDP Checksum

Data (if any)

Data (if any)

Data (if any)

Data (if any)

UDP Checksum (FYI)

Data (if any)