cis81-e1-4-transportlayer

7/29/2019 cis81-E1-4-TransportLayer

1/77

Chapter 4

Transport Layer

CIS 81 Networking Fundamentals

Rick GrazianiCabrillo College

[email protected]

Last Updated: 3/2/2008


2/77

2

This Presentation

For a copy of this presentation and access to my web site for otherCCNA, CCNP, and Wireless resources please email me for ausername and password.

Email: [email protected]

Web Site: www.cabrillo.edu/~rgraziani


3/77

3

Note

This presentation is not in the order of the book or online curriculum. This presentation also contains information beyond the curriculum.


4/77

Transport Layer Overview


5/77

5

Transport Layer

The Layer 4 data stream is a logical connection between the endpoints of anetwork, 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 UDP


6/77

6

ApplicationHeader + data

TCP Header UDP Header

or


7/77

7

UDP

TCP

TCP/UDP TCP/UDP


8/77

8

DataHTTPHeader

TCPHeader

IPHeader

Data LinkHeader

Data LinkTrailer

IP PacketData LinkHeader

Data LinkTrailer


Data LinkTrailer


Data LinkTrailerIP PacketData LinkHeader

Data LinkTrailer


Data LinkTrailer


Data LinkTrailer

DataHTTPHeader

TCPHeader

IPHeader

Data LinkHeader

Data LinkTrailer

Reminder of encapsulation/decapsulation


9/77

9

Focus on Transport Layer

TCP

TCP


10/77

10

Transport Layer

The Transport layer provides for the segmentation of data and the controlnecessary to reassemble segments.

Primary responsibilities:

Tracking the individual communication between applications on thesource and destination hosts

Segmenting data

Managing each segment

Reassembling the segments into streams of application data

Identifying the different applications


11/77

11

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 twoend systems to a delivery service between two process running on the end

systems. Known as transport layer multiplexing and demultiplexing.

segment segment
http://www.apache.org/


12/77

12

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 connectionestablishment) Applications

DNS (usually)

SMTP

RTP (Real-Time Protocol)

VoIP


13/77

13

A single client may have multiple transport connections with multipleservers.

Notice that TCP is a connection-oriented service (two-way arrow)

between the hosts, whereas UDP is a connectionless service (one-wayarrow) . (later)

TCP

TCP

TCP

TCP

TCP

TCP

HTTPHTTP

FTP

UDP

SMTP

UDP

Cabrillo

WebServer

ISPs

Emailand FTPServer


14/77

Port Numbers: TCP and UDP

D


15/77

15

Both TCP and UDP use ports (or sockets) numbers to pass information to theupper 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)

UR

G

AC

K

PS

H

RS

T

SY

N

FI

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


16/77

16

ApplicationHeader + dataPort numbers are used to

know which applicationthe receiving host should

send the Data.

ApplicationHeader + data

Port numbers are used toknow which application

the receiving host shouldsend the Data.


17/77

17


18/77

18

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

The Internet Assigned Numbers Authority (IANA) assigns portnumbers.
http://www.iana.org/assignments/port-numbershttp://www.iana.org/assignments/port-numbershttp://www.iana.org/assignments/port-numbershttp://www.iana.org/assignments/port-numbers


19/77

19

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 thatspecific port and its associated service.


20/77

20

Registered Ports (Numbers 1024 to 49151) Assigned to user processes or applications.

Primarily individual applications that a user has chosen to install rather thancommon applications that would receive a Well Known Port.

When not used for a server resource, these ports may also be useddynamically selected by a client as its source port.


21/77

21

Dynamic or Private Ports (Numbers 49152 to 65535)

Also known as Ephemeral Ports

Usually assigned dynamically to client applications when initiating aconnection.

Client: TCP source port

It is not very common for a client to connect to a service using aDynamic 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)


22/77

22

Client Server

Telnet


23/77

23

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

RG

A

CK

P

SH

R

ST

S

YN

F

IN

16-bit Window Size


Options (if any)

Data (if any)

231028

Data for Telnet

Client Server


24/77

24

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 HeaderLength

6-bit(Reserved)

UR

G

AC

K

PS

H

RS

T

SY

N

FI

N16-bit Window Size


