Transport Layer

transport layer provides logical communication between 2 processes on different hosts, the protocols are implemented in the end systems but not network routers

network layer provides logical communication between 2 hosts

• application = message

• transport = segment

• network = datagram

• link = frame

transport layer relies on the network layer and enhances the existing network layer services. [via the IP Service Model]

• transport layer (TL) converts messages from the application layer into segments by breaking down the message into chunks and adding a transport layer header - encapsulation

  • TL passes the segment to the network layer (NL) where the segment is encapsulated into a datagram and sent to the destination

• NL extracts the TL segment from the datagram and passes it up to the TL

• TL processes the segment and makes the data available to receiving application

network routers act on the NL only and do not examine the encapsulated TL segment fields

• UDP - unreliable, unordered delivery

• TCP - reliable, in-order delivery

these transport protocols from the transport layer provide transport services

• process-level addressing

• multiplexing and demultiplexing

• integrity checking

• connection management (establishment and termination)

• acknowledgements and retransmissions

• flow control

• congestion control

these services are provided by a combination of UDP and TCP specific services

• connection management (establishment and termination)

• acknowledgements and retransmissions

• flow control

• congestion control

TL differentiates between processes on applications, but the network layer identifies the actual hosts

used to pass data between correct application-level process and network, happens regardless of which protocol is used

error detection for when data is sent

provided if using a connection-oriented protocol (TCP)

provided if using a reliable service (TCP)

provided if using an in-order delivery service (TCP)

MUX and DMUX at transport layer enhances an existing network layer service

• enhaces the existing host-to-host delivery service into a process-to-process delivery service

on the sending host

• process of gathering data chunks from different sockets, encapsulating each chunk into segments and passing segments to the network layer

• data can be sent all in one go

on the destination host

unwrapping the received segments and delivering them to the correct socket

receiving host can have many sockets so each socket has a unique identifier

the type of socket used

• UDP socket for connectionless demultiplexing

• TCP socket for connection-oriented demultiplexing

• destination ip address

• destination port number

• source ip address

• source port number

• destination ip address

• destination port number

when (UDP or TCP) segment arrives from network to host, the host uses the type of socket, and its identifier to demultiplex the segment to the correct socket

• using UDP = send both segments to the same destination process using the same socket

• using TCP = send the segments to 2 separate sockets that are both made for the same process

• well known servers are used by http and have registered socket numbers eg. web server has port number 80

• when a client sends segments to a server all the segments (containing the initial connection request and all other requests) have the same destination port number [80]

• server differentiates segments from different clients using source socket identifier

• one to one correspondence

• multithreading

• each connection with a client causes the web server to spawn a new process

• each process has its own connection socket that can sent and receive HTTP requests

• P3 is a process, with a corresponding socket underneath

• server has 3 connections, therefore 3 processes are spawned, and a socket is assigned to each process

to prevent servers being overloaded with one on one requests servers can use multithreading

only 1 process is created and within that process new threads are created and attached to that process. each thread has a connection socket used for a client connection. as usual each socket has its own socket identifier

a lightweight sub-process

the server is now a threaded server, and only contains one process [P4] that has 3 threads attached which each have their own socket. for 3 client connections, they each use different sockets that are part of the same process

• take messages (payload) from application process - attaches source and destination port # for mux/demux, length, and checksum, and passes segment to network layer

• if segment arrives at host, UDP uses destination port # to deliver to correct socket

• process-level addressing

• multiplexing and demultiplexing

• light error checking

width 32 bits is relative to field size, eg. source port # is 16 bits, dest port # is 16 bits

header = 8 bytes

number of byes in UDP segment (including both header & payload)

• needed because size of payload differs from segment to segment

used by receiving host to check if the segment has errors

• sender treats segment content as a sequence of 16-bit integers and uses this to calculate the checksum for that segment (one’s complement sum of segment content)

• receiver recalculates the checksum and checks if this matches the checksum field

• processes must handshake to establish connection

• three way handshake procedure

• has a logical connection

• provides full-duplex service

• always point to point

preliminary segments are sent to each other to establish the parameters of the resultant data transfer

both sides will initialise many TCP state variables regarding the TCP connection

• client sends special TCP segment to server asking to initiate connection (no payload)

• server respond with special TCP segment to initiate or not (no payload)

• client sends special TCP segment (may contain payload)

