Chapter 4 Transport Layer

Chapter 4Transport 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

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

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

TCP UDP

Application Header + data

TCP Header UDP Header

PDU: Segment

PDU: Data

What is the application PDU called?

What is the transport PDU called?

TCP/UDP TCP/UDP

The Layer 4 data stream is a: Logical connection between the endpoints Provides transport services

End-to-end service

DataHTTP Header

TCP Header

IP Header

Data Link Header

Data Link Trailer

IP PacketData Link Header

Data Link Trailer

DataHTTP Header

TCP Header

IP Header

Data Link Header

Data Link Trailer

Reminder of encapsulation/decapsulation

Focus on Transport LayerTCP

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

Transport Layer

www.cisco.com

TCP 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.

segment segment

TCP vs. UDP

TCP provides: Reliable delivery Error checking Flow control Congestion control Ordered delivery Connection establishment Applications:

HTTP FTP SMTP 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) DHCP RTP (Real-Time Protocol) VoIP

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.

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)

TCPTCP

HTTPHTTP

Cabrillo Web Server

ISP’s Email 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)

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

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.

Application Header + dataPort numbers are used by

the receiver so it knows which application it should

send the “Data” to.

Application Header + dataPort numbers are used to

by the sender to tell the receiver which network

application it should use for the “Data”.

Port Number

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 Client: TCP destination port Server: TCP source port

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).

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)

Private/Dynamic Port Number

Client Server

Telnet

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

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

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

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

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? 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.

192.168.1.101

172.16.5.5

Destination Port

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 IPDestination 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

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

0 15 16 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

0 15 16 31

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

0 15 16 31

16-bit UDP Length

16-bit UDP Checksum

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.

0 15 16 31

16-bit UDP Length

16-bit UDP Checksum

Data (if any)

UDP segmentUDP segmentUDP segmentUDP segment

Client Server

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

0 15 16 31

16-bit UDP Length

16-bit UDP Checksum

Data (if any)

Client Server

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.

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.

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 UDP Length

16-bit UDP Checksum

Data (if any)

Client Server

Cumulative Sum: 1100101011001010

1s complement: 0011010100110101

Total: 1111111111111111

Final Checksum

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 UDP Length

16-bit UDP Checksum

Data (if any)

Client Server

Cumulative Sum: 1100101011001010

1s complement: 0011000100110101

Total: 1111101111111111

Final Checksum

Connection-oriented Transport: 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

4-bit Header Length

6-bit (Reserved)

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

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

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

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

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.)

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

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

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

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=8564

ACK, SEQ=8564 ACK=1679

SYN Received

SYN, ACK Received

ACK Received

Web Server

HTTP Request (GET)

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

49 Step 1: Client sends ISN, SEQ=8563 (last four digits)

50 Step 2: Server responds with ACK=8564, own ISN, SEQ=1678

51 Step 3: Client sends ACK=1679

52 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

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

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?

Flow Control and Reliability

Reliability Guaranteed delivery

Flow Control Flow control makes sure these buffers do not receive more data than

the connection can handle.

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

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.

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

Client Window Size=5,000

Server Window

Size=10,000

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.

Server Window

Size=10,000Server’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 ReliabilityApplication 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 (To be completely accurate in the diagram the MSS would

include the data plus the TCP header.) 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.

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

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)

Server Window

Size=10,000

Server Window

Size=10,000…

Send Window: Byte 10,000

Server Window

Size=10,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,000SEQ=3,001 – 4,000SEQ=4,001 – 5,000

ACK=5,001

SEQ=1 – 1,0001

SEQ=6,001 – 7,000SEQ=7,001 – 8,000SEQ=8,001 – 9,000SEQ=9,001 – 10,000

ACK=10,001

SEQ=5,001 – 6,000

Server Window

Size=10,000

Server Window

Size=10,000

Server Window

Size=10,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

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.

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

Host A - Sender Host B - Receiver

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

TCP Header

1 2 3 4 5 6 7 8 9 10 11 12 13

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.

1 2 3 4 5 6 7 8 9 10 11 12 13

Octets sent

Not ACKed

Usable Window

Can send ASAP

Window size = 6

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

More sliding windows

1 2 3 4 5 6 7 8 9 10 11 12 13

Octets sent

Not ACKed

Usable Window

Can send ASAP

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

Host B - ReceiverHost A - Sender

Window size = 6

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!

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

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

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 see three simple examples to explain how this works. The last two examples are FYI.

My reliable puppy Luigi

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

SEQ=92, 8 bytes data

ACK=100

X (loss)

Timeout

ACK=100

(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

ACK=100

seq 92 Timeout

ACK=120

seq 92 Timeout

This ACK tells the Web Server that both segments have been received.

FYI 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

ACK=120

FYI Scenario 3: Loss of first ACK

ACK=100

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

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

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.

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.

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

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

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 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

Send Window=5,000

Window=5,000

Last few notes

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

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

UDP and TCP TCP

TCP provides: Reliable delivery Error checking Flow control Congestion control Ordered delivery (Connection establishment)

UDP provides: Unreliable delivery No error checking No flow control No congestion control No ordered delivery (No connection

establishment)

Note of Interest – TCP Reset

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

0 15 16 31

4-bit Header Length

6-bit (Reserved)

16-bit Window Size

16-bit TCP Checksum

Options (if any)

Data (if any)

Hey, I’m sending segments but I’m not getting any

Acks. I’m going to reset this connection.

Although, published in 1994, written by the late Richard Stevens, it is still regarded as the definitive book on TCP/IP.

TCP/IP Illustrated, Vol. 1 W. Richard Stevens Addison-Wesley Pub Co ISBN: 0201633469

Computer Networking

James Kurose and Keith Ross ISBN 0321227352

University level text book Variety of networking topics. An excellent extension to CIS

81 material

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 bytes through 100. This ignores SACK.

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.

Chapter 4Transport Layer

CIS 81 Networking Fundamentals

Rick Graziani

Cabrillo College

graziani@cabrillo.edu

Chapter 4 Transport Layer

Documents

Chapter 3: Transport Layer - UoAcgi.di.uoa.gr/~shadj/PLH36/TCP_presentation_KUROSE.pdf · Chapter 3: Transport Layer ... Internet Chapter Overview: ... Transport Layer 3a-2 Transport

Chapter 3: Transport Layer

Chapter 3 Transport Layer

Transport Layer3-1 Chapter 3 Transport Layer. Transport Layer3-2 Chapter 3: Transport Layer Our goals: r understand principles behind transport layer

Transport Layer Chapter 3 architecture Transport Layer

Chapter 22 Transport Layer

Chapter 3 Chapter 3: Transport Layer Transport Layer

Chapter 3 Transport Layer - unimi.itra.crema.unimi.it/turing/materiale/admin/corsi/sistemi/Lezioni/M2/... · Transport Layer 3-1 Chapter 3 Transport Layer ... Transport Layer 3-2

Chapter 3 Transport Layer

CHAPTER 3: TRANSPORT LAYER

Chapter 3 Transport Layer - School of Computing and ...users.cis.fiu.edu/~pand/tcn5030/lec06.pdf · Transport Layer 3-1 Chapter 3 Transport Layer Computer Networking: ... 3.1 transport-layer

CHAPTER 3: TRANSPORT LAYER TRANSPORT LAYER Transport Layer Services Transport Layer Services Establishing/Releasing Connections Establishing/Releasing

CCNA1-1 Chapter 4 OSI Transport Layer. CCNA1-2 Chapter 4 OSI Transport Layer Roles of the Transport Layer

Transport Layer Chapter 3 Transport Layer