Options (if any)

Data (if any)

102823

Data for Telnet

Client Server


25/77

25

Notice the difference in how source and destination port numbers areused 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)

Client Server


26/77

26

Same client to same server - Two different HTTP sessions

Client: Same destination port

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

4989049888


27/77

27

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>

TCPorUDP

Source Port

Destination IP

Destination Port Connection State

Source IP

4989049888


28/77

28

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 serverhost as long as the source ports or source IPs are different.

192.168.1.101

172.16.5.5

Destination

Port80

80

80

Source

Port

49890

49888

SourcePort

198.133.219.2549888

www.cisco.com


29/77

29

Note: When downloading a web document and its objects it is common thatthere will be several TCP sessions created.

netstatnwww.cisco.comwww.google.com

TCPorUDP Source Port

Destination IP

Destination Port

Connection StateSource IP


30/77

Connectionless Transport: UDP


31/77

31

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

0 15 16 31


16-bit UDP Length 16-bit UDP Checksum

Data (if any)


32/77

32

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



Data (if any)


33/77

33

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



Data (if any)


34/77

34

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



Data (if any)

Time

Client Server


35/77

35

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 stateinformation

Small packet header overhead

TCP header has 20 bytes of overhead.

UDP header has only 8 bytes of overhead

0 15 16 31



Data (if any)

Time

Client Server


36/77

36

UDP

Note: Multimedia Applications and UDP

There is an issue (controversy) with multimedia applications overUDP.

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

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

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

Many applications give you a choice of TCP or UDP.


37/77

37

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

0 15 16 31



Data (if any)

Time

Client Server

Cumulative Sum: 1100101011001010

1s complement: 0011010100110101

Total: 1111111111111111


38/77

38

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



Data (if any)

Time

Client Server

Cumulative Sum: 1100101011001010

1s complement: 0011000100110101

Total: 1111101111111111


39/77

39


40/77

Connection-oriented Transport: TCP


41/77

41

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 HeaderLength

6-bit(Reserved)

U

RG

A

CK

P

SH

R

ST

S

YN

F

IN

16-bit Window Size


Options (if any)

Data (if any)

0 15 16 31


42/77

42

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




4-bit HeaderLength

6-bit(Reserved)

UR

G

AC

K

PS

H

RS

T

SY

N

FI

N16-bit Window Size


Options (if any)

Data (if any)


43/77

43

TCP: Connection Establishment

For a connection to be established, the two end stations must synchronizeon 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 TCPconnection 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

RG

A

CK

P

SH

R

ST

S

YN

F

IN

16-bit Window Size


Options (if any)

Data (if any)


44/77

44

Three-wayHandshake

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 aninitial value in the sequence number field in the header.

The sequence number is the Initial Sequence Number (ISN), is randomlychosen 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

WebServer

Note: ISNs do not start a 0 or 1.There are several reasons forthis including segments that maystill be in buffers and also

security issues. (Beyond thescope of this presentation.)


45/77

45

Three-wayHandshake

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 clientinitial sequence number plus 1.

This is called an expectational acknowledgementthe next bytethis 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=1678ACK=8564

SYN Received

SYN, ACK Received

WebServer


46/77

46

Three-wayHandshake

Step 3:

TCP client responds with a segment containing an ACK that is theresponse to the TCP SYN sent by the server.

The value in the acknowledgment number field contains one more than theinitial 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=1678ACK=8564

ACK,SEQ=8564

ACK=1679

SYN Received

SYN, ACK Received

ACK Received

WebServer

HTTP Request(GET)


47/77

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


48/77

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


49/77

49 Step 3: Client sends ACK=1679


50/77

50 Client now sends HTTP Request (GET) to Web Server


51/77

51

TCP: Connection Termination

1. When the client has no more data to send in the stream, it sends a segmentwith 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

RG

A

CK

P

SH

R

ST

S

YN

F

IN

16-bit Window Size


Options (if any)

Data (if any)


52/77

52

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 thanthe connection can handle.

0 15 16 31




4-bit HeaderLength

6-bit(Reserved)

U

RG

A

CK

P

SH

R

ST

S

YN

F

IN

16-bit Window Size


Options (if any)

Data (if any)

