chapter 4 transport layer - w3.ualg.ptw3.ualg.pt/~jjose/cisco/ccna1/ccna1-ch4-transportlayer.pdf ·...

Chapter 4

Transport Layer

João José

[email protected]

http://w3.ualg.pt/~jjose/cisco/

Based on:

Graziani, R. (2008) CIS 81 Networking Fundamentals

Cisco CCNA 1 Exploration - Networking


Transport Layer Overview

Transport Layer

The Layer 4 data stream is a:

logical connection between the endpoints of a network,

provides transport services from a host to a destination.

End-to-end service.

The transport layer also provides two protocols

TCP – Transmission Control Protocol

UDP – User Datagram Protocol

PDU: Segment

TCP UDP

TCP Header UDP Header

DataHTTP

Header

TCP

Header

IP

Header

Data Link

Header

Data Link

Trailer

IP PacketData Link

Header

Data Link

TrailerIP PacketData Link

Header

Data Link

Trailer

IP PacketData Link

Header

Data Link


Header

Data Link

Trailer

IP PacketData Link

Header

Data Link


Header

Data Link

Trailer

Reminder of encapsulation/decapsulation

DataHTTP

Header

TCP

Header

IP

Header

Data Link

Header

Data Link

Trailer

Transport Layer

Primary responsibilities:

Tracking the individual communication between applications

Segmenting data

Managing each segment

Reassembling the segments

Identifying the different applications

Transport Layer

Protocols:

TCP

UDP

IP is a best-effort delivery service

No guarantees

Best-effort service

“Unreliable service”

TCP/UDP is responsible for extending IP‟s delivery service between two

end systems.

Known as transport layer multiplexing and demultiplexing.

segment segment

http://www.apache.org/

TCP vs. UDP

TCP provides:

Reliable delivery

Error checking

Flow control

Congestion control

Ordered delivery

(Connection establishment)

Applications:

HTTP

FTP

Telnet

MSN messenger

UDP provides:

Unreliable delivery

No error checking

No flow control

No congestion control

No ordered delivery

(No connection establishment)

Applications

DNS (usually)

SMTP

DHCP

RTP (Real-Time Protocol)

VoIP

A single client may have multiple transport connections with multiple servers.

Notice that TCP is a connection-oriented service (two-way arrow) between the hosts, whereas UDP is a connectionless service (one-way arrow) . (later)

TCP

TCP

TCP

TCP

TCP

TCP

HTTPHTTP

FTP

UDP

SMTP

UDP

Cabrillo

Web

Server

ISP’s

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)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum

16-bit Urgent Pointer

Options (if any)

Data (if any)

TCP Header

HTTP is Port 80

UDP Header

Application

Header + dataPort numbers are used to

know which application

the receiving host should

send the “Data”.

Application

Header + dataPort numbers are used to

know which application

the receiving host should

send the “Data”.

http://www.iana.org/assignments/port-numbers

The Internet Assigned Numbers Authority (IANA) assigns port

numbers.




Well Known Ports (Numbers 0 to 1023)

Reserved for common services and applications.

HTTP (web server), POP3/SMTP (e-mail server) and Telnet.

Client: TCP destination port

Server: TCP source port

Registered Ports (Numbers 1024 to 49151)

Assigned to user processes or applications.

Non-common applications.

Client: TCP destination port

Server: TCP source port

May also be used as dynamic or private port (next).

Dynamic or Private Ports (Numbers 49152 to 65535)

Also known as Ephemeral Ports

Usually assigned dynamically to client applications when initiating a

connection.

Client: TCP source port

Server: TCP destination port

May also include the range of Registered Ports (Numbers 1024 to

49151)

Note: Some peer-to-peer file sharing programs use these ports as

Register Ports. (previous slide)

Client sends TCP segment with:

Destination Port: 23 (Well known port number)

Source Port: 1028 (Dynamic Port assigned by client)

Client TCP Header0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


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)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

102823

Data for Telnet

Client Server

Notice the difference in how source and destination port numbers are used with clients and servers:

Client (initiating Telnet service):

Destination Port = 23 (telnet)

Source Port = 1028 (dynamically assigned)

Server (responding to Telnet service):

Destination Port = 1028 (source port of client)

Source Port = 23 (telnet)

Same client to same server - Two different HTTP sessions

Client: Same destination port

