Computer network [top-down] - transport layer

1. Principles of reliable data transmission

reliable data transfer protocol (rdt)

In the case of best-effort services provided by the lower layer, reliable services are provided to the upper layer through this layer.

1. Stop waiting for the agreement

1.1, Rdt1.0 Reliable data transmission on reliable channels

• The lower layer channel is completely reliable
  • No bits are wrong
  • No packets are lost
• FSM for sender and receiver
  • The sender sends data to the lower channel
  • The receiver receives data from the lower layer channel

1.2, Rdt2.0 channel with only bit errors

• Lower layer channel may be in error: flip bits in packet

  • Use checksums to detect bit errors

• Question: How to recover from errors:

  • Acknowledgment (ACK): The receiver explicitly tells the sender that the packet has been received correctly
  • Negative Acknowledgment (NAK): The receiver explicitly tells the sender that an error occurred in the packet
    • After the sender receives the NAK, the sender retransmits the packet.

• New mechanism in rdt2.0: error detection using error control coding

  • Send variance error mechanism encoding and caching
  • Receiver uses encoding error detection
  • Feedback from the receiver: control message (ACK, NAK); receiver → sender
  • The sender takes corresponding actions after receiving the feedback

  Text description:
  The sender sends data. After receiving the data, the receiver performs data verification.
  If there is no problem, an ACK (confirmation) is sent back to the sender. After parsing the data, the data is provided to the upper layer through the previous interface. ;
  If the verification fails, reply to the sender with a NAK (reverse acknowledgment);
  after the sender receives the NAK, it resends the original data until it receives the ACK, and then continues to send the subsequent data.

1.3, Rdt2.1: ACK/NAK with error from the sender