0 15 16 31


53/77

53


To govern the flow of data between devices, TCP uses a peer-to-peer flowcontrol 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 currentlyprepared to receive.

Window size is included in every TCP segment sent from client or server startingwith three-way handshake.

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




4-bit Header

Length

6-bit

(Reserved)

UR

G

AC

K

PS

H

RS

T

SY

N

FI

N 16-bit Window Size


Options (if any)

Data (if any)

0 15 16 31


54/77

54

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 anacknowledgment 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 anacknowledgement from the other host.

Client Example

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

Send Window Size = 10,000 bytes Server told the client that it can send the server

10,000 bytes before receiving an acknowledgment.




4-bit Header

Length

6-bit

(Reserved)

UR

G

AC

K

PS

H

RS

T

SY

N

FI

N 16-bit Window Size


Options (if any)

Data (if any)


55/77

55


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

0 15 16 31



56/77

56

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 windowsize sent by the receiving host) until it receives an ACK from the receiver.

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

A larger window size allows more data to be transmitted pendingacknowledgment.



4-bit Header

Length

6-bit

(Reserved)

UR

G

AC

K

PS

H

RS

T

SY

N

FI

N16-bit Window Size


Options (if any)

Data (if any)

SS f


57/77

57

This is known as a

Stop-and-Waitwindowing protocol.

Server must wait foracknowledgmentbefore continuing tosend data.

A better method? Sliding Windows

Next!

Send Window Byte:This is the last bytethat can be sent

before receiving anACK

Client

SEQ=1,001 (to 2,000)

WebServer

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


SEQ=10,001 (to 11,000)

SendWindow=5,000

Client has aWindow Size of5,000 bytes

MSS of 1,000 bytes


58/77

58

TCP Window Size TCP provides full-

duplex service,which means data

can be flowing ineach direction,independent of theother direction.

Receiver sendsacceptablewindow size to

sender duringeach segmenttransmission (flowcontrol)

If too much databeing sent,acceptable

window size isreduced If more data can

be handled,acceptablewindow size isincreased

Client

SEQ=1,001

WebServer

SEQ=2,001

SEQ=3,001

SEQ=4,001

ACK=5,001

SEQ=1

SEQ=6,001

SEQ=7,001

SEQ=8,001

SEQ=9,001

ACK=10,001

SEQ=5,001

.



Send Window:Byte 15,000SEQ=10,001

SendWindow=5,000


59/77

59

Sliding Window Protocol

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

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

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 slidingwindow 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 happenswhen 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 sentNot ACKed

Usable WindowCan send ASAP

Working Window size

Usable WindowCan send ASAP

Initial Window size

Sliding Windows

0 15 16 31




TCP Header


60/77

60

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 its

window over showing it has sent those 3 octets.

Host A will not increase its usable window size by 3, until it receives anACKnowldegement 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 octetsends 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


4-bit HeaderLength

6-bit(Reserved)

UR

G

AC

K

PS

H

RS

T

SY

N

FI

N16-bit Window Size


Options (if any)

Data (if any)

Host B - ReceiverHost A - Sender


61/77

61

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 keepsending data, not until the window size reaches the window size of 6, so itsends octets 4 and 5.

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

over to equal 6 octets, 3 octets sent not ACKed plus 3 octets which can besent 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


62/77

62

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

Window size = 6
http://www.dslreports.com/front/DRTCP020.zip


63/77

63

Default 8K for Windows, 32K for Linux,

There are various unix/linux/microsoft programs that allow you to modify the defaultwindow 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 thatproblems resulting from modifications to the registry can be solved. Use theinformation provided at your own risk.

NOTE: I take no responsibility for this software or any others!
http://www.dslreports.com/front/DRTCP020.zip


64/77

64

Client

SEQ=1,001

WebServer

SEQ=2,001

SEQ=3,001

SEQ=4,001

ACK=2,001

SEQ=1

SEQ=6,001

SEQ=7,001

SEQ=8,001

SEQ=9,001

Etc.

SEQ=5,001

ACK=6,001

Web Server has a:MSS of 1000 bytes

Client has aWindow Size of5,000 bytes

SEQ=10,001

Send Window: Byte 5,000