Client: Different source ports to uniquely identify this web session.

4989049888

C:\Users\rigrazia>netstat -n

Active Connections

Proto Local Address Foreign Address State

TCP 192.168.1.101:49888 198.133.219.25:80 TIME_WAIT

TCP 192.168.1.101:49890 198.133.219.25:80 TIME_WAIT

C:\Users\rigrazia>

TCP

or

UDP

Source Port

Destination IP

Destination Port Connection State

Source IP

4989049888

What makes each connection unique?

Connection defined by the pair of numbers:

Source IP address, Source port

Destination IP address, Destination port

Different connections can use the same destination port on server host as long as the source ports or source IPs are different.

192.168.1.101

172.16.5.5

Destination

Port

80

80

80

Source

Port

49890

49888

Source

Port

198.133.219.2549888

www.cisco.com

Note: When downloading a web document and its objects it is common that

there will be several TCP sessions created.

netstat –n www.cisco.comwww.google.com

TCP

or

UDP Source Port

Destination IP

Destination Port

Connection StateSource IP

Using NetStat

Open a web browser.

Open a command prompt window (Start->Run->cmd)

Enter a URL of your choice.

Type netstat –n in the command window.

Questions:

What is/are the source ports on your client?

What is/are the destination ports on your client?

What would be the source port(s) on the server?

What would be the destination port(s) on the server?

What application layer protocol is being used? How can you tell?

What transport layer protocol is being used?

Trying more at home:

Use netstat to look at other networking applications such as FTP

or Telnet.

Connectionless Transport: UDP

UDP

No frills, barebones transport protocol.

Destination and Source Ports

Length and Checksum (used for error checking)

RFC 768

Connectionless transport

No “handshaking” (no connection establishment) as with TCP (coming)

Unreliable delivery

No error checking

No flow control

No congestion control

No ordered delivery

0 15 16 31



16-bit UDP Length

16-bit UDP Checksum

Data (if any)

UDP

source port -- the number of the calling port

destination port -- the number of the called port

UDP length -- the length of the UDP header

checksum -- the calculated checksum of the header and data fields

data -- upper-layer protocol data

0 15 16 31



16-bit UDP Length

16-bit UDP Checksum

Data (if any)

UDP

Why would an application developer choose UDP rather than TCP?

Finer application-layer control

TCP will continue to resend segments that are not acknowledged.

Applications that use UDP can tolerate some data loss:

Streaming video

VoIP (Voice over IP)

Application decides whether or not to resend entire file: TFTP

0 15 16 31



16-bit UDP Length

16-bit UDP Checksum

Data (if any)

UDP

No connection establishment

TCP uses a three-way handshake to establish a connection (coming)

UDP does not – it just blasts away the data to the sender.

No delay to establish connection.

0 15 16 31



16-bit UDP Length

16-bit UDP Checksum

Data (if any)

Time

Client Server

UDP

No connection state

UDP does not maintain connection state as does TCP (coming)

Connection state is used for reliability and flow control.

Server can support more active clients when not maintaining state

information

Small packet header overhead

TCP header has 20 bytes of overhead.

UDP header has only 8 bytes of overhead

0 15 16 31



16-bit UDP Length

16-bit UDP Checksum

Data (if any)

Time

Client Server

UDP

Note: Multimedia Applications and UDP

There is an issue (controversy) with multimedia applications over UDP.

UDP offers no congestion control (as we will see with TCP)

Congestion control is needed to prevent the network from entering and staying in a congested state.

If all applications were using UDP, because of congestion, very few UDP packets would be delivered and this would also cause TCP traffic rates to dramatically decrease.

Many applications give you a choice of TCP or UDP.

Online Gaming

Game data – Server and client need make sure all data (moves,

actions, etc) reach the other end reliably.

Voice chat – Some missing data can be tolerated (up to a point).

Retransmission would cause delay.

Question: Do the World

of Warcraft servers

use TCP or UDP?

Answer: TCP for game

data, UDP for voice

chat.

Why?

UDP Checksum (FYI)

UDP checksum provides error detection, any changed bits or missing segments.

Simplified explanation (see RFC 1071 for more details):

Sender

UDP adds 16 bit „words‟ keeping a cumulative sum.

Performs one's complement of the sum of all the 16-bit words in the segment.

Convert 0‟s to 1‟s and 1‟s to 0‟s

