Transport Layer, PDF

Chapter 3: Transport Layer 3.1 Introduction and Transport-Layer Services A transport-layer protocol provides for logical communication (as if the hosts running the processes were directly connected) between application processes running on different hosts. Application processes use the logical comm...

Chapter 3: Transport Layer 3.1 Introduction and Transport-Layer Services A transport-layer protocol provides for logical communication (as if the hosts running the processes were directly connected) between application processes running on different hosts. Application processes use the logical communication provided by the transport layer to send messages to each other, free from the worry of the details of the physical infrastructure used. Transport-layer protocols are implemented in the end systems but not in network routers. On the sending side, the transport layer converts the application messages into transport-layer packets, known as transport-layer segments. This is done by breaking them into smaller chunks and adding a transport-layer header to each chunk. The transport-layer then passes the segment to the network-layer packet at the sending end-system. On the receiving side, the network layer extracts the transport-layer segment from the datagram and passes the segment up to the transport-layer which then processes the received segment, making the data in the segment available to the received application. 3.1.1 Relationship between Transport and Network Layers A transport-layer protocol provides logical communication between processes running on different hosts. Whereas a network-layer protocol provides a logical communication between hosts. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 1 3.1.2 Overview of the Transport Layer in the Internet A TCP/IP network (such as the Internet) makes two distinct transport-layer protocols available to the application layer:  UDP [User Datagram Protocol], which provides an unreliable, connectionless service to the invoking application.  TCP [Transmission Control Protocol] which provides a reliable, connection-oriented service to the invoking application. We need to spend a few words on the network-layer protocol: the Internet network-layer protocol is the IP (Internet Protocol). It provides a logical communication between hosts. The IP service model is a best-effort delivery service: it makes the best effort to deliver segments between hosts, but it doesn’t provide guarantees:  it doesn't guarantee segment delivery  it doesn't guarantee orderly delivery of segments  it doesn't guarantee the integrity of the data in the segments Thus IP is said to be an unreliable service. Every host has at least one network-layer address a so-called IP address. UDP and TCP extend IP's delivery service between 2 end systems to a delivery service between two processes running on the end systems. Extend host-to-host delivery to process-to-process delivery is called transport-layer multiplexing and demultiplexing. UDP provides process-to-process delivery and error checking services. Therefore it is an unreliable service. TCP provides reliable data transfer using flow control, sequence numbers, acknowledgements and timers. TCP thus converts IP's unreliable service between end systems into a reliable data transport service between processes. TCP also provides congestion control, a service not really provided to the invoking application as it is to the Internet as a whole: it prevents any TCP connection from swamping the links and routers between communication hosts with an excessive amount of traffic giving each connection traversing a congested link an equal share of the bandwidth. 3.2 Multiplexing and Demultiplexing Here we'll cover multiplexing & demultiplexing in the context of the Internet but a multiplexing/demultiplexing service is needed for all computer networks. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 2   The job of delivering the data in a transport-layer segment to the correct socket is called demultiplexing.  The job of gathering data chunks at the source host from different sockets, encapsulating each data chunk with header information (which will be used in demultiplexing) to create segments and passing the segments to the networks layer is called multiplexing. Therefore sockets need to have unique identifiers and each segment needs to have special fields that indicate the socket to which the segment is delivered. These fields are the source port number field and the destination port number field. Each port number is a 16-bit number ranging from 0 to 65535. Port numbers ranging from 0 to 1023 are called well-known port numbers and are restricted, reserved for us by well-known application protocols such as HTTP (80) and FTP (21). Designing an application, we should assign it a port number. Connectionless Multiplexing and Demultiplexing A UDP socket is fully identified by the two-tuple: (destination IP address, destination port number) therefore if two UDP segments have different source IP address and/or source port numbers but have the same destination IP address and destination port number, than the two segments will be directed to the same destination process via the same destination socket. The source port number serves as part of the return address. Connection-oriented Multiplexing and Demultiplexing A TCP socket is identified by the four-tuple: (source IP address, source port number, destination IP address, destination port number) When a TCP segment arrives from the network to a host, the host uses all four values to demultiplex the segment to the appropriate socket. Two arriving TCP segments with different source IP addresses or source port numbers will (with the Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 3 exception of a TCP carrying the original connection establishment request) be directed to two different sockets. Routine:  The TCP server application always has a welcoming socket that waits for connection establishment requests from TCP clients on port number X  The TCP client creates a socket and sends a connection establishment request (a TCP segment including destination port, source port number and a special connection- establishment bit set in the TCP header)  The server OS receives the incoming connection-request segment on port X , it locates the server process that is waiting to accept a connection on port number X , then creates a new socket which will be identified by (source port number in the segment (cleint), IP address of source host (client), the destination port number in the segment (its own), its own IP address)  With the TCP connection in place, client and server can now send data to each other The server may support many simultaneous TCP connection sockets, with each socket attached to a process and each socket identified by its own four-tuple. When a TCP segment arrives at the host, all the fours fields are used to demultiplex the segment to the appropriate socket. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 4 And there may be a threaded server that has multiple sockets for one process. Port Scanning Can be used both by attackers and system administrator to find vulnerabilities in the target or to know network applications are running in the network. The most used port scanner is nmap free and open source. For TCP it scans port looking for port accepting connections, for UDP looking for UDP ports that respond to transmitted UDP segments. It then returns a list of open, closed or unreachable ports. A host running nmap can attempt to scan any target anywhere in the Internet. Web Servers and TCP In a web server, all segments have destination port 80 and both the initial connection- establishment segments and the segments carrying HTTP request messages will have destination port 80, the server will distinguish clients using the source IP addresses and port numbers. Moreover in today's high-performing Web, servers often use only one process and create a new thread with a new connection soket for each new client connection. If using persistent HTTP, client and server will exchange messages via the same server socket. If using non-persistent HTTP, a new TCP connection is created and closed for every request/response and hence a new socket is created and closed for every request/response. 3.3 Connectionless Transport: UDP UDP does multiplexing/demultiplexing, light error checking, nothing more. If the developer chooses UDP, the application is almost directly talking with IP. Note that with UDP there is no handshaking between sending and receiving transport-layer entities before sending a segment. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 5 For this reason UDP is said to be connectionless. DNS is an example of an application layer protocol that typically uses UDP: there is no handshaking and when a client doesn't receive a reply either it tries sending the query to another name server or it informs the invoking application that it can't get a reply. Why should a developer choose UDP?  Finer application-level control over what data is sent and when: as soon as the application passes data to UDP, UDP will package the data inside a segment and immediately pass it to the network layer. TCP's congestion control can delay the sending of the segment and will try sending the packet until this is received. In real time applications the sending rate is important, so we can trade off some data loss for some sending rate.  No connection establishment UDP just send data without any formal preliminaries without introducing any delay, probably the reason why DNS runs over UDP.  No connection state: because a UDP application doesn't need to keep track of the users or to keep connections alive, it can typically support many more active clients than a TCP application.  Small packet header overhead TCP has 20 bytes of header overhead in every segment versus the 8 of UDP. It is possible for an application developer to have reliable data transfer when using UDP. This can be done if reliability is built into the application itself (eg adding acknowledgement and retransmission mechanisms) but it is a nontrivial task and may keep the developer busy for a long time. 3.3.1 UDP Segment Structure Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 6 The UDP header has only four fields, each consisting of two bytes:  source port number  destination port number  checksum (used for error detection.)  length (which specifies the number of bytes in the UDP segment, header + data)  This length field is needed since the size of the data field may differ from one UDP segment to the next. 3.3.2 UDP Checksum It provides for error detection, to determine whether the bits in the segment have been altered as it moves from source to destination. At the send side, UDP performs the 1s complement of the sum of all the 16-bit (max 64) words in the segment, with any overflow encountered during the sum being wrapped around. This result is put in the checksum field of the UDP segment header. UDP implements error detection according to the end-end principle: certain functionality (error detection in this case) must be implemented on an end-end basis: "functions placed at the lower levels may be redundant or of little value when compared to the cost of providing them at the higher level". Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 7 3.4 Principles of Reliable Data Transfer It is the responsibility of a reliable data transfer protocol to implement reliable data service: no transferred data bits are corrupted or lost and all are delivered in the order in which they were sent. We will consider the following actions:  The sending side of the data transfer protocol will be invoked from above by a call to rdt_send()  On the receiving side rdt_rcv() will be called when a packet arrives while deliver_data() will be called when the rdt protocol wants to deliver data to the upper layer. We use the term packet rather than segment because the concepts explained here applies to computer networks in general. We will only consider the case of unidirectional data transfer that is data transfer from the sending to the receiving side. The case of reliable bidirectional (full-duplex) data transfer is not more difficult but more tedious to explain. Nonetheless sending and receiving side will need to transmit packets in both directions. 3.4.1 Building a Reliable Data Transfer Protocol 3.4.2 Pipelined Reliable Data Transfer Protocols A more realistic model of the underlying channel is one in which bits in a packet may be corrupted. Such bit errors typically occur in the physical components of a network as a packet is transmitted, propagates, or is buffered. This protocol uses both positive acknowledgments (“OK”) and negative acknowledgments (“Please repeat that.”). These control messages allow the receiver to let the sender know what has been received correctly, and what has been received in error and thus requires repeating. In a computer network setting, reliable data transfer protocols based on such retransmission are known as ARQ (Automatic Repeat reQuest) protocols. We’ll continue to assume for the moment that all transmitted packets are received (although their bits may be corrupted) in the order in which they were sent. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 8 The following figure shows the FSM representation of rdt2.0, a data transfer protocol employing error detection, positive acknowledgments, and negative acknowledgments. The send side of rdt2.0 has two states. In the leftmost state, the send-side protocol is waiting for data to be passed down from the upper layer. When the rdt_send(data) event occurs, the sender will create a packet (sndpkt) containing the data to be sent, along with a packet checksum and then send the packet via the udt_send(sndpkt) operation. In the rightmost state, the sender protocol is waiting for an ACK or a NAK packet from the receiver. If an ACK packet is received (the notation rdt_rcv(rcvpkt) && isACK(rcvpkt) in the above figure, the sender knows that the most recently transmitted packet has been received correctly and thus the protocol returns to the state of waiting for data from the upper layer. If a NAK is received, the protocol retransmits the last packet and waits for an ACK or NAK to be returned by the receiver in response to the retransmitted data packet. It is important to note that when the sender is in the wait-for-ACK- or-NAK state, it cannot get more data from the upper layer; that is, the rdt_send() event can’t occur; that will happen only after the sender receives an ACK and leaves this state. Thus, the sender will not send a new piece of data until it is sure that the receiver has correctly received the current packet. Because of this behavior, protocols such as rdt2.0 are known as stop-and- wait protocols. Protocol rdt2.0 may look as if it works but, we haven’t accounted for the possibility that the ACK or NAK packet could be corrupted! Minimally, we will need to add checksum bits to ACK/NAK packets in order to detect such errors. The more difficult question is how the protocol should recover from errors in ACK or NAK packets. The difficulty here is that if an ACK or NAK is Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 9 corrupted, the sender has no way of knowing whether or not the receiver has correctly received the last piece of transmitted data. A simple solution to this new problem is to add a new field to the data packet and have the sender number its data packets by putting a sequence number into this field. the sequence number of the received packet has the same sequence number as the most recently received packet or a new packet. Since we are currently assuming a channel that does not lose packets, ACK and NAK packets do not themselves need to indicate the sequence number of the packet they are acknowledging. rdt2.1, the fixed version of rdt2.0. The rdt2.1 sender and receiver FSMs each now have twice as many states as before. This is because the protocol state must now reflect whether the packet currently being sent (by the sender) or expected (at the receiver) should have a sequence number of 0 or 1. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 10 Protocol rdt2.1 uses both positive and negative acknowledgments from the receiver to the sender. When an out-of-order packet is received, the receiver sends a positive acknowledgment for the packet it has received. When a corrupted packet is received, the receiver sends a negative acknowledgment. We can accomplish the same effect as a NAK if, instead of sending a NAK, we send an ACK for the last correctly received packet. A sender that receives two ACKs for the same packet (that is, receives duplicate ACKs) knows that the receiver did not correctly receive the packet following the packet that is being ACKed twice. The NAK-free reliable data transfer protocol for a channel with bit errors is rdt2.2, shown in the following figure. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 11 Suppose now that in addition to corrupting bits, the underlying channel can lose packets as well. There are many possible approaches toward dealing with packet loss. Here, the burden of detecting and recovering from lost packets is put on the sender. Suppose that the sender transmits a data packet and either that packet, or the receiver’s ACK of that packet, gets lost. In either case, no reply is forthcoming at the sender from the receiver. If the sender is willing to wait long enough so that it is certain that a packet has been lost, it can simply retransmit the data packet. But how long must the sender wait? The sender must clearly wait at least as long as a round-trip delay between the sender and receiver plus whatever amount of time is needed to process a packet at the receiver. If an ACK is not received within this time, the packet is retransmitted. if a packet experiences a particularly large delay, the sender may retransmit the packet even though neither the data packet nor its ACK have been lost. This introduces the possibility of duplicate data packets in the sender-to-receiver channel. The rdt3.0, a protocol that reliably transfers data over a channel that can corrupt or lose packets. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 12 Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 13 In today's high-speed networks stop-and-wait protocols are simply not tolerable: we cannot send one packet and wait for the ACK and then send the second one, it is inefficient as we can see computing the utilization of the channel: The solution is simple: rather than operate in a stop-and-wait manner, the sender is allowed to send multiple packets without waiting for acknowledgements. Since the many in-transit send-to- receiver packets can be visualized as filling a pipeline, this technique is known as pipelining. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 14 Some consequences: The range of sequence numbers must be increased: each in-transit packet must have a unique sequence number Sender and receiver may have to buffer more than one packet. Two basic approaches toward pipelined error recovery can be identified: Go-Back-N and Selective Repeat. 3.4.3 Go-Back-N (GBN) The window at the sender is as follows: Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 15 The sender is allowed to send N packets (sender window size = N), the receiver has a window of size 1. If a segment from sender to receiver is lost, the receiver discards all the segments with sequence number greater than the sequence number of the dropped packet, answering with ACK with this sequence number. (no packet re-ordering) The sender will wait for ACK in order to move the window and send new packets. The wait is not infinite, after a certain time a timeout will occur and the sender will retransmit all the packets in the sending window. In a Go-Back-N protocol, acknowledgements are cumulative: if sender receives ACK3 he will know that all the packets from 0 to 3 have been received, even if hasn't received ACK2. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 16 3.4.4 Selective Repeat When the window-size and bandwidth-delay product are both large, many packets can be in the pipeline and a single packet error can thus cause GBN to retransmit a large number of packets, many unnecessarily. Selective Repeat avoid unnecessary retransmissions by having the sender retransmit only those that packets it suspects were received in error at the receiver: individual acknowledgements (opposed to cumulative). sender window size = N and receiver window size = N. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 17 The sender has a timer for each packet in its window. When a timeout occurs, only the missing packet is resent. The receiver buffers out of order packets. The following figure illustrate the idea of the Selective repeat: Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 18 3.5 Connection-Oriented Transport: TCP 3.5.1 The TCP Connection TCP is said to be connection-oriented because before one application process can begin to send data to another, the two processes must first "handshake" with each other. During the connection establishment, both sides of the connection will initialize many TCP state variables. TCP connection is not an end-to-end TDM or FDM circuit nor is it a virtual circuit as the connection state resides entirely in the two end systems and not in the intermediate network elements. A TCP connection provides a full-duplex service: when a connection between process A and process B, application layer data can flow from A to B and, at the same time, from B to A. TCP is also point-to-point: a connection is always between a single sender and a single receiver, no multicast possible. Establishment of the connection: the client first sends a special TCP segment, the server responds with a second special TCP segment and the client answer again with a third special TCP segment. The first two cannot contain a payload while the third can. Three segments: three-way handshake. Both the sender and the receiver have buffers that are set up during the handshake. The maximum amount if data that can be grabbed and placed in a segment is limited by the maximum segment size (MSS). TCP therefore splits data into smaller chunks and pairs each chunk of client data with a TCP header thereby forming TCP segments which are passed down to the network layer. When TCP receives a segment at the other end, the segment's data is placed in the TCP connection's receive buffer. Each side of the connection has its own send buffer and its own receive buffer. 3.5.2 TCP Segment Structure Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 19   32 bit sequence number and acknowledgement number necessary for reliable data transmission  16 bit receive window used for flow control, indicates the number of bytes that a receiver is willing to accept  4 bit header length field. The TCP header can be of a variable length due to the TCP options field (usually empty therefore usual length is 20 bytes)  options field used to negotiate MSS or as a window scaling factor for use in high speed networks.  flag field: 6 bits: i. ACK used to indicate that the value carried in the acknowledgement field is valid, that is the segment contains an acknowledgement for a segment that has been successfully received. ii. , 3. and 4. RST, SYN, FIN for connection setup and teardown iii. PSH indicates that the receiver should pass the data to upper layer immediately iv. URG indicates that there is data in the segment that the sending side upper layer has marked as urgent. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 20 Sequence Numbers and Acknowledgment Numbers TCP views data as an unstructured, but ordered, stream of bytes and TCP's use of sequence numbers reflects this view: sequence numbers are over the stream of bytes and not over the series of transmitted segments. The sequence number for a segment is the byte-stream number of the first byte in the segment. EX 500,000 bytes, MSS = 1,000 bytes => 500 segments are created. First is numbered 0, second 1000, third 2000..... The acknowledgement number that Host A puts in its segment is the sequence number of the next byte Host A is expecting from Host B. TCP is said to provide cumulative acknowledgements: if sender receives ACK 536 he will know that all the bytes from 0 to 535 have been well received. What does a host do when it receives out-of-order segments? The receiver buffers the out-of- order bytes and waits for the missing bytes to fill in the gaps. Usually both sides of a TCP connection randomly choose an initial sequence number randomly both for security and for minimizing the possibility that a segment that is still present in the network from an earlier, already terminated connection between two hosts is mistaken for a valid segment in a later connection between these same two hosts. 3.5.3 Round-Trip Time Estimation and Timeout TCP uses a timeout/retransmit mechanism to recover from lost segments. The question rises: How long should the timeout intervals be? Clearly the timeout should be larger than the connection's round-trip time? How much larger? How can the RTT be evaluated? Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 21 Estimating the Round-Trip Time The sample RTT, SampleRTT , for a segment is the amount of time between when the segment is sent (passed to network layer) and when an acknowledgement for the segment is received. Most TCP implementations take one SampleRTT at a time: at any point in time, the SampleRTT is being estimated for only one of the transmitted but currently unacknowledged segments, leading to a new value of SampleRTT for approximatively every RTT. TCP never computes a SampleRTT for a segment that has been retransmitted, only for segments transmitted once. In order to estimate a typical RTT, TCP keeps an average called EstimatedRTT of the SampleRTT values. Upon obtaining a new SampleRTT TCP updates this estimation according to the formula: EstimatedRTT = (1 - α) * EstimatedRTT + α * SampleRTT where usually α = 1/8 = 0.125 We note that this weighted average puts more weight on recent samples than on old samples. In statistics such an average is called an exponential weighted moving average (EWMA). It is also useful to having an estimate of the variability of the RTT. We can measure how much SampleRTT typically deviates from EstimatedRTT : DevRTT = (1 - β) * DevRTT + β * | SampleRTT - EstimatedRTT | The recommended value for b is β = 0.25 We note that this is an EWMA of the difference of estimated and last measured RTT. Setting and Managing the Retransmission Timeout Interval TimeoutInterval = EstimatedRTT + 4 * DevRTT An initial TimeoutInterval value of 1 second is recommended. Also when a timeout occurs, the value of TimeoutInterval is doubled in order to avoid a premature timeout occurring for a subsequent segment that will soon be acknowledged. As soon as a segment is received and EstimatedRTT is updated, the TimeoutInterval is again computed using the formula above. 3.5.4 Reliable Data Transfer TCP creates a reliable data transfer service on top of IP's unreliable best-effort service. It ensures that the data stream that a process reads out of its TCP receive buffer is uncorrupted, without gaps, without duplication and in sequence. We supposed until now that an individual timer was associated with each transmitted segment. However timer management can require considerable overhead. Thus the recommended TCP timer management procedures (defined by Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 22 RFC standards) use only a single retransmission timer (it is helpful to think of the timer as being associated with the oldest unacknowledged segment). 1. Upon receiving data from the application layer, TCP encapsulates it in a segment and passes to the segment to IP. If the timer is not running for some other segment, TCP starts it when the segment is passed to IP, the timer expiration interval being TimeoutInterval. 2. If the timeout occurs, TCP responds by retransmitting the segment that caused the timeout and by restarting the timer. 3. An valid acknowledgement segment is received: TCP compares the ACK y value with its sendBase (the sequence number of the oldest unacknowledged byte). If y > sendBase then ACK is acknowledging one or more previously unacknowledged segments (cumulative acknowledgement). The sendBase variable is updated and the timer is restarted if there are not-yet-acknowledged segments. Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 23 TCP Retransmission Scenarios Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 24 Doubling the Timeout Interval Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 25 Each time TCP retransmits, it sets the next timeout interval to twice the previous value. However when the timer is restarted after receiving data from the application layer or after receiving an ACK, the TimeoutInterval is recomputed as described previously. Fast Retransmit The problem with timeout-triggered retransmission is that the timeout period can be relatively long. The sender can however often detect packet loss before the timeout event occurs by noting duplicate ACKs. A duplicate ACK is an ACK that reacknowledges a segment for which the sender has already received an earlier acknowledgement. When the TCP sender receives three duplicate ACK for the same data it takes this as an indication that the segment following the segment that has been ACKed three times has been lost. In the case that three duplicate ACKs are received, the TCP sender performs a fast restransmit: it retransmits the missing segment before that segment's timer expires. Go-Back-N or Selective Repeat? Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 26 Acknowledgments are cumulative (GBN) but many TCP implementations will buffer correctly received but out-of-order segments. Also consider fast retransmit where only the missing packet is resent (SR) instead of all the window (GBN). We can see that TCP's error recovery mechanism is categorized as a hybdrid of GB and SR protocols. 3.5.5 Flow Control The host on each side of a TCP connection set aside a receive buffer for the connection. When TCP receives bytes that are correct and in sequence, it places the data in the receive buffer. The associated application process will read data from this buffer, but necessarily at the instant the data arrives (busy, not interested...). Thus the the sender can easily overflow the connection's receive bufffer by sending too much data too quickly. To avoid this event, TCP provides a flow-control service. Flow control is a speed-matching service: matching the rate at which the sender is sending against the rate at which the receiving application is reading. Flow control and congestion control are not the same: the former preventing overflow at the receiver side and being actuated only by the two end points, the latter preventing congestion of the network. TCP provides flow control by having the sender maintain a variable called the receive window, used to give the sender an idea of how much free buffer space is available at the receiver. Host A sends a large file to Host B over TCP.  Receiver B “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments RcvBuffer size set via socket options (typical default is 4096 bytes) many operating systems autoadjust RcvBuffer  sender A limits amount of unacked (“in-flight”) data to receiver’s rwnd value  guarantees receive buffer will not overflow Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence 27 B side 1. B allocates a receive buffer to its connection, its size being `RcvBuffer` 2. B also keeps the variables: `LastByteRead` (number of last byte in the data stream read by the application process) and `LastByteRcvd` (the number of the last byte arrived from the network and placed in the receive buffer) We have: LastByteRcvd - LastByteRead