ssrs barcode image Fifteen in Software

Generator QR Code in Software Fifteen

Summary of Objectives in RFC-2488 Use Recommended Recommended RFC-2488 section 3.1 3.2 Where applied Sender Link Sender Sender Sender Sender Sender and receiver Sender and receiver Sender and receiver Sender and receiver

Mechanism Path MTU-Discovery FEC Slow start Congestion avoidance Fast retransmit Fast recovery Window scaling PAWS RTTM TCP SACKS

TCP congestion control Required 4.1.1 Required 4.1.1 Recommended 4.1.2 Recommended 4.1.2 TCP large windows Recommended 4.2 Recommended 4.2 Recommended 4.2 Recommended 4.4

Forward error correction (FEC).

Lost packets, whether from transmission errors or congestion, are assumed by the TCP to happen as a result of congestion, which means that congestion control is implemented, with its resulting reduction in throughput. Although there is ongoing research into ways of identifying the mechanisms for packet loss, the problem still remains. Application of FEC (as described in Chap. 11) therefore should be used where possible. These strategies have already been described in Sec. 15.8, along with the problems introduced by long RTTs. Slow start and congestion avoidance control the number of segments transmitted, but not the size of the segments. Using Path MTUDiscovery as described earlier can increase the size, and hence the data throughput is improved. From the nature of the ACKs received, the fast retransmit algorithm enables the sender to identify and resend a lost segment before its timeout expires. Since the data flow is not interrupted by timeouts, the sender can infer that congestion is not a problem, and the fast recovery algorithm prevents the congestion window from reverting to slow start. The fast retransmit algorithm can only respond to one lost segment per send window. If there is more than one, the others trigger the slow start mechanism.

As shown in Sec. 15.9 in connection with the bandwidth delay product, the receive window size is limited by the address field to 64 kilobytes maximum. By introducing a window scale extension into the TCP header, the address field can be effectively increased to 32 bits. Allowing for certain overheads, the maximum window size that can be declared is 230 1 gigabyte (again keeping in mind that 1 gigabyte 10243 bytes). The window size and hence the scale factor can be set locally by the receive TCP layer. Note, however, that the TCP extension has to be implemented at the sender and the receiver. The two mechanisms PAWS, which stands for protection against wrapped sequence, and RTTM, which stands for round-trip time measurement, are extensions that should be used with large windows. Maintaining steady traffic flow and avoiding congestion require a current knowledge of the RTT, which can be difficult to obtain with large windows. By including a time stamp in the TCP header, the RTT can be measured. Another problem that arises with large windows is that the numbering of old sequences can overlap with new, a condition known as wrap-around. The protection against wrapped sequences is an algorithm that also makes use of the time stamp. These algorithms are described fully in RFC-1323.

SACK stands for selective acknowledgment and is a strategy that enables the receiver to inform the sender of all segments received successfully. The sender then need resend only the missing segments. The strategy should be used where multiple segments may be lost during transmission, such as, for example, in a satellite link, since clearly, retransmission of duplicate segments over long delay paths would seriously reduce the throughput. Full details of SACK will be found in RFC-2018.

15.11 Requests for Comments The rapid growth of the Internet resulted, in large part, from the free and open access to documentation provided by network researchers. The ideas and proposals of researchers are circulated in memos called requests for comments (RFCs). They can be accessed on the World Wide Web at a number of sites, for example, http://www.rfceditor.org/. Following is a summary of some of the RFCs that relate specifically to satellite links and have been referred to in Sec. 15.5

RFC-2760, Ongoing TCP Research Related to Satellites, February 2000. Abstract: This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by the IETF. The goal of this document is to educate researchers as to the current work and progress being done in TCP research related to satellite networks. RFC-2488, Enhancing TCP Over Satellite Channels Using Standard Mechanisms, January 1999. Abstract: The TCP provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels, there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. At this time, all mitigations discussed in this document are IETF standards track mechanisms (or are compliant with IETF standards). RFC-2018, TCP Selective Acknowledgment Options, October 1996. Abstract: TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round-trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been received successfully. A SACK