This result is put in the checksum field of the UDP segment.

Receiver

UDP adds 16 bit „words‟ keeping a cumulative sum

Adds 1’s (ones) complement

If no errors are introduced into the segment, then the Total at the receiver will be 1111111111111111.

0 15 16 31



16-bit UDP Length

16-bit UDP Checksum

Data (if any)

Time

Client Server

Cumulative Sum: 1100101011001010

1s complement: 0011010100110101

Total: 1111111111111111

UDP Checksum (FYI)

What if there is an error?

UDP does nothing to recover the error.

It is up to the application layer protocol (example TFTP) to decide what to do, such as prompt the user to download/upload the entire file again.

0 15 16 31



16-bit UDP Length

16-bit UDP Checksum

Data (if any)

Time

Client Server

Cumulative Sum: 1100101011001010

1s complement: 0011000100110101

Total: 1111101111111111

Connection-oriented Transport: TCP

TCP

TCP provides reliable delivery on top of unreliable IP

TCP provides:

Reliable delivery

Error checking

Flow control

Congestion control

Ordered delivery

Connection establishment

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

TCP

source port -- the number of the calling port

destination port -- the number of the called port

sequence number -- the number used to ensure correct sequencing of the arriving data

acknowledgment number -- the next expected TCP octet

HLEN -- the number of 32-bit words in the header

reserved -- set to 0

code bits -- the control functions (e.g. setup and termination of a session)

window -- the number of octets that the sender is willing to accept

checksum -- the calculated checksum of the header and data fields

urgent pointer -- indicates the end of the urgent data

option -- one currently defined: maximum TCP segment size

data -- upper-layer protocol data

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


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)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

Three-way

Handshake

Step 1:

The three-way handshake happens before any data, HTTP Request (GET), is sent by the client.

A TCP client begins the three-way handshake by sending a segment with the SYN (Synchronize Sequence Number) control flag set, indicating an initial value in the sequence number field in the header.

The sequence number is the Initial Sequence Number (ISN), is randomly chosen and is used to begin tracking the flow of data from the client to the

server for this session.

Client

SYN, SEQ=8563

SYN Received

Web

Server

Note: ISNs do not start a 0 or 1.

There are several reasons for

this including segments that may

still be in buffers and also

security issues. (Beyond the

scope of this presentation.)

Three-way

Handshake

Step 2:

The TCP server needs to acknowledge the receipt of the SYN segment.

Server sends a segment back to the client with:

ACK flag set indicating that the Acknowledgment number is significant.

The value of the acknowledgment number field is equal to the client initial sequence number plus 1.

This is called an expectational acknowledgement – the next byte this host expects to receive (more soon).

SYN flag is set with its own random ISN for the Sequence number

Client

SYN, SEQ=8563

SYN, ACK,

SEQ=1678

ACK=8564

SYN Received

SYN, ACK Received

Web

Server

Three-way

Handshake

Step 3:

TCP client responds with a segment containing an ACK that is the

response to the TCP SYN sent by the server.

The value in the acknowledgment number field contains one more than the

initial sequence number received from the server.

The client can now send application data encapsulated in TCP segment.

HTTP Request (GET)

Client

SYN, SEQ=8563

SYN, ACK,

SEQ=1678

ACK=8564ACK,

SEQ=8564

ACK=1679

SYN Received

SYN, ACK Received

ACK Received

Web

Server

HTTP Request

(GET)

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

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

Step 3: Client sends ACK=1679

Client now sends HTTP Request (GET) to Web Server

TCP: Connection Termination

1. When the client has no more data to send in the stream, it sends a segment

with the FIN flag set.

2. The server sends an ACK to acknowledge the receipt of the FIN to terminate

the session from client to server.

3. The server sends a FIN to the client, to terminate the server to client session.

4. The client responds with an ACK to acknowledge the FIN from the server.

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

Packet Tracer Exercise: TCP Connection and

Termination

Download the file: PT-DHCP-DNS-HTTP.pkt

Open Packet Tracer (wait for green lights then click on Simulation mode)

Edit Filters: TCP, DNS, HTTP

On a client, open a web browser and type www.cabrillo.edu

Click Capture/Forward to watch the packets and examine the protocols.

Why didn‟t a TCP 3-way handshake happen before the client sent a DNS

request to the DNS server?

Why did a TCP 3-way handshake happen before the client sent a HTTP

