FIT3165 / FIT4165 COMPUTER NETWORKS
WEEK 4 – TRANSPORT LAYER – PART 2
Faculty of Information Technology © 2021 Monash University
Copyright By PowCoder代写 加微信 powcoder
3.3 USER DATAGRAM PROTOCOL
3.4 TRANSMISSION CONTROL PROTOCOL
USER DATAGRAM PROTOCOL
Some well-known ports used with UDP and TCP
• The User Datagram Protocol (UDP) is a connectionless, unreliable transport protocol.
• It does not add anything to the services of IP except for providing process-to-process instead of host-to-host communication.
• UDP packets, called user datagrams, has a fixed size header of 8 bytes made of four fields, each of 2 bytes (16 bits).
• UDP is a very simple protocol • using a minimum of overhead.
The figure above shows the format of a user datagram. The first two fields define the source and destination port numbers.
• The third field defines the total length of the user datagram, header plus data. The 16 bits can define a total length of 0 to 65,535 bytes.
The following is the contents of a UDP header in hexadecimal format.
a. What is the source port number?
○ The source port number is the first four hexadecimal digits (CB84)16 or (52100)10 b. What is the destination port number
○ The destination port number is the second four hexadecimal digits (000D)16 or (13)10. c. What is the total length of the user datagram?
○ The third four hexadecimal digits (001C)16 define the length of the whole UDP packet is 28 bytes. d. What is the length of the data?
○ The length of the data is the length of the whole packet minus the length of the header, or 28 − 8 = 20 bytes. e. Is the packet directed from a client to a server or vice-versa?
○ Since the destination port number is 13 (well-known port), the packet is from the client to the server. A server listens for UDP datagrams on UDP port 13.
f. What is the client process
○ The client process is the Daytime request. When a datagram is received, from server containing the current date and time
CB84000D001C001C
UDP Services
❑ Process-to-Process Communication
❑ Connectionless Services
❑ No flow Control
❑ No error Control
❑ Congestion Control
❑ Checksum (an optional inclusion)
❑ Encapsulation and Decapsulation
❑ Multiplexing and Demultiplexing
❑ Comparison : UDP and Simple Protocol
UDP Queues
Multiplexing and Demultiplexing
Example – UDP pseudo header for checksum calculation
• Initial checksum= 0000000000000000
• Then [ Pseudo-header + header +
data ] calculate the checksum
• Then discard the Pseudoheader
0000000000…00
Figure : UDP Pseudo-header for checksum calculation
Example – UDP checksum calculation -1
Example – UDP checksum calculation -2
What value is sent for the checksum in one of the following hypothetical situations?
1. The sender decides not to include the checksum.
The value sent for the checksum field is all 0s to show that the checksum is not calculated.
2. The sender decides to include the checksum, but the value of the checksum is all 1s.
When the sender computes the checksum, the result is all 0s; in such situations the sender complements the result again before sending it. The value sent for the checksum is now all 1s. The second complement operation is needed to avoid confusion with the case in part a.
UDP Applications
• Although UDP does not meet any of the criteria we mentioned earlier for a reliable transport-layer protocol, UDP is preferable for some applications.
• The reason is that some services may have some side effects that are either unacceptable or not preferable. An application designer sometimes needs to compromise to get the optimum results.
• In this section, we first discuss some features of UDP that may need to be considered when one designs an application program and then show some typical applications.
❑ UDP Features ❑ Typical Applications
❖ Connectionless Service
❖ Lack of Error Control
❖ Lack of Congestion Control
UDP Applications – DNS
• A client-server application such as DNS uses the services of UDP because a client needs to send a short request to a server and to receive a quick response from it.
• The request and response can each fit in one user datagram.
• Since only one message is exchanged in each direction, the connectionless
feature is not an issue;
• the client or server does not worry that messages are delivered out of order.
UDP Applications
Can we use UDP for SMTP?
○ A client-server application such as SMTP, which is used in electronic mail, cannot use the services of UDP because a user can send a long e-mail message, which may include multimedia (images, audio, or video).
○ If the application uses UDP and the message does not fit in one single user datagram, the message must be split by the application into different user datagrams. Here the connectionless service may create problems. The user datagrams may arrive and be delivered to the receiver application out of order.
○ The receiver application may not be able to reorder the pieces. This means the connectionless service has a disadvantage for an application program that sends long messages.
Can we use UDP for FTP?
○ Assume we are downloading a very large text file from the Internet. (FTP)
○ We definitely need to use a transport layer that provides reliable service. We don’t want part of the file to be missing or corrupted when we open the file.
○ The delay created between the deliveries of the parts is not an overriding concern for us; we wait until the whole file is composed before looking at it.
○ In this case, UDP is not a suitable transport layer protocol.
TRANSMISSION CONTROL PROTOCOL
Transmission Control Protocol
• Transmission Control Protocol (TCP) is a connection-oriented, reliable protocol.
• TCP explicitly defines connection establishment, data transfer, and connection teardown
phases to provide a connection-oriented service.
• TCP uses a combination of GBN and SR flow & error control protocols to provide reliability.
Process-to-Process Communication Stream Delivery Service
Sending and Receiving Buffers Segments
Full-Duplex Communication
Multiplexing and Demultiplexing Connection-Oriented Service Reliable Service
Transmission Control Protocol – Stream and segments
Figure: Stream delivery Figure: TCP segments
TCP Segment format and encapsulation
Figure: TCP segment format Figure: Control field
TCP Connection
• TCP is connection-oriented.
• Connection-oriented transport protocol establishes a logical path between the source and
destination.
• All of the segments belonging to a message are then sent over this logical path.
• Using a single logical pathway for the entire message facilitates the acknowledgment process as well as retransmission of damaged or lost segments.
Connection Establishment
Three-Way TCP Handshaking
SYN Flooding Attack
Data Transfer
Connection Termination
❖ Three-Way Handshaking
❖ Half-Close
Connection Reset
❖ Pushing Data
❖ Urgent Data
TCP Connection establishment using 3-way handshake
TCP – Data transfer
TCP – Connection termination 3-way handshaking
TCP – Half close
TCP – Timeline for a common scenario
TCP – Send Window
• TCP uses two windows (send window and receive window) for each direction of data transfer, which means four windows for a bidirectional communication.
• To make the discussion simple, we make an unrealistic unidirectional; the bidirectional communication can be inferred using two unidirectional communications with piggybacking.
❑ Send Window
❑ Receive Window
Figure: Send window in TCP
TCP – Receive Window
Figure: Receive window in TCP
TCP – Send and receive window
TCP – Flow control
• flow control balances the rate a producer creates data with the rate a consumer consuming the data.
• TCP separates flow control from error control.
• TCP adopts Go Back-N and Selective Repeat protocols.
• We assume that the logical channel between the sending and receiving TCP is error-free.
TCP – Data flow and flow control feedback
TCP – Error control
TCP is a reliable transport-layer protocol.
This means that an application program that delivers a stream of data to TCP relies on TCP to deliver the entire stream to the application program on the other end in order, without error, and without any part lost or duplicated.
Checksum Acknowledgment
❖ Cumulative Acknowledgment (ACK)
❖ Selective Acknowledgment (SACK)
Generating Acknowledgments Retransmission
❖ Retransmission after RTO
❖ Retransmission after Three Duplicate ACK
Out-of-Order Segments
TCP – Error Control – Scenario – Normal operation -1
Rule-1: It must include (piggyback) an acknowledgment that gives the next sequence number it expects to receive
TCP – Error Control – Scenario – Normal operation – 2
Rule-2: When the receiver has no data to send and it receives an in-order segment, the receiver delays sending an ACK segment until another segment ACK segments do not consume sequence numbers and are not acknowledged, arrives or until a period of time (normally 500 ms) has passed. This rule reduces ACK segments.
TCP – Error Control – Scenario – Lost segment – 1
Rule-3: When a segment arrives with a sequence number that is expected by the receiver, and the previous in-order segment has not been acknowledged, the receiver immediately sends an ACK segment. In other words, there should not be more than two in-order unacknowledged segments at any time. This prevents the unnecessary retransmission of segments that may create congestion in the network.
TCP – Error Control – Scenario – Lost segment – 2
RULE-4:When a segment arrives with an out-of-order sequence number that is higher than expected, the receiver immediately sends an ACK segment announcing the sequence number of the next expected segment. This leads to the fast retransmission of missing segments.
TCP – Error Control – Scenario – Lost segment – 3
RULE-5: When a missing segment arrives, the receiver sends an ACK segment to announce the next sequence number expected. This informs the receiver that segments reported missing have been received.
TCP – Error Control – Scenario – Fast retransmission
A fast retransmit algorithm is used when three duplicate ACKs are detected as packet loss.
TCP – Error Control – Scenario – Lost acknowledgement
TCP uses cumulative acknowledgment. We can say that the next acknowledgment automatically corrects the loss of the previous acknowledgment.
TCP – Error Control – Scenario – Lost acknowledgement corrected by resending a segment
Figure shows a scenario in which an acknowledgment is lost. If the next acknowledgment is delayed for a long time or there is no next acknowledgment (the lost acknowledgment is the last one sent), the correction is triggered by the RTO timer. A duplicate segment is the result.
TCP – Congestion control
• TCP uses different policies to handle the congestion in the network.
Congestion Window Congestion Detection Congestion Policies
❖ Slow Start: Exponential Increase
❖ Congestion Avoidance: Additive Increase
Policy Transition
❖ Taho TCP
❖ Reno TCP
❖ NewReno TCP
Additive Increase, Multiplicative Decrease TCP Throughput
TCP – Congestion policies – slow start – exponential increase
TCP – Congestion policies – Congestion avoidance, additive increase
TCP-Policy Transition – TCP Tahoe
1. A fast retransmit algorithm is used when duplicate ACKs are detected as packet loss.
2. TCP Tahoe is the simplest one out of all variants. It doesn’t have fast recovery. At congestion avoidance phase, it treats the triple(3) duplicate ACKs same as timeout. When timeout or triple duplicate ACKs is received, it will perform fast retransmit, reduce congestion window to 1, and enters slow-start phase.
TCP-Policy Transition – TCP Reno
Additive Increase, Multiplicative Decrease (AIMD)
• The additive-increase/multiplicative-decrease (AIMD) algorithm is a feedback control algorithm best known for its use in TCP congestion control.
• AIMD combines linear growth of the congestion window with an exponential reduction when a congestion takes place.
● So far we have discussed ○ UDP
● Next week
○ TCP/IP Protocol Stack – Network Layer
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com