TCP protocol runs on end systems only and not network elements (routers) - network elements are oblivious to TCP connection occurring

• application layer data can flow from process A to process B, and vice versa

• both hosts allocate a receive buffer and define a receive window variable

between one sender and one receiver

A TCP connection consists of the set of properties:

• {buffers, variables, and a socket connected to a process}

There is a set of these properties at each host- meaning each host at each side of the TCP connection has it’s own send and receive buffer

1. client process passes a stream of data through the socket

2. TCP running in the client directs data to the connection’s send buffer

3. TCP grabs chunks of data from send buffer

4. Maximum amount of data that can be grabbed and place in segment it defined by the Maximum Segment Size variable (MSS)

   • max size of the payload (application data), not max size of whole TCP segment (payload & headers)

   • calculate by getting length of the largest link layer frame that the host can send (Maximum Transmission Unit - MTU) to ensure the TCP segment encapsulated as a datagram + TCP/IP header length (40 bits) will fit in a frame

5. TCP pairs each chunk of data with a TCP header to form a TCP segment

6. segments passed to network layer where they are separately encapsulated into an IP datagram

7. IP datagram is sent into the network

8. when TCP receives a segment at other host, the segment’s payload is placed into the connection’s receive buffer

9. the application reads the stream of data from the receive buffer

blue highlight represents encapsulation and multiplexing as mentioned earlier

source port #

destination port #

checksum

sequence number

acknowledgement number

receive window

header length

options

flag

urgent data pointer

they don’t differ, the fields are the same

used by TCP sender and receiver for reliable data transfer

both are 32 bits each

used for flow control

16 bits

shows the length of the TCP header in 32-bit words

4 bits

the TCP header can vary in length depending if the Options field is used or not.

if options empty then header length = 20 bytes

optional fields used for negotiating MSS between hosts, window scaling factor for high speed networks, time stamping

has a variable length

contains 6 bits where each bit has a different meaning and use

• ACK bit - means the segment contains an acknowledgement (successfully received another segment)

• RST, SYN, FIN bits - used for connection setup and teardown

• CWR, ECE bits - used in explicit congestion notification

• PSH bit - indicates receiver should push data to the upper layer immediately

• URG bit - indicates there is data in the segment that is marked by the upper layer as urgent

points to the last byte of data that is marked as urgent

16 bits

⇒ byte-stream number of the first byte in the segment

• 500KB data (0 - 499,999) over 1KB MSS will be transmitted in 500 segments

• The first segment will have sequence number 0, the second segment will have sequence number 1,000, the third segment will have sequence number 2000, etc

⇒ the sequence number of the next byte the receiving host is expecting from the sender host

• when a receiving host is receiving the above data, after receiving the first segment it will send a segment containing acknowledgment number 1,000.

the acknowledgement number increment by 1 each time after each segment is sent since they are expecting segments to be sent in order - eg. server expects segment with sequence # 43, then segment with sequence # 44, client expects segment 79, then segment 80

the other host should then send a segment with the sequence number that the current host is expecting

IP alone has an unreliable best-effort service

TCP creates a reliable data transfer service on top of the standalone IP service

• ensures the data stream read from the receive buffer is uncorrupted

• not gaps or duplication and in-sequence

• byte stream sent is the same as the byte stream received

timeout- triggered retransmission

fast retransmit

a timer is started to measure the time between when a segment is sent and when an ACK for that segment is expected to be received by the sender → used to identify and recover lost segments.

1. TCP starts the time when a segment is passed to IP stack as long as the timer is not already running from a previous segment

2. If the ACK segment is not received in time a timeout occurs.

3. TCP retransmits the segment that caused the timeout and restarts the timer

4. When the ACK arrives the TCP compares the ACK value with the sequence number of the oldest unacknowledged byte

5. If there are issues with the ACK number then TCP restarts the timer if there are any unacknowledged segments

• if timeout period too long ⇒ when segment lost, the sender has to delay resending the lost packet which increased overall end-to-end delay

• if timeout period too short ⇒ the ACK may arrive after the timeout period causing unnecessary retransmission

an ACK acknowledges the receipt of all the bytes before the byte number. based on the ACK number the TCP sender can determine if there are any segments that were not acknowledged

the TCP sender can use duplicate acknowledgements sent by the receiver to detect packet loss before the timeout occurs

