Скачать презентацию MITM 753 Advanced Computer Networks Chapter 3 Transport Скачать презентацию MITM 753 Advanced Computer Networks Chapter 3 Transport

2ba6394c3533461d44f257308a06bb3e.ppt

  • Количество слайдов: 122

MITM 753: Advanced Computer Networks Chapter 3 Transport Layer MITM 753: Advanced Computer Networks Chapter 3 Transport Layer

Introduction l A transport-layer protocol provides for logical communication between processes running on different Introduction l A transport-layer protocol provides for logical communication between processes running on different hosts. l l l 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 l Upon receiving a message from the application layer, the transport layer: l Introduction l Upon receiving a message from the application layer, the transport layer: l l 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: l l l Receive segments from the network layer. Read and process the header. Pass the message to the application layer.

Introduction Introduction

Why Break Message into Smaller Chunks? Why Break Message into Smaller Chunks?

Transport Layer in the Internet l The Internet provides two transport-layer protocols that can Transport Layer in the Internet l The Internet provides two transport-layer protocols that can be used by applications: l l l An application needs to choose either one of the two protocols above. l l UDP (user datagram protocol) TCP (transmission control protocol) 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 l The IP service model is a best-effort delivery Transport Layer in the Internet l The IP service model is a best-effort delivery service. l l l UDP provides two minimal services: l l l It makes its “best effort” to deliver segments to receiving host, but it makes no guarantees. IP is said to be an unreliable service. Process-to-process delivery Error checking UDP is also an unreliable service.

Transport Layer in the Internet l TCP provides the following services: l l l Transport Layer in the Internet l TCP provides the following services: l l l Process-to-process delivery Error checking Reliable data transfer l l Using flow control, sequence number, acknowledgement and timers. Congestion control l l 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 l l A host may run one or more network programs. A Process-to-Process Delivery l l A host may run one or more network programs. A network program may have one or more sockets. l l 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. l Done using the port number.

