Chapter 4 Transport Layer - univ-reims.fr4 UDP TCP TCP/UDP TCP/UDP The Layer 4 data stream is a: Logical connection between the endpoints Provides transport services5 HTTP Data Header

Chapter 4 Transport Layer

2

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

3

Application Header + data

TCP Header UDP Header

or

PDU: Segment

PDU: Data

What is the application PDU called?

What is the transport PDU called?

4

UDP

TCP

TCP/UDP TCP/UDP

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

  End-to-end service

5

Data HTTP Header

TCP Header

IP Header

Data Link Header

Data Link Trailer

IP Packet Data Link Header

Data Link Trailer IP Packet Data Link

Header Data Link Trailer







Data HTTP Header

TCP Header

IP Header

Data Link Header

Data Link Trailer

Reminder of encapsulation/decapsulation

6

Focus on Transport Layer TCP

TCP

7

  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

TCP Segment

TCP Segment

TCP Segment

8

  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

9

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

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.

10

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

TCP TCP

TCP

TCP

TCP

TCP

HTTP HTTP

FTP

UDP

SMTP

UDP

Web Server

ISP’s Email and FTP Server

Port Numbers: TCP and UDP

12

  Both TCP and UDP use ports (or sockets) numbers to pass information to the upper layers.

TCP Header

HTTP is Port 80

UDP Header

13

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.

14

Application Header + data Port numbers are used by

the receiver so it knows which application it should

send the “Data” to.

Application Header + data Port numbers are used to

by the sender to tell the receiver which network

application it should use for the “Data”.

Port Number

Port Number

15

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

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

16

  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


17



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

18

  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


Private/Dynamic Port Number

19

Client Server

Telnet

20

  Client sends TCP segment with:   Destination Port: 23 (Well known port number)   Source Port: 1028 (Dynamic Port assigned by client)

Client TCP Header

23 1028

Data for Telnet

Client Server

21

  Server responds with TCP segment with:   Destination Port: 1028 (Dynamic Port assigned by client)   Source Port: 23 (Well known port number)

Server TCP Header 1028 23

Data for Telnet

Client Server

22

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)

23

  Same client to same server - Two different HTTP sessions   Client: Same destination port   Client: Different source ports to uniquely identify this web session.

49890 49888

24

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

49890 49888

25

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

80 80 80

Source Port

49890

49888

Source Port

198.133.219.25 49888

www.cisco.com

26

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

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

TCP or UDP Source Port

Destination IP Destination Port

Connection State Source IP

27

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

29

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

?

30

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

31

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

32

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.

Time

UDP segment UDP segment UDP segment UDP segment

Client Server

33

UDP

  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

Time

UDP segment UDP segment UDP segment UDP segment

Client Server

34

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.

35

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?

Connection-oriented Transport: TCP

37

TCP

  TCP provides reliable delivery on top of unreliable IP   TCP provides:

  Reliable delivery   Error checking   Flow control   Congestion control   Ordered delivery   Connection establishment

38

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

39

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.

40

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

41

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

42

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)

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

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

45   Step 3: Client sends ACK=1679

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

47

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.

48

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.

49

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.

Client Window Size=5,000

Server Window

Size=10,000

50

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,000 Server’s Send Window: 10,000

My Receive Window: 10,000 My 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.”

51

Flow Control and Reliability

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 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 aWindow Size of 5,000 bytes

…

TCP 1-1000 TCP Segment

52

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.

53

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

. Client Window Size=5,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

54

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

….



Server Window

Size=10,000

Server Window

Size=10,000

…

…



Server Window

Size=10,000

… SEQ=10,001 – 11,000

Send Window=5,000

55

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

56

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

TCP Header

57

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 - Receiver Host A - Sender

58

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 - Receiver Host A - Sender

Window size = 6

59

  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!

60

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


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

61

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.

62

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

63

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, 8 bytes data seq 92 Timeout


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

FYI Scenario 2: ACK arrives after timer expires

64

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



FYI Scenario 3: Loss of first ACK

X (loss)

65

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.

66

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.

67

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

Window=5,000

68

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)

UDP

Chapter 4 Transport Layer - univ-reims.fr4 UDP TCP TCP/UDP TCP/UDP The Layer 4 data stream is a: Logical connection between the endpoints Provides transport services5 HTTP Data Header

Documents