Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Transport Layer

•Download as PPT, PDF•
•
Ram Dutt Shukla
Ram Dutt Shukla

Transport layer protocols provide services like reliable data transfer and connection establishment between applications on networked devices. They address this need through protocols like TCP and UDP. TCP provides reliable, ordered data streams using mechanisms like three-way handshake, sequence numbers, acknowledgments, retransmissions, flow control via sliding windows, and connection termination handshaking. UDP provides simple datagram transmissions without reliability or flow control.

1 of 58
Services provided by transport layer protocols Protocols running at the transport layer provide services to upper layers To enable software applications in higher layers to work over an internetwork For connections to be established and maintained between software services on possibly distant machines. To enable applications to send data in a reliable way without needing to worry about error correction, lost data or flow management, and network-layer protocols, which are often unreliable and unacknowledged.
Adressing at Network and Transport layers Internet Protocol (IP) provide addressing function on a TCP/IP network Network-layer addresses uniquely identify each network interface serve as the mechanism by which data is routed to the correct network on the internetwork and then the correct device on that network Additional level of addressing occurs at the transport layer in TCP/IP TCP and UDP, use the concepts of ports and sockets for virtual software addressing To enable the Multiplexing and Demultiplexing Using Ports
Multiplexing and de-mutiplexing in TCP/IP
Port numbers Mux & DeMUX by Protocol field included in the header of each IP datagram Source Port and a Destination Port Port number field -16 bit For example, port #80 is reserved for the Hypertext Transfer Protocol (HTTP) Port numbers assignments are managed by IANA well-known port numbers (0 –1023) registered port numbers (1024 – 49151) ( 49152 – 65535 ) that can be used without IANA registration
Client server ports Well-known and registered port numbers are needed for server processes Client processes don't use well-known or registered ports The server must know the port number of client to send reply Each client process use temporary port number called an ephemeral port number . These port numbers are assigned in a pseudo-random way
Client Server communication
Applcation, port, protocol ftp 21/tcp File Transfer [Control] ftp 21/udp File Transfer [Control] ssh 22/tcp SSH Remote Login Protocol ssh 22/udp SSH Remote Login Protocol telnet 23/tcp Telnet telnet 23/udp Telnet tftp 69/tcp Trivial File Transfer tftp 69/udp Trivial File Transfer http 80/tcp World Wide Web HTTP http 80/udp World Wide Web HTTP kerberos 88/tcp Kerberos kerberos 88/udp Kerberos pop3 110/tcp Post Office Protocol - Version
Sockets: Process Identification Combination of The IP address of the host it runs on Port number which has been assigned to it Notation <IP Address>:<Port Number> Eg: Socket corresponding to the HTTP server would be 41.199.222.3:80
Socket Pairs: Connection Identification The exchange of data between a pair of devices consists of a series of messages sent from a socket on one device to a socket on the other Each device will normally have multiple such simultaneous conversations going on A connection is established for each pair of devices for the duration of the communication session Each connection is uniquely identified using the combination of the client socket and server socket An Eg: connection between two devices can be described using this socket pair:(41.199.222.3:80, 177.41.72.6:3022)
UDP The User Datagram Protocol (UDP) was developed for use by application protocols that do not require reliability, acknowledgment or flow control features at the transport layer. It is designed to be simple and fast, providing only transport layer addressing in the form of UDP ports and an optional checksum capability, and little else.
What UDP Does UDP's real task is to take data from higher-layer protocols place it in UDP messages then pass down to the Internet Protocol for transmission The basic steps for transmission using UDP are: Higher-Layer Data Transfer UDP Message Encapsulation Transfer Message To IP
What UDP Does Not UDP does not Establish connections before sending data. Provide acknowledgments to show that data was received. Provide any guarantees that its messages will arrive. Detect lost messages and retransmit them. Ensure that data is received in the same order that they were sent. Provide any mechanism to manage the flow of data between devices, or handle congestion.
Use of UDP When an application values timely delivery over reliable delivery TCP’s retransmission of lost data would be of limited or even no value. A simple Application is able to handle the potential loss of an IP datagram and other features of TCP are not required. UDP is also used for applications that require multicast or broadcast transmissions TCP is only supported for unicast communication between two devices.
UDP datagram
UDP pseudo header
TCP The primary transport layer protocol in the TCP/IP suite is the Transmission Control Protocol (TCP) . TCP is a connection-oriented, acknowledged, reliable, fully-featured protocol designed to provide applications with a reliable way to send data using the unreliable Internet Protocol.
TCP It allows applications To send bytes of data as a stream of bytes Automatically packages them into appropriately-sized segments for transmission. It uses a special sliding window acknowledgment system To ensure that all data is received by its recipient To handle necessary retransmissions To provide flow control for connected devices to manage the rate at which data is sent.
TCP functions Addressing/Multiplexing Connection Establishment, Management and Termination Data Handling and Packaging Data Transfer Providing Reliability and Transmission Quality Services Providing Flow Control and Congestion Avoidance Features
Functions Not Performed By TCP Specifying Application Use Providing Security Maintaining Message Boundaries Guaranteeing Communication
TCP Characteristics Connection-Oriented Bidrectional Multiply-Connected and Endpoint-Identified Reliable Acknowledged Stream-Oriented Data-Unstructured Data-Flow-Managed
TCP Stream
TCP segment
TCP FSM The TCP finite state machine describes the sequence of steps taken by both devices in a TCP session as they establish, manage and close the connection. Three types of message that control transitions between states SYN: A synchronize message, used to initiate and establish a connection. It is so named since one of its functions is to synchronizes sequence numbers between devices. FIN: A finish message, which is a TCP segment with the FIN bit set, indicating that a device wants to terminate the connection. ACK: An acknowledgment, indicating receipt of a message such as a SYN or a FIN.
The Simplified TCP Finite State Machine
3 way handshake
Sequence number synchronisation As part of the process of connection establishment, each of the two devices in a TCP connection informs the other of the sequence number it plans to use for its first data transmission by putting the preceding sequence number in the Sequence Number field of its SYN message. The other device confirms this by incrementing that value and putting it into the Acknowledgment Number field of its ACK , telling the other device that is the sequence number it is expecting for the first data transmission. This process is called sequence number synchronization .
Sequence number Synchronisation
Additional parameters (opt) exchanged during connection setup Window Scale Factor : To specify larger window sizes than would normally the 16-bit size of the TCP Window field. Selective Acknowledgment Permitted: To use the optional selective acknowledgment feature to allow only certain lost segments to be retransmitted. Alternate Checksum Method: Specify an alternative method of performing checksums Normal Connection Termination than the standard TCP mechanism.
Normal Connection Termination Device sends a FIN message to tell the other device that it wants to end the connection It is s acknowledged by other Device. When the responding device is ready, it too sends a FIN. This response FIN that is acknowledged After waiting a period of time for the ACK to be received, the session is closed.
TCP close (connection termination)
The TIME-WAIT State The TIME-WAIT state is required for two main reasons. The first is to provide enough time to ensure that the ACK is received by the other device, and to retransmit it if it is lost. The second is to provide a “buffering period” between the end of this connection and any subsequent ones. If not for this period, it is possible that packets from different connections could be mixed, creating confusion. The standard specifies that the client should wait double a particular length of time called the maximum segment lifetime (MSL) before finishing the close of the connection.
Transmission control block Since each connection is distinct, we must maintain data about each connection separately. TCP uses a special data structure for this purpose, called a transmission control block (TCB) . Each device maintains its own TCB for the connection. TCB contains all information about the connection, such as:- Two socket numbers that identify it Pointers to buffers where incoming and outgoing data are held. The TCB is also used to implement the sliding window mechanism. It holds variables that keep track of the number of bytes received and acknowledged, Bytes received and not yet acknowledged Current window size and so forth
TCB set up Before the process of setting up a TCP connection can begin, the devices on each end must perform some “prep work”. One of the tasks required to prepare for the connection is to set up the TCB that will be used to hold information about it. This is done right at the very start of the connection establishment process, when each device just transitions out of the CLOSED state
TCP requirements Two key requirements of the protocol: Reliability: Ensuring that data that is sent actually arrives at its destination, and if not, detecting this and re-sending the data. Data Flow Control: Managing the rate at which data is sent so that it does not overwhelm the device that is receiving it.
PAR Reliability in communications follow a rule a device to send back an acknowledgment each time it successfully receives a transmission If a transmission is not acknowledged after a period of time, it is retransmitted by its sender This system is called positive acknowledgment with retransmission (PAR) One drawback: the transmitter cannot send next message until the previous is acknowledged.
PAR
TCP ACK & Retransmission TCP acknowledgments are cumulative Tell a transmitter that all the bytes up to the sequence number indicated in the acknowledgment were received successfully. If bytes are received out of order, they cannot be acknowledged until all the preceding bytes are received. TCP includes a method for timing transmissions and retransmitting lost segments if necessary.
Managing Retransmissions Each time a segment is sent, a copy is Placed On Retransmission Queue Timer Starts at a predetermined value Counts down over time If an acknowledgment is received for a segment before its timer expires, the segment is removed from the retransmission queue If the timer expires before an acknowledgment is received, the segment is retransmitted No guarantee that a retransmitted segment will be received If not, Retransmission timer is reset, the segment will be retransmitted again and the process repeated
Policies For Dealing with Retransmission Retransmit Only Timed-Out Segments Retransmit All Outstanding Segments TCP selective acknowledgment
Retransmission Time Length of time for retransmission timer is very important If it is set too low A segment actually received might be retransmitted didn't wait long enough for the acknowledgment if it is set too long waste time waiting for an acknowledgment that will never arrive reducing overall performance
Choosing Retransmission time Ideally, the retransmission timer should be of value just slightly larger than the round-trip time (RTT) How to determine RTT? Differences in TCP Connection Distances. Transient Delays and Variability : The amount of time it takes to send data between any two devices will vary over time due to various happenings on the internetwork: fluctuations in traffic, router loads and so on.
Adaptive Retransmission Based RTT TCP uses a dynamic, or adaptive retransmission scheme Average RTT value for the connection A smoothing formula: New RTT = (a * Old RTT) + ( (1-a) * Newest RTT Measurement); 0 < a < 1 a ~ 1 -> better smoothing, slow reaction a ~ 0 -> fast reaction
RTT Calculation by Karn's Algorithm Karn's algorithm- Inventor, Phil Karn Does not use measured round-trip times Eliminates problem of acknowledgment ambiguity Start by setting the timer, based on the current average round-trip time On retransmission, the timer is not reset to the same value but is “backed off” (increased) using a multiplier (typically 2) to give the retransmission more time to be received The timer continues to be increased until a retransmission is successful, up to a certain maximum value
RTT Calculation by Karn's Algorithm The round-trip timer is kept at the longer (backed-off) value until a valid round-trip time can be measured on a segment that is sent and acknowledged without retransmission This permits a device to respond with longer timers temporarily, while eventually having the round-trip time settle back to a long-term average when normal conditions resume
TCP sliding window A variation on the enhanced PAR system To support TCP’s stream orientation Each device keeps track of the status of the byte stream Dividing Data into four conceptual categories: Bytes sent and acknowledged Bytes sent but not yet acknowledged Bytes not yet sent but that can be sent immediately Bytes not yet sent that cannot be sent until the recipient signals that it is ready for them.
Data Stream categories
Send, usable windows The send window is the key to the entire TCP sliding window system: it represents the maximum number of unacknowledged bytes a device is allowed to have outstanding at once. The usable window is the amount of the send window that the sender is still allowed to send at any point in time; it is equal to the size of the send window less the number of unacknowledged bytes already transmitted.
Send and usable window
Send and usable window
Implementing sliding window Three essential fields in the TCP segment The Sequence Number field indicates the number of the first byte of data being transmitted. The Acknowledgment Number is used to acknowledge data received by the device sending this segment. The Window field tells the recipient of the segment the size to which it should set its send window
Window slide When a device gets an acknowledgment for a range of bytes, it knows they have been successfully received by their destination. It moves them from the “sent but unacknowledged” to the “sent and acknowledged” category. This causes the send window to slide to the right, allowing the device to send more data.
TCP window size management The receiver on receipt of segment must Send Acknowledgement Transfer data from buffer to application Receiver delay in transfer can happen Danger of buffer overflow Varying window size to manage data flow
Flow control The TCP sliding window system is used not just for ensuring reliability through acknowledgments and retransmission it is also the basis for TCP’s flow control mechanism. By increasing or reducing the size of its receive window a device can raise or lower the rate at which its connection partner sends it data. In the case where a device becomes extremely busy, it can even reduce the receive window to zero, closing it this will halt any further transmissions of data until the window is reopened
Shrinking window
Silly window syndrome Sliding window mechanism does not ensure a min size of segment Shrinking window can result in inefficient transmission of small size segment
Silly window syndrome
SWS avoidance algorithm Receiver SWS avoidance Restrict moving right edge of window by too small amount Reduce window size to 0 Right edge be moved by half buffer size or MSS whichever is less
Sender SWS avoidance algorithm Nagle’s algorithm – John Nagle Data can be immediately sent as long as all sent data is acknowledged When there is unacknowledged data Do not send till all data acknowledged Send after accumulating data for full segment