Request message to the web server?

Flow Control and Reliability

Reliability

Guaranteed delivery - making sure all the data was received.

If missing data, determining which bytes need to be retransmitted.

Flow Control

Each host has a receive buffer for the TCP connection.

Flow control makes sure these buffers do not receive more data than the connection can handle.

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)


The receiving host's TCP layer reports a window size to the sending

host's TCP layer.

This window size specifies the number of bytes, starting with the

acknowledgment number, that the receiving host's TCP layer is currently

prepared to receive.

Window size is included in every TCP segment sent from client or server

starting with three-way handshake.

TCP is a full duplex service, client and server specify their own window

sizes.

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

Receive Window

The TCP Receive Window size: Amount of receive data (in bytes) that can be buffered by this host, at one time on a connection.

Sending host can send only that amount of data before getting an acknowledgment and window update from this (the receiving) host.

Send Window (not a TCP field)

The TCP Receive Window size of the other host.

How much data (in bytes) that can be sent by this host before receiving an acknowledgement from the other host.

Client Example

Receive Window Size=5,000 bytes – Server can only send 5,000 bytes before it receives an acknowledgement.

Send Window Size = 10,000 bytes – Server told the client that it can send the server 10,000 bytes before receiving an acknowledgment.

Server‟s Send

Window: 10,000

My Receive

Window: 10,000My Receive

Window: 5,000

Client‟s Send

Window: 5,000

“I can send 10,000

bytes without hearing

an ACK, and I can

only receive 5,000

bytes at a time.”

“I can send 5,000

bytes without hearing

an ACK, and I can

only receive 10,000

bytes at a time.”


Application Data (100,000 bytes)

1-1000 1001-2000 2001-3000 3001-4000 4001-5000

Flow control and reliability are intertwined .

When TCP has a large file (such an image) it breaks it into equal chunks, with

the last chunk typically smaller.

Each chunk of data with TCP header is known as a segment.

The size of the chunk is known as the MSS (Maximum Segment Size)

TCP Options field (later)

In the following example:

Web Server has a:

MSS of 1000 bytes

Client

Window Size of 5,000 bytes

…

TCP 1-1000 TCP Segment

Sequence Number and Acknowledgements

Remote host sends TCP segments with a Sequence Number.

Note: This is the first byte in the of data in the segment.

The receiving host:

Determines the number of bytes in the segment (FYI later).

Sends an ACK (Acknowledgement) back to the remote host, with the last byte received + 1.

The sending host cannot send any data past the Send Window (the window size sent by the receiving host) until it receives an ACK from the receiver.

This is an expectational acknowledgments, meaning that the acknowledgment number refers to the next byte that the sender of the acknowledgement expects to receive.

A larger window size allows more data to be transmitted pending acknowledgment.

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

This is known as a

Stop-and-Wait

windowing protocol.

Server must wait for

acknowledgment

before continuing to

send data.

A better method?

Sliding Windows

Next!

Send Window Byte:

This is the last byte

that can be sent

before receiving an

ACK

Client

SEQ=1,001 (to 2,000)

Web

Server

SEQ=2,001 (to 3,000)

SEQ=3,001 (to 4,000)

SEQ=4,001 (to 5,000)

ACK=5,001

SEQ=1 (to 1,000)

SEQ=6,001 (to 7,000)

SEQ=7,001 (to 8,000)

SEQ=8,001 (to 9,000)

SEQ=9,001 (to 10,000)

ACK=10,001

SEQ=5,001 (to 6,000)

….

Send Window:

Byte 10,000

Send Window:

Byte 15,000

SEQ=10,001 (to 11,000)

Send

Window=5,000

Client has a

Window Size of

5,000 bytes

MSS of 1,000 bytes

TCP Window Size

TCP provides full-duplex service, which means data can be flowing in each direction, independent of the other direction.

Receiver sends acceptable window size to sender during each segment transmission (flow control)

If too much data being sent, acceptable window size is reduced

If more data can be handled, acceptable window size is increased

Client

SEQ=1,001 – 2,000

Web

Server

SEQ=2,001 – 3,000

SEQ=3,001 – 4,000

SEQ=4,001 – 5,000

ACK=5,001

SEQ=1 – 1,0001

SEQ=6,001 – 7,000

SEQ=7,001 – 8,000

SEQ=8,001 – 9,000

