Download
1 / 122
1.22k likes | 1.27k Views
MITM753: Advanced Computer Networks. Chapter 3 Transport Layer. Introduction. A transport-layer protocol provides for logical communication between processes running on different hosts. From an application’s perspective, it is as if the source and destination hosts are directly connected.
E N D
MITM753: Advanced Computer Networks Chapter 3 Transport Layer
Introduction • A transport-layer protocol provides for logical communication between processes running on different hosts. • From an application’s perspective, it is as if the source and destination hosts are directly connected. • Simplify programming task – no need to worry about the complicated infrastructure in between. • Transport-layer protocols are only implemented in end systems.
Introduction • Upon receiving a message from the application layer, the transport layer: • Break the message into smaller chunks • Attach a transport-layer header on each chunk to create a transport-layer segment. • Pass each segment to the network layer. • On the receiving side, the transport layer: • Receive segments from the network layer. • Read and process the header. • Pass the message to the application layer.
Transport Layer in the Internet • The Internet provides two transport-layer protocols that can be used by applications: • UDP (user datagram protocol) • TCP (transmission control protocol) • An application needs to choose either one of the two protocols above. • Which protocol to choose depends on the application’s requirements. • The services provided by UDP and TCP extends the services provided by Internet’s network layer protocol (IP).
Transport Layer in the Internet • The IP service model is a best-effort delivery service. • It makes its “best effort” to deliver segments to receiving host, but it makes no guarantees. • IP is said to be an unreliable service. • UDP provides two minimal services: • Process-to-process delivery • Error checking • UDP is also an unreliable service.
Transport Layer in the Internet • TCP provides the following services: • Process-to-process delivery • Error checking • Reliable data transfer • Using flow control, sequence number, acknowledgement and timers. • Congestion control • A service for the general good (most of the time, it is not good for the application itself). • Regulate the rate at which sending-side TCPs can send traffic into the network.
Process-to-Process Delivery • A host may run one or more network programs. • A network program may have one or more sockets. • A socket is a “door” between a process and the network. • Each socket is tied to a particular receiver. • Each socket has a unique identifier • One important task of a transport-layer protocol is to make sure the received data is directed to the correct process. • Done using the port number.
Process-to-Process Delivery • A port number is a 16-bit value (ranging from 0 to 65535) that identifies a socket. • Since a socket is tied to an application process, a port number also identifies a particular process. • Port number from 0 to 1023 are well know port numbers reserved for well-known application protocols. • Well-known port numbers are defined in RFC 1700 and RFC 3232. • Example: HTTP – port 80, FTP – port 21, etc. • These reserved port numbers only apply on the server side. • When we develop a new application we must assign it a port number that does not conflict with existing applications.
Process-to-Process Delivery • Upon receiving a segment from the network, the transport-layer implementation in the operating system will: • Check the destination port number • Send the segment to the corresponding process • What would be the use of the source port number in the header? • For replying the message • It is important that the message is replied to the process that sends the message in the first place
Process-to-Process Delivery • Sometimes a process may spawn another process or create a new thread to service each new client connection. • Example: in high-performing Web servers • The new process or thread may have the same port number as the main process • In this case, the source port number, the destination port number and the source IP address are needed to identify the correct receiving process.
Connectionless Transport: UDP • UDP (RFC 768) does as minimum as a transport protocol can do. UDP only does: • Process-to-process delivery • Error checking • Other than that, UDP adds nothing more to the functionalities provided by IP. • Even without reliability mechanism, UDP may be more suitable for certain applications. This is due to the following reasons:
Connectionless Transport: UDP • Finer application-level control on what data is sent and when • Segment transmission will not be delayed by the reliability and congestion control mechanism • No connection establishment • No delay in establishing connection before data transfer • No connection state • Use less memory and system resources • Small packet overhead • Smaller segment size
Connectionless Transport: UDP • It is still possible for applications using UDP to have reliable data transfer. • Implement reliability mechanism inside the application itself. • Involved implementing retransmission and acknowledgement mechanism. • Implemented by many streaming applications. • Having too many applications using UDP can be dangerous to the network. • Applications send too many packets in the network. • Possibly causing severe congestion.
UDP Segment Structure • Source and destination port numbers: • Identify sending and receiving process • Length: • The length of the entire UDP segment • Specified in bytes • Checksum: • Contains error detection codes • Used for error checking
UDP Checksum • The checksum code is generated by the sender. • The receiver use the code to check whether the received data contains any bit errors or not. • Although UDP provides error checking, it does not do anything to recover from an error. • Because UDP provides no reliable data transfer mechanism. • Depending on implementation, UDP might: • Discard the damaged segment. • Pass the damaged segment to the application with a warning.
Error Detection and Correction Techniques • Many transport, network and link layer protocols provide a mechanism for detecting errors. • Some mechanisms can also correct simple errors. • Error correction and detection techniques involve attaching an error detection and correction code to the packet. • These techniques allow the receiver to sometimes (but not always) detect bit errors. • There is always a small probability of having undetected bit errors. • With more sophisticated techniques, the probability of having undetected bit errors will be lower. • But this may require more computation and overhead.
Parity Checks • The simplest form of error detection. • Adds a single parity bit at the end of the data. • Two types: • Even parity: the parity bit is added such that the total number of 1s is even. • Odd parity: the parity bit is added such that the total number of 1s is odd.
Parity Checks • Can only detect errors if odd number of bits are corrupted. • 1, 3, 5, 7, etc. • In computer networks, errors are often clustered together in bursts (bursty errors). • When error occurs, a group of bits are affected. • If parity check is used, the probability of undetected bit errors can reach 50%. • Only used in simple data transmission such as transmission over a serial cable.
Two-dimensional Parity Scheme • This scheme not only can detect bit errors, but it can also correct a single bit error. • The data bits are divided into i rows and j columns. • A parity value is computed for each row and column.
Checksum • Sum a sequence of k-bit integers, and use the result as error detection bits. • Used in TCP, UDP and IPv4. • Requires a relatively low packet overhead. • In TCP / UDP, only 16 bits is required in the header to carry the error detection bits. • Better than parity check, but not as good as cyclic redundancy check (CRC). • Easier to be implemented in software (compared to CRC).
Checksum • The checksum is calculated at the sender side and the result is put in the checksum field in the header. • The checksum is calculated as follows: • Divide data into 16-bit words and sum them up • Wrap around any overflow • 1’s complement the result • Example: supposed that we have the following 16-bit words:
Checksum 0110011001100000 0101010101010101 1000111100001100 The sum of the first two 16-bit words is: 0110011001100000 0101010101010101 1011101110110101 Adding the third word to the result above gives: 1011101110110101 1000111100001100 0100101011000010
Checksum • How does the receiver use the checksum value to check for errors? • Sum all the 16-bit words, including the checksum value. • The result should be 1111111111111111. • If there is any 0, that means the are bit errors in the segment. • The 16-bit words to be added depend on the protocol. Example: • UDP – Header and data (i.e. the whole segment) • IP – Header only
Cyclic Redundancy Check (CRC) • Link-layer protocols commonly use CRC rather than checksum. • CRC provides stronger protection against errors compared to checksum. • Since link-layer protocol is implemented in hardware, it can rapidly perform the more complex CRC operations. • CRC operates as follows: • Consider a piece of data D that contains d bits. • The sender and receiver need to agree on an r+1 bit pattern, known as a generator, G. • The most significant (leftmost) bit of G must be 1.
Cyclic Redundancy Check (CRC) • The CRC codes, R, are obtained by dividing D (padded with r number of zeros) by G using modulo-2 arithmetic. • The remainder of the division will become R. • R will contain r bits. • R will be attached to the original data D, and then transmitted to the receiver. • At the receiving side, the received bits are divided by G using modulo 2 arithmetic. • If the remainder is non-zero, then an error has occurred. • Otherwise, the data is accepted as being correct.
Cyclic Redundancy Check (CRC) • International standards have been defined for 8-, 12-, 16- and 32-bit generators, G. • Each CRC standard can detect burst error of fewer than r+1 bits. • Under appropriate assumptions, a burst of length greater than r+1 bits can also be detected with probability 1 – 0.5r. • Each CRC standard can also detect any number odd number of bit errors. • Example: Standard 32-bit CRC generator (used in Ethernet). • GCRC-32 = 100000100110000010001110110110111
Principles of Reliable Data Transfer • Reliability is one of the most important problems in networking. • With a reliable channel: • No data bits are corrupted (flipped from 0 to 1 or vice versa). • All data are delivered in order in which they were sent. • Here, we will discuss the problem of reliable data transfer in a general context. • Applies to computer networks in general, not just transport layer.
Building a Reliable Data Transfer Protocol • We will incrementally develop the sender and receiver sides of a reliable data transfer protocol, considering increasingly complex models of the underlying channel. • Reliable data transfer over a channel with bit errors • Reliable data transfer over a lossy channel with bit errors
Reliable Data Transfer over a Channel with Bit Errors • When a packet is transmitted, bits in the packet may be corrupted. • However, we will assume that the packets are received in the order in which they were sent. • The key to recover from bit errors is to perform retransmission. • Upon receiving a message the receiver will perform error detection and send an acknowledgement. • ACK – positive acknowledgement • NAK – negative acknowledgement
Reliable Data Transfer over a Channel with Bit Errors • If a NAK is received, the sender needs to retransmit. • Protocols based on this mechanism are known as ARQ (Automated Repeat reQuest) protocols. • The sender will not send a new piece of data until it is sure that the receiver has correctly received the current packet. • Protocols with this behavior are known as stop-and-wait protocols.
Reliable Data Transfer over a Channel with Bit Errors • So far, we assume that only the data packets can be corrupted. • But in reality, even the ACK and NAK packets can be corrupted. • One solution to this would be to have the sender retransmit the current data packet every time it receives a corrupted ACK or NAK packet. • This solution may introduce another problem: • The receiver may be receiving duplicate packets. • When a packet arrive, is it a new one or a retransmission?
Reliable Data Transfer over a Channel with Bit Errors • A simple solution to this problem would be to put sequence number inside the data packet. • For now, a 1-bit sequence number should be enough. • The receiver would then expect packets with alternating (0 and 1) sequence numbers. • If the receiver receives two packets with the same sequence number back-to-back, then it knows that the second one is a duplicate. • The duplicated packet can be discarded.
Reliable Data Transfer over a Channel with Bit Errors • The use of two types of acknowledgement packets (ACK and NAK) is unnecessary. • The same effect can be accomplished by just using one type of acknowledgement packet. • Only use ACK • Each ACK is given a sequence number • The receiver replies with an ACK that has the same sequence number as the packet receiver. • For packet 0, send ACK 0 • For packet 1, send ACK 1
Reliable Data Transfer over a Channel with Bit Errors • Since there is no longer a NAK, what would the receiver do when a corrupted packet is received? • Send an ACK but with the sequence number of the last correctly received packet. • If the sender receives two ACKs of the same packet, then it knows that the receiver did not correctly receive the packet following the packet being ACKed twice.
Reliable Data Transfer over a Lossy Channel with Bit Errors • In addition to having bit errors, now the underlying channel can also lose packets. • In this condition, there are two issues that need to be addressed by the protocol: • How to detect packet loss • What to do when packet loss occurs • The second issue can already be solved with the techniques discussed so far. • Sequence number, ACK packets, retransmission.
Reliable Data Transfer over a Lossy Channel with Bit Errors • The task of detecting packet loss will be done by the sender. • The sender can “assume” a packet to be lost if no acknowledgement is received from the receiver. • But how long should the sender wait? • In practice, the length of time for the sender to wait can be implemented with a countdown timer. • A timer is set for every packet sent • If the timer times out, retransmit the packet
Reliable Data Transfer over a Lossy Channel with Bit Errors • Even after retransmission, the sender does not actually know what happen. It could be: • The packet is actually lost • The ACK is lost • The ACK was simply overdelayed • In the case where the ACK is lost or overdelayed, the receiver may end up receiving two copies of the same packet. • However, our previous mechanism can already take care of this problem.