Server can now continue sending without having to wait for anacknowledgement.

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

SendWindow=5,000


65/77

65

Reliable Data Transfer

TCPs reliable data service is on top of IPs unreliable, best-effort service.

TCP uses a single retransmission timerfor all of its segments within aTCP 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 oldestunacknowledged segment sent.

We will use three simple examplesto explain how this works.

My reliable puppy Luigi

Scenario 1: Loss of an ACK


66/77

66

Client WebServer

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 RetransmissionTimer expires.

Retransmits segment.

Client

Receives segment butdiscards it.

Resends ACK

Web Server

Receives ACK

X(loss)

Timeout

(TCPRetransmissionTimer)

Scenario 2: ACK arrives after timer expires


67/77

67

Client WebServer 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 segmentwill not be retransmitted. Client:

Receives retransmitted SEQ=92segment.

Discards segment Re-sends ACK=120 for next byte

needed

seq 92

Timeout

seq 92Timeout

(TCPRetransmissionTimer)

This ACK tellsthe Web Serverthat bothsegments havebeen received.

W b

Scenario 3: Loss of first ACK


68/77

68

Client WebServer 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 hasreceived everything up to byte 119.

Does not need to resend either of the two

segments.

seq 92

Timeout

(TCPRetransmissionTimer)X

(loss)


69/77

69

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

Both hosts in the TCP connection constantly advertise their Window Size to theremote host in each segment sent.

Remember, TCP is a full duplex service data can be sent and received inboth 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

N16-bit Window Size


Options (if any)

Data (if any)

0 15 16 31




4-bit HeaderLength

6-bit(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N16-bit Window Size


Options (if any)

Data (if any)


70/77

70

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

The host may reduceits 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 increaseits 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

N16-bit Window Size


Options (if any)

Data (if any)

0 15 16 31




4-bit HeaderLength

6-bit(Reserved)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N16-bit Window Size


Options (if any)

Data (if any)

W b Send


71/77

71

Client

SEQ=1,001

WebServer

SEQ=2,001

SEQ=3,001

SEQ=4,001

ACK=2,001Window=7,000

SEQ=1

SEQ=6,001

SEQ=7,001

SEQ=8,001

SEQ=9,001

Etc.

SEQ=5,001

ACK=6,001Window=9,000

Web Server has a:MSS of 1000 bytes

Client has an initialWindow Size of5,000 bytes

SEQ=10,001




Client increases its Window Size.

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

SendWindow=5,000

L f


72/77

72

Last few notes

This has been a very brief look at TCP.

TCP has many components, some of which we have started to becomefamiliar with.

Some other TCP topics which may be of interest to you: Slow Start

SACK

NAK

Timer calculations

Congestion algorithms and windows

Whew!

0 15 16 31


UDP and TCP

TCP


73/77

73



4-bit Header

Length

6-bit

(Reserved)

URG

ACK

PSH

RST

SYN

FIN

16-bit Window Size


Options (if any)

Data (if any)

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

(No connection

establishment)

UDP


74/77

74

Although, published in 1994, writtenby the late Richard Stevens, it is stillregarded as the definitive book onTCP/IP.

TCP/IP Illustrated, Vol. 1W. Richard Stevens

Addison-Wesley Pub CoISBN: 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
http://www.amazon.com/exec/obidos/tg/stores/detail/-/books/0201633469/reader/2/102-0782088-5257725


75/77

75

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

Check Sequence Number to check for missing segments and tosequence out-of-order segments.

Remember that the ACK is for the sequence number of the byte youexpect to receive. When you ACK 101, that says you've received all

bytes through 100. This ignores SACK.

TCP MSS defines the


76/77

76

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 itsreported 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 negotiatesthe TCP segment size by using the maximum segment size (MSS) option field inthe 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)

maximum size of the datain the TCP segment.

Ethernet MTU defines themaximum size of the data inthe Ethernet frame.

The host using Ethernet, MTU of 1500octets so I will set my MSS to 1460.


77/77

Chapter 4

Transport Layer

CIS 81 Networking Fundamentals

Rick Graziani

Cabrillo College

[email protected]

Last Updated: 3/2/2008

cis81-e1-4-transportlayer

Documents