More Related Content

Transport Layer

  • 1. Services provided by transport layer protocols Protocols running at the transport layer provide services to upper layers To enable software applications in higher layers to work over an internetwork For connections to be established and maintained between software services on possibly distant machines. To enable applications to send data in a reliable way without needing to worry about error correction, lost data or flow management, and network-layer protocols, which are often unreliable and unacknowledged.
  • 2. Adressing at Network and Transport layers Internet Protocol (IP) provide addressing function on a TCP/IP network Network-layer addresses uniquely identify each network interface serve as the mechanism by which data is routed to the correct network on the internetwork and then the correct device on that network Additional level of addressing occurs at the transport layer in TCP/IP TCP and UDP, use the concepts of ports and sockets for virtual software addressing To enable the Multiplexing and Demultiplexing Using Ports
  • 4. Port numbers Mux & DeMUX by Protocol field included in the header of each IP datagram Source Port and a Destination Port Port number field -16 bit For example, port #80 is reserved for the Hypertext Transfer Protocol (HTTP) Port numbers assignments are managed by IANA well-known port numbers (0 –1023) registered port numbers (1024 – 49151) ( 49152 – 65535 ) that can be used without IANA registration
  • 5. Client server ports Well-known and registered port numbers are needed for server processes Client processes don't use well-known or registered ports The server must know the port number of client to send reply Each client process use temporary port number called an ephemeral port number . These port numbers are assigned in a pseudo-random way
  • 7. Applcation, port, protocol ftp 21/tcp File Transfer [Control] ftp 21/udp File Transfer [Control] ssh 22/tcp SSH Remote Login Protocol ssh 22/udp SSH Remote Login Protocol telnet 23/tcp Telnet telnet 23/udp Telnet tftp 69/tcp Trivial File Transfer tftp 69/udp Trivial File Transfer http 80/tcp World Wide Web HTTP http 80/udp World Wide Web HTTP kerberos 88/tcp Kerberos kerberos 88/udp Kerberos pop3 110/tcp Post Office Protocol - Version
  • 8. Sockets: Process Identification Combination of The IP address of the host it runs on Port number which has been assigned to it Notation <IP Address>:<Port Number> Eg: Socket corresponding to the HTTP server would be 41.199.222.3:80
  • 9. Socket Pairs: Connection Identification The exchange of data between a pair of devices consists of a series of messages sent from a socket on one device to a socket on the other Each device will normally have multiple such simultaneous conversations going on A connection is established for each pair of devices for the duration of the communication session Each connection is uniquely identified using the combination of the client socket and server socket An Eg: connection between two devices can be described using this socket pair:(41.199.222.3:80, 177.41.72.6:3022)
  • 10. UDP The User Datagram Protocol (UDP) was developed for use by application protocols that do not require reliability, acknowledgment or flow control features at the transport layer. It is designed to be simple and fast, providing only transport layer addressing in the form of UDP ports and an optional checksum capability, and little else.
  • 11. What UDP Does UDP's real task is to take data from higher-layer protocols place it in UDP messages then pass down to the Internet Protocol for transmission The basic steps for transmission using UDP are: Higher-Layer Data Transfer UDP Message Encapsulation Transfer Message To IP
  • 12. What UDP Does Not UDP does not Establish connections before sending data. Provide acknowledgments to show that data was received. Provide any guarantees that its messages will arrive. Detect lost messages and retransmit them. Ensure that data is received in the same order that they were sent. Provide any mechanism to manage the flow of data between devices, or handle congestion.
  • 13. Use of UDP When an application values timely delivery over reliable delivery TCP’s retransmission of lost data would be of limited or even no value. A simple Application is able to handle the potential loss of an IP datagram and other features of TCP are not required. UDP is also used for applications that require multicast or broadcast transmissions TCP is only supported for unicast communication between two devices.
  • 16. TCP The primary transport layer protocol in the TCP/IP suite is the Transmission Control Protocol (TCP) . TCP is a connection-oriented, acknowledged, reliable, fully-featured protocol designed to provide applications with a reliable way to send data using the unreliable Internet Protocol.
  • 17. TCP It allows applications To send bytes of data as a stream of bytes Automatically packages them into appropriately-sized segments for transmission. It uses a special sliding window acknowledgment system To ensure that all data is received by its recipient To handle necessary retransmissions To provide flow control for connected devices to manage the rate at which data is sent.
  • 18. TCP functions Addressing/Multiplexing Connection Establishment, Management and Termination Data Handling and Packaging Data Transfer Providing Reliability and Transmission Quality Services Providing Flow Control and Congestion Avoidance Features
  • 19. Functions Not Performed By TCP Specifying Application Use Providing Security Maintaining Message Boundaries Guaranteeing Communication
  • 20. TCP Characteristics Connection-Oriented Bidrectional Multiply-Connected and Endpoint-Identified Reliable Acknowledged Stream-Oriented Data-Unstructured Data-Flow-Managed
  • 23. TCP FSM The TCP finite state machine describes the sequence of steps taken by both devices in a TCP session as they establish, manage and close the connection. Three types of message that control transitions between states SYN: A synchronize message, used to initiate and establish a connection. It is so named since one of its functions is to synchronizes sequence numbers between devices. FIN: A finish message, which is a TCP segment with the FIN bit set, indicating that a device wants to terminate the connection. ACK: An acknowledgment, indicating receipt of a message such as a SYN or a FIN.
  • 24. The Simplified TCP Finite State Machine
  • 26. Sequence number synchronisation As part of the process of connection establishment, each of the two devices in a TCP connection informs the other of the sequence number it plans to use for its first data transmission by putting the preceding sequence number in the Sequence Number field of its SYN message. The other device confirms this by incrementing that value and putting it into the Acknowledgment Number field of its ACK , telling the other device that is the sequence number it is expecting for the first data transmission. This process is called sequence number synchronization .
  • 28. Additional parameters (opt) exchanged during connection setup Window Scale Factor : To specify larger window sizes than would normally the 16-bit size of the TCP Window field. Selective Acknowledgment Permitted: To use the optional selective acknowledgment feature to allow only certain lost segments to be retransmitted. Alternate Checksum Method: Specify an alternative method of performing checksums Normal Connection Termination than the standard TCP mechanism.
  • 29. Normal Connection Termination Device sends a FIN message to tell the other device that it wants to end the connection It is s acknowledged by other Device. When the responding device is ready, it too sends a FIN. This response FIN that is acknowledged After waiting a period of time for the ACK to be received, the session is closed.
  • 30. TCP close (connection termination)
  • 31. The TIME-WAIT State The TIME-WAIT state is required for two main reasons. The first is to provide enough time to ensure that the ACK is received by the other device, and to retransmit it if it is lost. The second is to provide a “buffering period” between the end of this connection and any subsequent ones. If not for this period, it is possible that packets from different connections could be mixed, creating confusion. The standard specifies that the client should wait double a particular length of time called the maximum segment lifetime (MSL) before finishing the close of the connection.
  • 32. Transmission control block Since each connection is distinct, we must maintain data about each connection separately. TCP uses a special data structure for this purpose, called a transmission control block (TCB) . Each device maintains its own TCB for the connection. TCB contains all information about the connection, such as:- Two socket numbers that identify it Pointers to buffers where incoming and outgoing data are held. The TCB is also used to implement the sliding window mechanism. It holds variables that keep track of the number of bytes received and acknowledged, Bytes received and not yet acknowledged Current window size and so forth
  • 33. TCB set up Before the process of setting up a TCP connection can begin, the devices on each end must perform some “prep work”. One of the tasks required to prepare for the connection is to set up the TCB that will be used to hold information about it. This is done right at the very start of the connection establishment process, when each device just transitions out of the CLOSED state
  • 34. TCP requirements Two key requirements of the protocol: Reliability: Ensuring that data that is sent actually arrives at its destination, and if not, detecting this and re-sending the data. Data Flow Control: Managing the rate at which data is sent so that it does not overwhelm the device that is receiving it.
  • 35. PAR Reliability in communications follow a rule a device to send back an acknowledgment each time it successfully receives a transmission If a transmission is not acknowledged after a period of time, it is retransmitted by its sender This system is called positive acknowledgment with retransmission (PAR) One drawback: the transmitter cannot send next message until the previous is acknowledged.
  • 36. PAR
  • 37. TCP ACK & Retransmission TCP acknowledgments are cumulative Tell a transmitter that all the bytes up to the sequence number indicated in the acknowledgment were received successfully. If bytes are received out of order, they cannot be acknowledged until all the preceding bytes are received. TCP includes a method for timing transmissions and retransmitting lost segments if necessary.
  • 38. Managing Retransmissions Each time a segment is sent, a copy is Placed On Retransmission Queue Timer Starts at a predetermined value Counts down over time If an acknowledgment is received for a segment before its timer expires, the segment is removed from the retransmission queue If the timer expires before an acknowledgment is received, the segment is retransmitted No guarantee that a retransmitted segment will be received If not, Retransmission timer is reset, the segment will be retransmitted again and the process repeated
  • 39. Policies For Dealing with Retransmission Retransmit Only Timed-Out Segments Retransmit All Outstanding Segments TCP selective acknowledgment
  • 40. Retransmission Time Length of time for retransmission timer is very important If it is set too low A segment actually received might be retransmitted didn't wait long enough for the acknowledgment if it is set too long waste time waiting for an acknowledgment that will never arrive reducing overall performance
  • 41. Choosing Retransmission time Ideally, the retransmission timer should be of value just slightly larger than the round-trip time (RTT) How to determine RTT? Differences in TCP Connection Distances. Transient Delays and Variability : The amount of time it takes to send data between any two devices will vary over time due to various happenings on the internetwork: fluctuations in traffic, router loads and so on.
  • 42. Adaptive Retransmission Based RTT TCP uses a dynamic, or adaptive retransmission scheme Average RTT value for the connection A smoothing formula: New RTT = (a * Old RTT) + ( (1-a) * Newest RTT Measurement); 0 < a < 1 a ~ 1 -> better smoothing, slow reaction a ~ 0 -> fast reaction
  • 43. RTT Calculation by Karn's Algorithm Karn's algorithm- Inventor, Phil Karn Does not use measured round-trip times Eliminates problem of acknowledgment ambiguity Start by setting the timer, based on the current average round-trip time On retransmission, the timer is not reset to the same value but is “backed off” (increased) using a multiplier (typically 2) to give the retransmission more time to be received The timer continues to be increased until a retransmission is successful, up to a certain maximum value
  • 44. RTT Calculation by Karn's Algorithm The round-trip timer is kept at the longer (backed-off) value until a valid round-trip time can be measured on a segment that is sent and acknowledged without retransmission This permits a device to respond with longer timers temporarily, while eventually having the round-trip time settle back to a long-term average when normal conditions resume
  • 45. TCP sliding window A variation on the enhanced PAR system To support TCP’s stream orientation Each device keeps track of the status of the byte stream Dividing Data into four conceptual categories: Bytes sent and acknowledged Bytes sent but not yet acknowledged Bytes not yet sent but that can be sent immediately Bytes not yet sent that cannot be sent until the recipient signals that it is ready for them.
  • 47. Send, usable windows The send window is the key to the entire TCP sliding window system: it represents the maximum number of unacknowledged bytes a device is allowed to have outstanding at once. The usable window is the amount of the send window that the sender is still allowed to send at any point in time; it is equal to the size of the send window less the number of unacknowledged bytes already transmitted.
  • 48. Send and usable window
  • 49. Send and usable window
  • 50. Implementing sliding window Three essential fields in the TCP segment The Sequence Number field indicates the number of the first byte of data being transmitted. The Acknowledgment Number is used to acknowledge data received by the device sending this segment. The Window field tells the recipient of the segment the size to which it should set its send window
  • 51. Window slide When a device gets an acknowledgment for a range of bytes, it knows they have been successfully received by their destination. It moves them from the “sent but unacknowledged” to the “sent and acknowledged” category. This causes the send window to slide to the right, allowing the device to send more data.
  • 52. TCP window size management The receiver on receipt of segment must Send Acknowledgement Transfer data from buffer to application Receiver delay in transfer can happen Danger of buffer overflow Varying window size to manage data flow
  • 53. Flow control The TCP sliding window system is used not just for ensuring reliability through acknowledgments and retransmission it is also the basis for TCP’s flow control mechanism. By increasing or reducing the size of its receive window a device can raise or lower the rate at which its connection partner sends it data. In the case where a device becomes extremely busy, it can even reduce the receive window to zero, closing it this will halt any further transmissions of data until the window is reopened
  • 55. Silly window syndrome Sliding window mechanism does not ensure a min size of segment Shrinking window can result in inefficient transmission of small size segment
  • 57. SWS avoidance algorithm Receiver SWS avoidance Restrict moving right edge of window by too small amount Reduce window size to 0 Right edge be moved by half buffer size or MSS whichever is less
  • 58. Sender SWS avoidance algorithm Nagle’s algorithm – John Nagle Data can be immediately sent as long as all sent data is acknowledged When there is unacknowledged data Do not send till all data acknowledged Send after accumulating data for full segment