an ACK that acknowledges a segment that the sender has already received an acknowledgment for earlier on

1. TCP receiver receives the segment and checks sequence number

2. if the sequence number larger that expected it means there’s a gap in the in-order sequence data stream thus, missing segment (eg. sequence num = 99, then 101 when expecting 100)

3. receiver reacknowlges by sending an ACK for the last in-order byte of data it received (eg. send an ACK for 101 containing ACK number = 100 instead of using ACK number = 101)

   1. if sender is sending segments back to back then multiple duplicate ACKS can occur (eg. 3 segments trying to be send after the missing one, 101, 102, 103. instead of giving an ACK for each of those numbers, duplicates the ACK# = 100 3 times)

4. if sender received the duplicate ACKS - eg. 3 duplicate ACKs for 100, means that the segment with the same ACK number needs to be sent (eg. need to resend segment 100)

5. sender performs a fast retransmit of the missing segment before the segment timer expires

a speed matching service that matches the rate at which sender is sending against rate that receiving application is reading

if application is slow at reading data ten sender can overflow the connection’s receive buffer by sending too much data too quick

1. Sender has a variable called receive window

2. TCP is full duplex so both hosts allocate and define a receive window variable

3. when an application reads data it takes it out from the receive buffer.

4. the receiver knows the last byte read and the last byte received. the receive window is calculated.

5. the sender uses the receive window to know how much data to send

memory to store the payload of segments

a variable showing to the sender how much free buffer space is available at the receiver

the receive window value is sent to the TCP header and because no overflow is permitted the receive window is always ≤ receive buffer

connection establishment

connection termination

a three-way handshake procedure to form a connection between 2 hosts before data can be sent

made up of 3 parts:

• SYN segment

• SYN/ACK segment

• ACK segment

1. client sends special segment to server

   1. segment contains no application layer data

   2. SYNbit in header = 1

   3. client randomly chooses initial sequence number to add to sequence number field (client_isn)

2. server receives SYN segments and allocates the TCP buffers and variables to that side of the connection

3. sends special segment to client

   1. sets SYNbit = 1 in header and ACKbit = 1

   2. sets ACK# to client_isn + 1 and adds to header

   3. chooses random number to be initial sequence number (server_isn) and adds to header

   4. sends connection-granted segment to client where SYN bit = 1

   5. does not contain application layer data in payload

4. client receives SYN/ACK and allocates TCP buffers and variables to that side of the connection

5. sends special segment to server acknowledging that connection-granted segment

   1. SYNbit = 0, ACKbit = 1, SEQ# = client_isn + 1 , ACK# = server_isn + 1

   2. can contain application layer data in payload

either process can end the connection

when connection ends the resources - [buffers / variables] in the host are deallocated

1. client application process issues close command

2. client TCP sends special segment to server

   1. FINbit = 1

3. server receives segment and sends an ACK segment for it (where ACKbit = 1)

4. server sends a special shutdown segment

   1. FINbit = 1

5. client receives the segment and sends and ACK segment for it

6. resources in the host are deallocated

TCP must use end-to-end (between sender and path to receiver) congestion control rather than network-assisted congestion control, since the IP layer provides no explicit feedback to the end systems regarding network congestion

sender limits the rate at which it senders traffic into its connection based on the function of its perceived network congestion

1. perceives little congestion = increase send rate, high congestion = reduce send rate : inverse relationship

2. the TCP perceives the network congestion based on the amount of packet loss and/or delayed acknowledgements (high ACK rate = perceived congestion free)

3. congestion-control mechanism at sender manages a variable called congestion window (cwnd)

4. CWND imposes constraints on the rate that the sender can send traffic into the network, the sender cannot send an amount of unacknowledged data into the network that is greater than the minimum value of the congestion window or the receive window

LastByteSent − LastByteAcked ≤ min{cwnd, rwnd}

the TCP sender’s rate increases when receiving ACKs until a loss event occurs, then the transmission rate is decreased

the way bandwidth probing occurs

1. additive increase - cwnd by 1 MSS every RTT until loss detected

2. loss occurs

3. multiplicative decreases the bandwidth - cut cwnd in half after loss

• application-level control

• minimum sending rate where loss tolerated but not delay

• no connection establishment delay

• no client-server connection state so can manage more request

• smaller size due to smaller 8 byte header vs. 20 byte