SEQ=9,001 – 10,000

ACK=10,001

SEQ=5,001 – 6,000

….

Send Window:

Byte 10,000

Send Window:

Byte 15,000

SEQ=10,001 – 11,000

Send

Window=5,000

Sliding Window Protocol

Sliding window algorithms are a method of flow control for network data transfers using the receivers Window size.

The sender computes its usable window, which is how much data it can immediately send.

Over time, this sliding window moves to the rights, as the receiver acknowledges data.

The receiver sends acknowledgements as its TCP receive buffer empties.

The terms used to describe the movement of the left and right edges of this sliding window are:

1. The left edge closes (moves to the right) when data is sent and acknowledged.

2. The right edge opens (moves to the right) allowing more data to be sent. This happens when the receiver acknowledges a certain number of bytes received.

3. The middle edge open (moves to the right) as data is sent, but not yet acknowledged.

Octets sent

Not ACKed

Usable Window

Can send ASAP

Working Window size

Usable Window

Can send ASAP

Initial Window size

Sliding Windows

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

2

3

Host B gives Host A a window size of 6 (octets).

Host A begins by sending octets to Host B: octets 1, 2, and 3 and slides it‟s

window over showing it has sent those 3 octets.

Host A will not increase its usable window size by 3, until it receives an

ACKnowldegement from Host B that it has received some or all of the octets.

Host B, not waiting for all of the 6 octets to arrive, after receiving the third octet

sends an expectational ACKnowledgement of “4” to Host A.

ACK 4

Octets sent

Not ACKed

Usable Window

Can send ASAP

Window size = 6 Octets received

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

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

1

Host A - Sender Host B - Receiver

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

TCP Header

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

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

2

3

ACK 4

Host A does not have to wait for an acknowledgement from Host B to keep

sending data, not until the window size reaches the window size of 6, so it

sends octets 4 and 5.

Host A receives the acknowledgement of ACK 4 and can now slide its window

over to equal 6 octets, 3 octets sent – not ACKed plus 3 octets which can be

sent asap.

4

5

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

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

ACK 6

Octets sent

Not ACKed

Usable Window

Can send ASAP

Window size = 6

1

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

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

Host B - ReceiverHost A - Sender

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

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

2

3

ACK 4

More sliding windows

4

5

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

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

ACK 6

Octets sent

Not ACKed

Usable Window

Can send ASAP

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

7

6

9

8

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

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

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

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

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

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

1

Host B - ReceiverHost A - Sender

Window size = 6

Client

SEQ=1,001 – 2,000

Web

Server

SEQ=2,001 – 3,000

SEQ=3,001 – 4,000

SEQ=4,001 – 5,000

ACK=2,001

SEQ=1 – 1,000

SEQ=6,001 – 7,000

SEQ=7,001 – 8,000

SEQ=8,001 – 9,000

SEQ=9,001 – 10,000

Etc.

SEQ=5,001 – 6,000

ACK=6,001

Web Server has a:

MSS of 1000 bytes

Client has a

Window Size of

5,000 bytes

SEQ=10,001 – 11,000

Send Window: Byte 5,000

Send Window:

Byte 7,000

2,001 to 7,000

Send Window:

Byte 11,000

6,001 to 11,000

Server can now continue sending without having to wait for an

acknowledgement.

Send Window Byte: This is the last byte that can be sent before receiving

an ACK

Send

Window=5,000

Reliable Data Transfer

TCP‟s reliable data service is on top of IP‟s unreliable, best-effort service.

TCP uses a single retransmission timer for all of it‟s segments within a

TCP connection.

How this timer is calculated is beyond the scope of this presentation

(too many slides already )

See RFC 2988

The TCP retransmission timer is associated with the oldest

unacknowledged segment sent.

We will use three simple examples to explain how this works.

Client Web

Server Web Server sends data.

Starts TCP retransmission

timer.

Client:

Segment received

Sends ACK

But ACK from Client gets

lost (dropped somewhere)

Web Server

Waiting for ACK.

TCP Retransmission

Timer expires.

Retransmits segment.

Client

Receives segment but

discards it.

Resends ACK

Web Server

Receives ACK

X (loss)

Timeout

(TCP

Retransmission

Timer)

Scenario 1: Loss of an ACK

Client Web

Server Web Server:

Sends 2 segments

Starts timer for oldest segment, SEQ=92