Editor's Notes

  1. The question is: how do we demultiplex a sequence of IP datagrams that need to go to many different application processes? Let&apos;s consider a particular host with a single network interface bearing the IP address 24.156.79.20. Normally, every datagram received by the IP layer will have this value in the IP Destination Address field. Consecutive datagrams received by IP may contains a piece of a file you are downloading with your Web browser, an e-mail sent to you by your brother, and a line of text a buddy wrote in an IRC chat channel. How does the IP layer know which datagrams go where, if they all have the same IP address? The first part of the answer lies in the Protocol field included in the header of each IP datagram. This field carries a code that identifies the protocol that sent the data in the datagram to IP. Since most end-user applications use TCP or UDP at the transport layer, the Protocol field in a received datagram tells IP to pass data to either TCP or UDP as appropriate. In both UDP and TCP messages two addressing fields appear, for a Source Port and a Destination Port . These are analogous to the fields for source address and destination address at the IP level , but at a higher level of detail. They identify the originating process on the source machine, and the destination process on the destination machine. They are filled in by the TCP or UDP software before transmission, and used to direct the data to the correct process on the destination device. TCP and UDP port numbers are 16 bits in length, so valid port numbers can theoretically take on values from 0 to 65,535. As we will see in the next topic , these values are divided into ranges for different purposes, with certain ports reserved for particular uses. One fact that is sometimes a bit confusing is that both UDP and TCP use the same range of port numbers, and they are independent. So, in theory, it is possible for UDP port number 77 to refer to one application process and TCP port number 77 to refer to an entirely different one. There is no ambiguity, at least to the computers , because as mentioned above, each IP datagram contains a Protocol field that specifies whether it is carrying a TCP message or a UDP message. IP passes the datagram to either TCP or UDP, which then sends the message on to the right process using the port number in the TCP or UDP header. This mechanism is illustrated in Figure 198 . In practice, having TCP and UDP use different port numbers is confusing, especially for the reserved port numbers used by common applications. For this reason, by convention, most reserved port numbers are reserved for both TCP and UDP. For example, port #80 is reserved for the Hypertext Transfer Protocol (HTTP) for both TCP and UDP, even though HTTP only uses TCP. Application process multiplexing and demultiplexing in TCP/IP is implemented using the IP Protocol field and the UDP/TCP Source Port and Destination Port fields. Upon transmission, the Protocol field is given a number to indicate whether TCP or UDP was used, and the port numbers are filled in to indicate the sending and receiving software process. The device receiving the datagram uses the Protocol field to determine whether TCP or UDP was used, and then passes the data to the software process indicated by the Destination Port number
  2. Higher-Layer Data Transfer: An application sends a message to the UDP software . UDP Message Encapsulation: The higher-layer message is encapsulated into the Data field of a UDP message. The headers of the UDP message are filled in, including the Source Port of the application that sent the data to UDP, and the Destination Port of the intended recipient. The checksum value may also be calculated. Transfer Message To IP: The UDP message is passed to IP for transmission
  3.   TCP is designed to have applications send data to it as a stream of bytes, rather than requiring fixed-size messages to be used. This provide maximum flexibility for a wide variety of uses, because applications don’t need to worry about data packaging, and can send files or messages of any size. TCP takes care of packaging these bytes into messages called segments . Consider for example an application that is sending database records. It needs to transmit record #579 from the Employees database table, followed by record #581 and record #611. It sends these records to TCP, which treats them all collectively as a stream of bytes. TCP will package these bytes into segments, but in a manner the application cannot predict. It is possible that each will end up in a different segment, but more likely they will all be in one segment, or part of each will end up in different segments, depending on their length. The records themselves must have some sort of explicit markers so the receiving device can tell where one record ends and the next starts. Since applications send data to TCP as a stream of bytes and not prepackaged messages, each application must use its own scheme to determine where one application data element ends and the next begins. TCP is said to treat data coming from an application as a stream ; thus, the description of TCP as stream-oriented . Each application sends the data it wishes to transmit as a steady stream of octets (bytes). It doesn&apos;t need to carve them into blocks, or worry about how lengthy streams will get across the internetwork. It just “pumps bytes” to TCP. TCP is designed to have applications send data to it as a stream of bytes, rather than requiring fixed-size messages to be used. This provide maximum flexibility for a wide variety of uses, because applications don’t need to worry about data packaging, and can send files or messages of any size. TCP takes care of packaging these bytes into messages called segments . Since TCP works with individual bytes of data rather than discrete messages, it must use an identification scheme that works at the byte level to implement its data transmission and tracking system. This is accomplished by assigning each byte TCP processes a sequence number . Since applications send data to TCP as a stream of bytes and not prepackaged messages, each application must use its own scheme to determine where one application data element ends and the next begins. Consider for example an application that is sending database records. It needs to transmit record #579 from the Employees database table, followed by record #581 and record #611. It sends these records to TCP, which treats them all collectively as a stream of bytes. TCP will package these bytes into segments, but in a manner the application cannot predict. It is possible that each will end up in a different segment, but more likely they will all be in one segment, or part of each will end up in different segments, depending on their length. The records themselves must have some sort of explicit markers so the receiving device can tell where one record ends and the next starts.