Process-to-Process Delivery l A port number is a 16 -bit value (ranging from 0 Process-to-Process Delivery l 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. l l l Well-known port numbers are defined in RFC 1700 and RFC 3232. l l l 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 Process-to-Process Delivery

Process-to-Process Delivery l Upon receiving a segment from the network, the transport-layer implementation in Process-to-Process Delivery l Upon receiving a segment from the network, the transport-layer implementation in the operating system will: l l l 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? l l 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 Process-to-Process Delivery

Process-to-Process Delivery l Sometimes a process may spawn another process or create a new Process-to-Process Delivery l Sometimes a process may spawn another process or create a new thread to service each new client connection. l l l 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.

Process-to-Process Delivery Process-to-Process Delivery

Connectionless Transport: UDP l UDP (RFC 768) does as minimum as a transport protocol Connectionless Transport: UDP l UDP (RFC 768) does as minimum as a transport protocol can do. UDP only does: l l 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 l Finer application-level control on what data is sent and when Connectionless Transport: UDP l Finer application-level control on what data is sent and when l l No connection establishment l l No delay in establishing connection before data transfer No connection state l l Segment transmission will not be delayed by the reliability and congestion control mechanism Use less memory and system resources Small packet overhead l Smaller segment size

Connectionless Transport: UDP Connectionless Transport: UDP

Connectionless Transport: UDP l It is still possible for applications using UDP to have Connectionless Transport: UDP l It is still possible for applications using UDP to have reliable data transfer. l l 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. l l Applications send too many packets in the network. Possibly causing severe congestion.

UDP Segment Structure UDP Segment Structure

UDP Segment Structure l Source and destination port numbers: l l Length: l l UDP Segment Structure l Source and destination port numbers: l l Length: l l l Identify sending and receiving process The length of the entire UDP segment Specified in bytes Checksum: l l Contains error detection codes Used for error checking

UDP Checksum l l l The checksum code is generated by the sender. The UDP Checksum l l l 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. l l Because UDP provides no reliable data transfer mechanism. Depending on implementation, UDP might: l l Discard the damaged segment. Pass the damaged segment to the application with a warning.

Error Detection and Correction Techniques l Many transport, network and link layer protocols provide Error Detection and Correction Techniques l Many transport, network and link layer protocols provide a mechanism for detecting errors. l l l 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. l l 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. l But this may require more computation and overhead.

Error Detection and Correction Techniques Error Detection and Correction Techniques

Parity Checks l l l The simplest form of error detection. Adds a single Parity Checks l l l The simplest form of error detection. Adds a single parity bit at the end of the data. Two types: l l Even parity: the parity bit is added such that the total number of 1 s is even. Odd parity: the parity bit is added such that the total number of 1 s is odd.

Parity Checks l Can only detect errors if odd number of bits are corrupted. Parity Checks l Can only detect errors if odd number of bits are corrupted. l l In computer networks, errors are often clustered together in bursts (bursty errors). l l l 1, 3, 5, 7, etc. 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 l l This scheme not only can detect bit errors, but Two-dimensional Parity Scheme l l 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. l A parity value is computed for each row and column.

Two-dimensional Parity Scheme Two-dimensional Parity Scheme

Checksum l l l Sum a sequence of k-bit integers, and use the result Checksum l l l Sum a sequence of k-bit integers, and use the result as error detection bits. Used in TCP, UDP and IPv 4. Requires a relatively low packet overhead. l l l 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 l l The checksum is calculated at the sender side and the result Checksum l l 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: l l 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 011001100000 01010101 1000111100001100 The sum of the first two 16 -bit words is: Checksum 011001100000 01010101 1000111100001100 The sum of the first two 16 -bit words is: 011001100000 01010101 101110110101 Adding the third word to the result above gives: 101110110101 1000111100001100 0100101011000010

Checksum l How does the receiver use the checksum value to check for errors? Checksum l How does the receiver use the checksum value to check for errors? l l Sum all the 16 -bit words, including the checksum value. The result should be 11111111. 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: l l UDP – Header and data (i. e. the whole segment) IP – Header only

Cyclic Redundancy Check (CRC) l Link-layer protocols commonly use CRC rather than checksum. l Cyclic Redundancy Check (CRC) l Link-layer protocols commonly use CRC rather than checksum. l l l 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: l l 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. l The most significant (leftmost) bit of G must be 1.

Cyclic Redundancy Check (CRC) l The CRC codes, R, are obtained by dividing D Cyclic Redundancy Check (CRC) l The CRC codes, R, are obtained by dividing D (padded with r number of zeros) by G using modulo-2 arithmetic. l 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. l l l At the receiving side, the received bits are divided by G using modulo 2 arithmetic. l l If the remainder is non-zero, then an error has occurred. Otherwise, the data is accepted as being correct.

Cyclic Redundancy Check (CRC) Cyclic Redundancy Check (CRC)

Cyclic Redundancy Check (CRC) l International standards have been defined for 8 -, 12, Cyclic Redundancy Check (CRC) l International standards have been defined for 8 -, 12, 16 - and 32 -bit generators, G. l l 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. 5 r. Each CRC standard can also detect any number odd number of bit errors. Example: Standard 32 -bit CRC generator (used in Ethernet). l GCRC-32 = 10000010011000001110110110111

Principles of Reliable Data Transfer l l Reliability is one of the most important Principles of Reliable Data Transfer l l Reliability is one of the most important problems in networking. With a reliable channel: l l l 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. l Applies to computer networks in general, not just transport layer.

Principles of Reliable Data Transfer Principles of Reliable Data Transfer

Building a Reliable Data Transfer Protocol We will incrementally develop the sender and receiver 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 l l l When a Reliable Data Transfer over a Channel with Bit Errors l l l 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. l Upon receiving a message the receiver will perform error detection and send an acknowledgement. l ACK – positive acknowledgement l NAK – negative acknowledgement

Reliable Data Transfer over a Channel with Bit Errors l l l If a Reliable Data Transfer over a Channel with Bit Errors l l l If a NAK is received, the sender needs to retransmit. Protocols based on this mechanism are known as ARQ (Automated Repeat re. Quest) protocols. The sender will not send a new piece of data until it is sure that the receiver has correctly received the current packet. l Protocols with this behavior are known as stopand-wait protocols.

Reliable Data Transfer over a Channel with Bit Errors l l So far, we Reliable Data Transfer over a Channel with Bit Errors l l 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: l l 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 l A simple solution to Reliable Data Transfer over a Channel with Bit Errors l A simple solution to this problem would be to put sequence number inside the data packet. l l l 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. l The duplicated packet can be discarded.

Reliable Data Transfer over a Channel with Bit Errors l l The use of Reliable Data Transfer over a Channel with Bit Errors l l 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. l l l 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. l l For packet 0, send ACK 0 For packet 1, send ACK 1

Reliable Data Transfer over a Channel with Bit Errors l Since there is no Reliable Data Transfer over a Channel with Bit Errors l Since there is no longer a NAK, what would the receiver do when a corrupted packet is received? l l 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 l l In addition Reliable Data Transfer over a Lossy Channel with Bit Errors l l 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: l l l 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. l Sequence number, ACK packets, retransmission.

Reliable Data Transfer over a Lossy Channel with Bit Errors l The task of Reliable Data Transfer over a Lossy Channel with Bit Errors l The task of detecting packet loss will be done by the sender. l l l 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. l l 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 l Even after retransmission, Reliable Data Transfer over a Lossy Channel with Bit Errors l Even after retransmission, the sender does not actually know what happen. It could be: l l 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. l However, our previous mechanism can already take care of this problem.

Reliable Data Transfer over a Lossy Channel with Bit Errors Reliable Data Transfer over a Lossy Channel with Bit Errors

Reliable Data Transfer over a Lossy Channel with Bit Errors Reliable Data Transfer over a Lossy Channel with Bit Errors

Pipelined Reliable Data Transfer Protocol l The reliable data transfer mechanism discussed previously works, Pipelined Reliable Data Transfer Protocol l The reliable data transfer mechanism discussed previously works, but unfortunately it is a stop-and-wait protocol. l l l Only one packet is sent at one time. No new packet will be sent until the current one is confirmed to be received correctly. Stop-and-wait behavior has a very bad performance. l If we have 1000 bytes, to be transmitted over 1 Gbps link, and the RTT is 30 msec, the effective throughput is only 267 kbps!

Pipelined Reliable Data Transfer Protocol l Solution: use pipelining technique. l l Pipelining has Pipelined Reliable Data Transfer Protocol l Solution: use pipelining technique. l l Pipelining has the following consequences for reliable data transfer protocol. l l l Transmit multiple packets in one time and then wait for acknowledgement. The range of sequence number must be increased. The sender and receiver must be able to buffer more than one packet. Two basic approaches for pipelined error recovery: l l Go-Back-N Selective repeat

Pipelined Reliable Data Transfer Protocol Pipelined Reliable Data Transfer Protocol

Pipelined Reliable Data Transfer Protocol Pipelined Reliable Data Transfer Protocol

Go-Back-N (GBN) l The sender is allowed to transmit multiple packets without waiting for Go-Back-N (GBN) l The sender is allowed to transmit multiple packets without waiting for acknowledgement, but constrained to a maximum allowable number, N. l l l N is referred to as the window size. Packets will be numbered from 0 to N-1. In practice, N is limited by the number of bits allocated for sequence number in the header. l If k bits are allocated, then the sequence number range would be [0, 2 k-1].

Go-Back-N (GBN) l This is how the sender’s view the sequence number in GBN: Go-Back-N (GBN) l This is how the sender’s view the sequence number in GBN:

Go-Back-N (GBN) l The sender keeps track of two variables: l l l Base Go-Back-N (GBN) l The sender keeps track of two variables: l l l Base – the sequence number of the oldest unacknowledged packet. Nextseqnum – the smallest unused sequence number. As the protocol operates, the window slides forward over the sequence number space. l Due to this behavior, GBN is also knows as the sliding-window protocol.

Go-Back-N (GBN) l The GBN sender needs to respond to three events: l Request Go-Back-N (GBN) l The GBN sender needs to respond to three events: l Request from upper layer to send data l l Check whether the window is full or not. If it is full, refuse to accept the data. If it is not full, prepare the packet to be sent. Receive an ACK from the receiver l l When an ACK is received for a particular sequence number, it is assumed all the packets up to the ACKed sequence number has been received correctly. This is called a cumulative acknowledgement.

Go-Back-N (GBN) l When a timeout occurs l l The GBN receiver needs to Go-Back-N (GBN) l When a timeout occurs l l The GBN receiver needs to do the following: l l l Retransmit all packets that have been sent but not yet acknowledged. If a packet with sequence number n is received correctly and in order, send an ACK for packet n. Otherwise, discard the packet and send an ACK for the last correctly received, in-order packet. In GBN, the receiver will discard all out-oforder packets.

Go-Back-N (GBN) l Although it seems wasteful to discard correctly received, but out-of-order packets, Go-Back-N (GBN) l Although it seems wasteful to discard correctly received, but out-of-order packets, this simplifies implementation. l l There is no need to buffer out-of-order packets. Easier to implement. Use less memory. Of course, the disadvantage of doing this is that packets may need to be retransmitted unnecessarily. l Use up more bandwidth that required.

Go-Back-N (GBN) Go-Back-N (GBN)

Selective Repeat (SR) l GBN may suffer from performance problem. l l SR protocol Selective Repeat (SR) l GBN may suffer from performance problem. l l SR protocol avoids unnecessary retransmission by only retransmitting packets that are received in error (lost or corrupted). l l A single packet loss may cause many packets to be retransmitted unnecessarily. Therefore, each packet should be acknowledged individually (no cumulative acknowledgement). A window of size N is still used to limit the number of unacknowledged packets.

Selective Repeat (SR) l However, some of the packets in the window may have Selective Repeat (SR) l However, some of the packets in the window may have already been ACKed.

Selective Repeat (SR) l Each packet sent by the sender will have a timer Selective Repeat (SR) l Each packet sent by the sender will have a timer associated with it. l l When the timer times out, the packet is assumed to be lost and is retransmitted. The receiver will acknowledge a correctly received packet regardless of whether it is in order or not. l l Out-of-order packets are buffered until missing packets are received. Any duplicates must also be acknowledged.

Selective Repeat (SR) l The windows size, N, in SR is limited to half Selective Repeat (SR) l The windows size, N, in SR is limited to half the sequence number space. l l N <= 2 k (k = number of bits allocated for sequence number) Although SR seems to be better in terms of performance, it has several disadvantages: l l More complicated implementation. l Sender needs to be able to transmit out-of-sequence. l Receiver must be able to insert packets into the buffer in the proper sequence. Smaller window size compared to GBN for the same number of sequence number bits.

Selective Repeat (SR) Selective Repeat (SR)

Connection-oriented Transport: TCP l l Now that we have covered the principles of reliable Connection-oriented Transport: TCP l l Now that we have covered the principles of reliable data transfer, we are ready to discuss about TCP uses many of the mechanisms that we have discussed before: l l Error detection, retransmission, cumulative acknowledgement, sequence numbers and timers. TCP is defined in several RFCs: l RFC 793, RFC 1122, RFC 1323, RFC 2018 and RFC 2581.

TCP Connection l l TCP is said to be connection-oriented because before data transfer TCP Connection l l TCP is said to be connection-oriented because before data transfer a “handshake” must be performed. TCP connection does not involve intermediate network elements. l l The connection is strictly between the two end systems. Characteristics of TCP connection: l l Full-duplex Point-to-point

TCP Connection l The connection establishment procedure is often referred to as a three-way TCP Connection l The connection establishment procedure is often referred to as a three-way handshake. l l The client sends a special TCP segment. The server responds with a second special TCP segment. The client responds again with a third special TCP segment. This third segment may include application-layer data. Once a TCP connection is established, the two applications can start sending data.

TCP Connection l The TCP connection is required to prepare both sides for data TCP Connection l The TCP connection is required to prepare both sides for data transfer: l l Initialize TCP state variables Allocate send and receive buffers When an application sends data through the socket, the data will go to TCP send buffer. From time to time, TCP will take an amount of data from the send buffer and encapsulates it with a TCP header. l This TCP segment is then passed to the network layer.

TCP Connection TCP Connection

TCP Connection l l Each side of the connection has its own send and TCP Connection l l Each side of the connection has its own send and receive buffer. The amount of data that can be taken at one time is limited by the maximum segment size (MSS). l l l Depends on the TCP implementation (determined by the OS). Can be configured by the application. Common values are 1460 bytes, 536 bytes and 512 bytes.

TCP Segment Structure TCP Segment Structure

TCP Segment Structure l l Source and destination port numbers are used for process-to-process TCP Segment Structure l l Source and destination port numbers are used for process-to-process delivery. The checksum field is used for error detection. The 32 -bit sequence number and acknowledgement number fields are used to implement reliable data transfer. The 4 -bit length field specifies the length of the TCP header in 32 -bit words. l The header can be of variable length due to the TCP option field.

TCP Segment Structure l The 16 -bit receive window field indicates the number of TCP Segment Structure l The 16 -bit receive window field indicates the number of bytes that the receiver is willing to accept. l l It is used for flow control The option field is optional and can be of variable length. Among others, it is used for: l l l Sender and receiver to negotiate MSS Window scaling factor Time-stamping

TCP Segment Structure l The flag field contains 6 bits: l l ACK: Used TCP Segment Structure l The flag field contains 6 bits: l l ACK: Used to indicate whether the value in the acknowledgement field is valid or not. RST, SYN and FIN: Used for connection setup and teardown. PSH: When this bit is set, it indicates that the receiver should pass the data to the upper layer immediately. URG: Used to indicate that there is data in this segment that the upper-layer entity has marked as “urgent”. The location of the last byte of this urgent data is indicated by the 16 -bit urgent data pointer field.

Sequence Numbers and Acknowledgements Numbers l l l TCP views data as a stream Sequence Numbers and Acknowledgements Numbers l l l TCP views data as a stream of bytes. The value that TCP puts in the sequence number field is the byte-stream number of the first byte in the segment. For example, suppose that the data stream consists of a file consisting of 500, 000 bytes. l l l Assume that the MSS is 1000 bytes. TCP will then construct 500 segments out of this data stream. The first segment gets assigned sequence number 0, the second segment gets assigned sequence number 1000, the third segment gets assigned sequence number 2000, and so on.

Sequence Numbers and Acknowledgements Numbers Sequence Numbers and Acknowledgements Numbers

Sequence Numbers and Acknowledgements Numbers l l Assuming a communication between A and B, Sequence Numbers and Acknowledgements Numbers l l Assuming a communication between A and B, the acknowledgement number that host A puts in its segment is the sequence number of the next byte that host A is expecting from host B. For example, suppose A has received all bytes numbered 0 to 535 from B and that A is about to send a segment to B. l l A is currently waiting for byte 536 from B. Therefore A will put 536 in the acknowledgement number field.

Sequence Numbers and Acknowledgements Numbers l As another example, suppose that A has received Sequence Numbers and Acknowledgements Numbers l As another example, suppose that A has received one segment from host B containing bytes 0 through 535 and another segment containing bytes 900 through 1000. l l l For some reason, bytes 536 through 899 have not been received. In this case, A’s next segment to B will contain 536 in the acknowledgement number field. TCP only acknowledges bytes up to the first missing byte in the stream (cumulative acknowledgements)

Sequence Numbers and Acknowledgements Numbers l In the previous example, A is receiving data Sequence Numbers and Acknowledgements Numbers l In the previous example, A is receiving data out of order. l l l The TCP RFCs does not impose any rules on what to do in this case. It is up to the programmers who are implementing the TCP to decide what to do. Basically there are only 2 choices: l l Discard out-of-order bytes. Keeps the out-of-order bytes and waits for the missing bytes.

Sequence Numbers and Acknowledgements Numbers l The second choice is more efficient in terms Sequence Numbers and Acknowledgements Numbers l The second choice is more efficient in terms of network bandwidth. l l This is the approach taken in practice. So far, we have assumed that the initial sequence number is zero. l l In practice, both sides of TCP randomly choose an initial sequence number. Done to avoid confusion should somehow there are segments from an earlier, already-terminated connection still present in the network.

Round-Trip Time Estimation and Timeout l l TCP uses timeout/retransmit mechanism to recover from Round-Trip Time Estimation and Timeout l l TCP uses timeout/retransmit mechanism to recover from lost segments. How do we decide the length of the timeout interval? l l l Clearly, it should be larger than RTT. But it cannot be too large that it causes significant delays before a lost packet is retransmitted. In general, TCP decides the timeout interval by sampling the RTT of each segment sent and estimating the RTT of the next segment.

Estimating the Round-Trip Time l The sample RTT (Sample. RTT) for a segment is Estimating the Round-Trip Time l The sample RTT (Sample. RTT) for a segment is the amount of time from when a segment is sent until an acknowledgment from the segment is received. l l l This value is sampled once every RTT. One segment will be selected to be sampled (this must not be a retransmitted segment). The value of Sample. RTT will fluctuate from segment to segment due to the congestion at routers and varying load on the end systems.

Estimating the Round-Trip Time l l TCP maintains an average, called the Estimated. RTT, Estimating the Round-Trip Time l l TCP maintains an average, called the Estimated. RTT, of the Sample. RTT values. Upon receiving an acknowledgement and obtaining a new Sample. RTT, TCP updates the Estimated. RTT using the following formula: l l Estimated. RTT = (1 – α)*Estimated. RTT + α*Sample. RTT Recommended value for α: α = 0. 125.

Estimating the Round-Trip Time Estimating the Round-Trip Time

Estimating the Round-Trip Time l TCP also measures the variation of RTT (Dev. RTT). Estimating the Round-Trip Time l TCP also measures the variation of RTT (Dev. RTT). l l l Dev. RTT = (1 – β)*Dev. RTT + β *| Sample. RTT – Estimated. RTT | Recommended value for β: β = 0. 25 Dev. RTT measures the difference between Sample. RTT and Estimated. RTT. l Dev. RTT is small if Sample. RTT values have little fluctuation (and vice versa).

Setting and Managing the Retransmission Timeout Interval l The timeout is set to be Setting and Managing the Retransmission Timeout Interval l The timeout is set to be equal to the Estimated. RTT plus some margin. l l l This margin should be large if there is a lot of fluctuation in the Sample. RTT values. It should be small when there is little fluctuation. The timeout interval is set using the following formula: l Timeout. Interval = Estimated. RTT + 4*Dev. RTT

Reliable Data Transfer l TCP creates a reliable data transfer service on top of Reliable Data Transfer l TCP creates a reliable data transfer service on top of IP’s unreliable best effort service. l l Our discussion here assumes: l l l Data stream in the TCP receive buffer is uncorrupted, without duplication and in sequence. A single retransmission timer is used. Data is being sent in only one direction (A to B) and that Host A is sending a large file. There are three major events that need to be handled by a TCP sender: l l l Data is received from the application above Timer timeout An ACK is received

Reliable Data Transfer Reliable Data Transfer

Reliable Data Transfer l Whenever TCP retransmits, the timeout interval will be set to Reliable Data Transfer l Whenever TCP retransmits, the timeout interval will be set to twice the previous value. l l The timeout derived from Sample. RTT and Estimated. RTT will not be used. If the same segment times out again, the next timeout interval will be doubled again. Provide a limited form of congestion control. However, for new data received from the application above, the Timeout. Interval value will be used.

Reliable Data Transfer l l When a segment is lost, a long timeout may Reliable Data Transfer l l When a segment is lost, a long timeout may delay retransmission of the lost segment. Retransmission can be done faster by having the receiver sends a duplicate ACK. l l l Happen when receiver receives data out of order The receiver reacknowledges the last in-order bytes of data that it has received If a sender receives 3 duplicate ACKs for the same data, it will assume that the segment following the ACKed segment has been lost. l l The sender will then retransmit This is called a fast retransmit

Reliable Data Transfer Reliable Data Transfer

Reliable Data Transfer l Is TCP a Go-Back-N or a Selective Repeat protocol? l Reliable Data Transfer l Is TCP a Go-Back-N or a Selective Repeat protocol? l l l In some way, TCP looks like GBN: l TCP performs cumulative acknowledgement l Out-of-order segments are not ACKed In some other way, TCP looks like SR: l Many TCP implementations will buffer correctly out-of-order segments l Only lost segments are retransmitted Therefore, TCP is best categorized as a hybrid GBN and SR protocol.

Flow Control l l Bytes that are correctly received and in sequence by the Flow Control l l Bytes that are correctly received and in sequence by the receiving TCP will be put in a receive buffer. The corresponding application process will then read from this buffer. l l The application decides when to read the data. Data is not necessarily read at the instant it arrives. It is possible that if the application is slow in reading the data, the receive buffer may overflow. TCP provides a flow control service to prevent the sender from overflowing the receiver’s buffer.

Flow Control l The TCP sender maintains a variable called the receive window (Rcv. Flow Control l The TCP sender maintains a variable called the receive window (Rcv. Window). l l This variable tells how much free space is available at the receiver. Rcv. Window is actually calculated at the receiver. l l l Last. Byte. Read: The last byte number read by the receiving application. Lasy. Byte. Rcvd: The last byte number arrived from the network and put in the receive buffer. Rcv. Window = Rcv. Buffer – [Last. Byte. Rcvd – Last. Byte. Read]

Flow Control Flow Control

Flow Control l Consider a communication between host A and B (A sends a Flow Control l Consider a communication between host A and B (A sends a file to B). l l B tells A the current value of its Rcv. Window by placing it in the receive window field of every segment it sends to A. Host A keeps track of two variables: l l Last. Byte. Read and Last. Byte. Acked To ensure that A does not overflow B, A must make sure that: l Last. Byte. Sent – Last. Byte. Acked <= Rcv. Window

TCP Connection Management l l Here, we will look in more detail on how TCP Connection Management l l Here, we will look in more detail on how a TCP connection is established and terminated. If a client wants to set up a connection to a server, the client-side TCP first send a connection request segment (called a SYN segment) to the server-side TCP. l l l Contains no application-layer data. SYN flag bit is set to 1. The client chooses an initial sequence number (client_isn) and puts this number in the sequence number field.

TCP Connection Management l Upon receiving the TCP SYN segment, the server allocates TCP TCP Connection Management l Upon receiving the TCP SYN segment, the server allocates TCP buffers and variables to the connection and sends a connection-granted segment (called a SYNACK segment) to the client. l l Contains no application-layer data. SYN flag bit is set to 1. The acknowledgement field is set to client_isn+1. The server chooses its own initial sequence number (server_isn) and puts this number in the sequence number field.

TCP Connection Management l l Upon receiving the TCP SYNACK segment from the server, TCP Connection Management l l Upon receiving the TCP SYNACK segment from the server, the client also allocates buffers and variables to the connection. The client then sends a segment to the server to acknowledge the server’s connectiongranted segment. l l May contain application-layer data. SYN flag bit is set to 0. The acknowledgement field is set to server_isn+1. The sequence number field is set to client_isn+1.

TCP Connection Management TCP Connection Management

TCP Connection Management l l This procedure is called a three-way handshake. After this, TCP Connection Management l l This procedure is called a three-way handshake. After this, the two hosts can start sending segments containing data to each other. l l In each of these future segments, the SYN bit will be set to 0. The TCP connection can be terminated by either host. l When the connection ends, the resources (buffers and connection variables) at both hosts are de-allocated.

TCP Connection Management l Suppose that the client wants to close the connection. l TCP Connection Management l Suppose that the client wants to close the connection. l l l It will send a special TCP segment to the server with its FIN bit set to 1. When the server receives the segment, it will send an ACK segment in return. The server then sends its own shutdown segment. l l This segment has FIN bit set to 1. The client will in turn send an ACK.

TCP Connection Management TCP Connection Management

TCP Connection Management l The connection is only really closed after a certain time TCP Connection Management l The connection is only really closed after a certain time wait interval: l l l Allows the TCP client to retransmit the final ACK in case it is lost. The time spent in this state is implementation dependent. Typical values are 30 seconds, 1 minute or 2 minutes.

Principles of Congestion Control l l Congestion control is also another important problem in Principles of Congestion Control l l Congestion control is also another important problem in networking. The retransmission mechanism discussed earlier can treat the symptom of congestion but not treat the cause of congestion. In general, congestion control is performed by slowing down the senders when congestion occurs. Here, we will discuss the problem of congestion control in general. l l l Why congestion is a bad thing? How do we know that there is congestion in the network? What can we do to avoid or react to network congestion?

The Causes and Costs of Congestion l Congestion is caused by high packet arrival The Causes and Costs of Congestion l Congestion is caused by high packet arrival rate. l l The sender must perform retransmission in order to compensate for dropped packets due to buffer overflow. If premature timeout occurs, packets will be unnecessarily retransmitted. l l Causes high queuing delay. Packets may also be dropped. Waste router and link resources. When a packet is dropped along a path, the transmission capacity that has been used to transmit the packet up to the point where it is dropped ends up being wasted.

Approaches to Congestion Control l In general, when the network is congested, the sending Approaches to Congestion Control l In general, when the network is congested, the sending host should lower its data rate. l l There are two broad approaches toward congestion control: l l l But how can the sending host know whether the network is congested or not? Network-assisted congestion control End-to-end congestion control Network-assisted congestion control: l Network-layer components (routers) provide explicit feedback to the sender regarding the congestion state in the network.

Approaches to Congestion Control l Feedback can be done in one of two ways: Approaches to Congestion Control l Feedback can be done in one of two ways: l l l Router sends a choke packet to the sender to tell that it is congested. Router marks a field in a packet flowing from sender to receiver. The receiver then notifies the sender of the congestion indication. The information sent by the router to the sender can take various forms: l l A single bit indicating congestion. Tell the exact transmission rate that the router can support at that time.

Approaches to Congestion Control l This approach is used by a number of networks: Approaches to Congestion Control l This approach is used by a number of networks: l l IBM SNA DECnet ATM ABR (available bit rate) congestion control. End-to-end congestion control: l l l Network layer provides no explicit support for congestion control. The presence of congestion must be implied based on network behavior such as packet loss and delays. Used by the Internet.

TCP Congestion Control l l TCP uses end-to-end congestion control. TCP limits the rate TCP Congestion Control l l TCP uses end-to-end congestion control. TCP limits the rate at which each sender sends traffic into its connection as a function of perceived network congestion. l l l If the sender perceived there is no or little congestion on the path, the send rate is increased. And vice versa. To perform this, we need to solve three problems: l l l How does the sender know there is congestion in the path? How does the sender limit the send rate? What algorithm should be used to change the send rate?

TCP Congestion Control l During congestion, one or more router buffers along the path TCP Congestion Control l During congestion, one or more router buffers along the path overflows. l l l Datagrams will be dropped. Datagrams that are not dropped may be overly delayed. Therefore, congestion can be implied by a “loss event”. l l Timeout The receipt of three duplicate ACKs

TCP Congestion Control l l To limit the data rate, TCP keeps track of TCP Congestion Control l l To limit the data rate, TCP keeps track of a variable called congestion window (Cong. Win). The congestion window impose a constraint on the rate at which a TCP sender can send traffic into the network. l l l Last. Byte. Sent – Last. Byte. Acked <= min{Cong. Win, Rcv. Window} Assuming Rcv. Window is much larger than Cong. Win, Sender’s rate = Cong. Win/RTT bytes/sec Adjusting the Cong. Win value allows the sender to adjust the rate at which data is sent.

TCP Congestion Control Algorithm l TCP congestion control has evolved over the years (and TCP Congestion Control Algorithm l TCP congestion control has evolved over the years (and will continue to evolve). l l l There are several versions of TCP congestion control algorithms: l l What was good for the Internet several years ago may not be good for the Internet now. Due to the types of application that run on the Internet. TCP Tahoe algorithm TCP Reno algorithm (we will choose this for discussion) TCP Vegas algorithm For each of these versions there may be variants in terms of implementation.

TCP Congestion Control Algorithm l When a TCP connection begins, Cong. Win = 1 TCP Congestion Control Algorithm l When a TCP connection begins, Cong. Win = 1 MSS. l l l For each acknowledgement received before a loss event, the Cong. Win value is doubled. l l Initial data rate = MSS/RTT bytes/second Example: If MSS = 500 bytes and RTT = 200 msec, data rate = 20 kbps. 1 MSS 2 MSS 4 MSS 8 MSS 16 MSS, etc. The Cong. Win value increases exponentially. This procedure continues until a loss event occurs. This phase is called the slow start (SS) phase.

TCP Congestion Control Algorithm l What happen when a loss event occurs? l l TCP Congestion Control Algorithm l What happen when a loss event occurs? l l l If the sender receives three duplicate ACKs: l Congestion window is cut in half. l Increase linearly (no longer exponentially). If timeout occurs: l Enter the slow start phase. l Congestion window grows exponentially until it reaches half of the size before the timeout occurred. l Then it will increase linearly. This linear increase phase is referred to as the congestion avoidance (CA) phase.

TCP Congestion Control Algorithm l l To manage the complexity of having a dynamic TCP Congestion Control Algorithm l l To manage the complexity of having a dynamic congestion window size, TCP uses a variable called Threshold is initially set to a very high value. l l l 65 Kbytes in practice. Whenever a loss event occurs, the Threshold value is set to ½ the size of the current Cong. Win. Threshold separates the SS and CA phases. l l If Cong. Win < Threshold, we are in SS phase. If Cong. Win > Threshold, we are in CA phase.

TCP Congestion Control Algorithm TCP Congestion Control Algorithm

TCP Congestion Control Algorithm l In general, TCP: l l Additively increase its rate TCP Congestion Control Algorithm l In general, TCP: l l Additively increase its rate when the path is congestion-free. Multiplicatively decreases its rate when the path is congested. For this reason, TCP is referred to as an additiveincrease, multiplicative-decrease (AIMD) algorithm. Say that W is the congestion window size before a loss event occurs: l Average throughput =

TCP Congestion Control Algorithm TCP Congestion Control Algorithm

Secure Transport Layer Protocols l Security in transport layer is provided by: l l Secure Transport Layer Protocols l Security in transport layer is provided by: l l l TLS is the successor to SSL. l l SSL (Secure Sockets Layer) TLS (Transport Layer Security) SSL got up to version 3. 0 The next one is TLS 1. 0 (sometimes also called SSL 3. 1) The latest version is TLS 1. 2 Provides encryption and authentication to application data.