A pkt version is added based on rdt2.0. There may be duplication (just don't deliver it to the upper layer), but there will be no errors.

rdt2.1 process:

• sender:
  • Add serial number to group
  • Two sequence numbers (0, 1) are enough
    • Only send one unacknowledged packet at a time
  • Must detect whether ACK/NAK is wrong (requires EDC)
  • The number of states has doubled
    • It is necessary to remember whether the sequence number of the current group is 0 or 1
• receiver
  • Must detect whether received packets are duplicates
    • The status will indicate whether the sequence number of the packet expected to be received is 0 or 1
  • Note: The receiver does not know whether the sender received its ACK/NAK correctly
    • Confirmation without scheduled confirmation

1.4, Rdt2.2: NAK-free protocol

The function is the same as rdt2.1, but it only lacks a NAK reverse confirmation and uses ACK (0 and 1 sequence numbers) for confirmation.

1.5, Rdt3.0: Channels with bit errors and packet loss

• New assumption: packets (data or ACK) may be lost on the lower layer channel
  • Will deadlock
  • The mechanism is not adequate to handle this situation
    • checksum
    • serial number
    • ACK
    • Retransmission
• Method: The sender waits for ACK for a reasonable period of time
  • The sender times out and retransmits: If no ACK is received by then → retransmit
  • Problem: If the packet (or ACK) is simply delayed:
    • Retransmission will result in data duplication, but this problem can be solved using sequence numbers.
    • The receiver must specify the sequence number that was correctly received
  • Need a countdown timer
    

2. Pipeline protocol

Pipeline: Run the sender to send multiple packets at once without receiving confirmation from the other party

• The range of sequence numbers must be increased: use multiple bits to represent the sequence number of the group
• There needs to be a buffer on the sender/receiver side
  • Sender buffer: not acknowledged, may need to be retransmitted;
  • Receiver's cache: the rate at which upper-level users access data = the rate of received data: the received data may be out of order, sorted and delivered (checkable)
• Two common pipeline protocols: backoff N steps (GBN) and selective retransmission (SR)
  • GBN:RW=1, cannot be received out of order
  • SR: RW>1, packets within the receiving window can be received out of order, but cannot be delivered, and the receiving window cannot slide forward.

2.1. Sliding window protocol

• Send buffer:
  • Form: an area in memory where packets falling into the buffer can be sent
  • Function: used to store packets that have been sent but not confirmed
  • Necessity: available when resending is required
• The size of the send buffer: the maximum number of unacknowledged packets that can be sent at one time
  • Stop waiting for protocol=1
  • Pipeline protocol > 1, reasonable value, cannot be very large, link utilization cannot exceed 100%
• Send buffered packets
  • What has not happened : Packets falling into the sending buffer can be sent out continuously.
  • Packets that have been sent and are waiting for confirmation from the other party: the packets in the sending buffer can only be deleted when they are confirmed

Similarities and differences between GBN protocol and SR protocol

• Similarities
  • Send window>1
  • Ability to send multiple unacknowledged packets at one time
• the difference
  • GBN: receive window size=1
    • Receiving end: can only receive sequentially
    • Sender: From the performance point of view, once a packet is not sent successfully, such as: 0, 1, 2, 3, 4
      • If 1 is not successful, 2, 3, and 4 are all sent out, return 1 and then generate GBN
  • SR: receive window size>1
    • Receiving end: can receive out of order
    • Sending end: send 0, 1, 2, 3, 4, once 1 is not successful, 2, 3, 4 has been sent, no need to resend, selectively send 1

Go back N steps GBN

Select retransmit SR

2. Multiplexing

1. Transmission services and protocols

• Provides logical communication between application processes running on different hosts
• The transport protocol runs on the end system
  • Sender: divide the application layer message into message segments, and then pass it to the network layer
  • Receiver: reassemble the message segment into a message, and then pass it to the application layer
• Multiple transport layer protocols are available for applications to choose from
  • Internet: TCP and UDP

2. Transport layer VS network layer

• Network layer services: logical communication between hosts
• Transport layer services: logical communication between processes
  • Services that depend on the network layer
    • Delay, bandwidth
  • And enhance the service process of the network layer
    • Data loss, confusion, encryption

Add the header data through the downward transfer through the Socket, and finally transfer it to the target end through the network card, and then perform demultiplexing

3. Multiplexing/demultiplexing

• Multiplexed at the sender host
  • Receive messages from multiple processes from multiple sockets, and encapsulate the message segments with headers based on the IP address and port number corresponding to the socket (the header information is used for subsequent demultiplexing)
• Demultiplexing at the receiver host
  • Send the received message segment to the correct socket (and the corresponding application process) according to the IP address and port number in the header information of the message segment

3. Connectionless transmission of UDP

• Best-effort service segments may be lost
  • lost
  • Message segments sent to the application process are out of order
• UDP is used for:
  • Streaming media (loss-insensitive, rate-sensitive)

1. UDP: User Datagram Protocol

Why UDP?

• No connection is established (will increase latency)
• Simple: no connection state between sender and receiver
• The header of the message segment is small (low overhead)
• No congestion control and flow control

4. Connection-oriented transmission TCP

1. TCP: Overview

• peer to peer:

  • One sender, one receiver

• Reliable, sequential byte stream

  • without borders

• Pipeline (assembly line):

  • TCP congestion control and flow control set window size

• Send and receive cache

• Full duplex data

  • Data flows in both directions on the same connection
  • MSS: Maximum segment size

• connection oriented

  • Before data exchange, the state variables of the sender and receiver are initialized through handshake (exchange of control messages)

• With flow control:

  • The sender will not overwhelm the receiver
    

• Serial number:

  • The number of the first byte of the message segment in the byte stream

• Confirmation Number

  • The sequence number of the next byte expected to be received from the other party
  • Cumulative confirmations

• How does the receiver deal with out-of-order

2. TCP round trip delay (RTT) and timeout

• How to set TCP timeout
  • longer than RTT
    • But RTT changes
  • Too short: Timeout too early
    • Unnecessary retransmission
  • Too long: reaction to segment loss is too slow and negative
• How to estimate RTT
  • SampleRTT: Measures the time from when a message segment is sent to when the acknowledgment is received
    • If there is a retransmission, ignore this measurement
  • SampleRTT will vary, so the estimated RTT should be smoother
    • Average several recent measurements instead of just the current SampleRTT

3. TCP: reliable data transmission

• TCP builds rdt on IP unreliable range
  • Pipelined segments
    • GBN or SR
  • Cumulative confirmations (like GBN)
  • Single retransmission timer (like GBN)
  • Whether out-of-order is acceptable, there is no standard
• Retransmission is triggered by the following events
  • Timeout (resend only the oldest unacknowledged segment: SR)
  • Duplicate confirmation
    • Example: Received ACK50, then received 3 more ACK50
• Consider first the simplified TCP sender:
  • Ignore duplicate confirmations
  • Ignore flow control and congestion control

4. TCP connection management

Before formally exchanging data, the sender and receiver shake hands to establish the communication relationship:

• Agree to establish a connection (each party knows that the other is willing to establish a connection)
• Agree on connection parameters

Two handshakes to establish connection

• question:
  • The server will have many half-connections
  • Problem with receiving old data

5. Three-way handshake solution: semi-connection and receiving old data problems

s: Select the initial sequence number to tell the server that the server has received it; then tell the client that it has received it, and also tell the client the server's initial sequence number; after the client receives the server's initial sequence number, it then tells the server that it has received your initial sequence number. serial number

6. TCP closes the connection:

• The client and the server respectively close the connection on their own side
  • Send TCP segment with FIN bit=1
• Once FIN is received, respond with ACK
  • Received FIN, ACK can be sent together with its own FIN segment
• Can handle simultaneous FIN exchanges
• 

5. Congestion Control

1. Congestion control principle

congestion:

• Informal definition: "Too much data needs to be transmitted over the network, exceeding the network's processing capabilities."
• Unlike flow control
• Manifestations of congestion:
  • Packet loss (router buffer overflow)
  • The packet experiences a relatively long delay (queuing in the router's queue)
  • The most serious situation will be network deadlock, where there is only network in and no network out.

2. Congestion control method

2 commonly used congestion control methods:

• End-to-end congestion control:
  • No display feedback from the network
  • End systems infer whether there is congestion based on delay and loss events
  • The method used by TCP

• Network-Assisted Congestion Control: ATM
  • The router provides feedback information to the end system
    • A single bit is set to indicate congestion (SNA, DECbit, TCP/IP ECN AIM)
    • Shows the rate available to the sender

TCP congestion control:

congestion awareness

How does the sender detect congestion?

• A segment has timed out (lost event); congestion
  • The timeout period has expired and the confirmation for a certain segment has not come.
  • Reason 1: There is a high probability of network congestion (a router buffer has no space and is discarded)
  • Reason 2: Errors were discarded (errors at all levels, failed verification, discarded) probability is small
  • Once it times out, it is considered to be congested. There is a certain misjudgment, but the overall control direction is correct.
• 3 duplicate ACKs about a segment: slight congestion
  • The first ack of the segment, normal, confirm the green segment, expect the red segment

rate control method

How to control the rate sent by the sender

• CongWin is dynamic and is a function of perceived network congestion
  • Timeout or 3 repeated acks, CongWin;
    • CongWin drops to 1Mss when timeout, enters the SS phase and then doubles to CongWin/2 (each RTT), thus entering the CA phase
    • 3 repeated acks; CongWin is reduced to CongWin/2, CA stage

Why is TCP fair?

Two competing TCP sessions:

• Additivity increases, slope is 1, throughput increases
• Multiplicative reduction, throughput decreases proportionally
•