Waits for ACK

Client:

Receives both segments

Sends 2 separate ACKs

Web Server:

Neither ACK has arrived yet

Timer for SEQ=92 expires

Resends segment SEQ=92

Restarts timer for SEQ=92

As long as the ACK for the second segment arrives before the new timeout expires, the second segment will not be retransmitted.

Client:

Receives retransmitted SEQ=92 segment.

Discards segment

Re-sends ACK=120 for next byte needed

seq 92

Timeout

seq 92

Timeout

(TCP

Retransmission

Timer)

This ACK tells

the Web Server

that both

segments have

been received.

Scenario 2: ACK arrives after timer expires

Client Web

Server Web Server:

Sends 2 segments

Starts timer for oldest segment, SEQ=92

Waits for ACK

Client:

Receives both segments

Sends 2 separate ACKs

ACK for first segment, ACK=100, is lost

Web Server:

Before timer expires for SEQ=92 ACK

(ACK=100), receives ACK=120

Web Server knows that Client has

received everything up to byte 119.

Does not need to resend either of the two

segments.

seq 92

Timeout

(TCP

Retransmission

Timer)

Scenario 3: Loss of first ACK

X (loss)

A few more notes on Window Size, Timers, etc.

Both hosts in the TCP connection constantly advertise their Window Size to the

remote host in each segment sent.

Remember, TCP is a full duplex service – data can be sent and received in

both directions.

Receive Window Size may be increased or decreased due to flow control

(buffers) or congestion (network).

The effects on TCP are very similar.

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

A few more notes on Window Size, Timers, etc.

The host may reduce it‟s Window Size if:

ACKs not arriving before retransmission timer expires or not arriving at all.

This may also cause the host to increase it‟s retransmission timer

interval.

Receive buffers are decreasing, filling up.

The host may increase it‟s Window Size if:

ACKs are received before retransmission timer expires

Receive buffers are increasing, less bits to process.

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

0 15 16 31





4-bit Header

Length

6-bit

(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit Window Size

16-bit TCP Checksum


Options (if any)

Data (if any)

Client

SEQ=1,001 – 2,000

Web

Server

SEQ=2,001 – 3,000

SEQ=3,001 – 4,000

SEQ=4,001 – 5,000

ACK=2,001

Window=7,000

SEQ=1 – 1,000

SEQ=6,001 – 7,000

SEQ=7,001 – 8,000

SEQ=8,001 – 9,000

SEQ=9,001 – 10,000

Etc.

SEQ=5,001 – 6,000

ACK=6,001

Window=9,000

Web Server has a:

MSS of 1000 bytes

Client has an initial

Window Size of

5,000 bytes

SEQ=10,001 –

11,000

Send Window:

Byte 5,000

Send Window:

Byte 9,000

2,001 to 9,000

(Win=7,000)

Send Window:

Byte 15,000

6,001 to 15,000

(Win=9,000)

Client increases its Window Size.

Send Window Byte: This is the last byte that can be sent before receiving

an ACK

Send

Window=5,000

TCP MSS = 1460

Data = 1460 octets

20 octets 20 octets 1460 octets

1500 octets

Determining TCP MTU

Typically, an end system uses the "outgoing interface MTU" minus 40 as its reported MSS.

For example, an TCP over IP over Ethernet MSS value is 1460 (1500 - 40 = 1460).

When a host (usually a PC) initiates a TCP session with a server, it negotiates the TCP segment size by using the maximum segment size (MSS) option field in the TCP SYN packet. (curriculum say IP segment).

The value of the MSS field is determined by the maximum transmission unit (MTU) configuration on the host.

The default Ethernet MTU value for a PC is 1500 bytes. (curriculum says MSS)

TCP MSS defines the

maximum size of the data

in the TCP segment.

Ethernet MTU defines the

maximum size of the data in

the Ethernet frame.

The host using Ethernet, MTU of 1500

octets so I will set my MSS to 1460.

This presentation is available at:


Original presentations from:

http://www.cabrillo.edu/~rgraziani/

Cisco curriculum available at:

http://cisco.netacad.net (Internet Explorer recommended)

After login, under: “Course Materials”

http://cisco.netacad.net/

chapter 4 transport layer - w3.ualg.ptw3.ualg.pt/~jjose/cisco/ccna1/ccna1-ch4-transportlayer.pdf ·...

Documents