R. Fox. TCP big window and NAK options. RFC 1106, IETF, June 1989.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....status will not guarantee a seamless transition. Sometimes it is necessary to transfer the state of a replaceable component to its new counterpart. As an example, consider the replacement of the acknowledgement strategy used by a deployed reliability protocol (such as replacing ACK [ 16] by NAK [3] support) In that case, a seamless transition can only be realized when component related state information (such as the sequence number of the expected packet) is transferred from the old to the new components. The State Transition Handler (see figure 3) of the control plane will take care of ....

R. Fox. TCP big window and NAK options. RFC 1106, IETF, June 1989.

.... have high loss, changing delays, or large amounts of data in transit at one time; Protect Against Wrapped Sequence Numbers (RFC 1323, reference [5] addresses very long delay environments or very high bandwidth missions; Selective negative acknowledgment (adapted from RFC 1106, reference [B5]) addresses high loss environments; Record Boundary Indication the ability to mark and reliably carry end of record indications for packet oriented applications; Best Effort Communication the ability for an application to select correct, insequence, but possibly incomplete delivery ....

R. Fox. TCP Big Window and Nak Options. RFC 1106, June 1989.

....to the receiver and prevents the sender from flooding the network with a quickly increasing data stream. However, the advent of Short Long Fat Networks ( S,L]FNs) and multimedia WWW traffic have created different requirements for TCP congestion and window control to those originally implemented [7]. Recent TCP extensions such as Window Scaling [7] and Fast Retransmit Recovery [20] have done much to cope with increasingly reliable, high bandwidth, fibre based communications. However, issues related to TCP s sometimes inappropriate reaction to network congestion have not been addressed [7] ....

....the network with a quickly increasing data stream. However, the advent of Short Long Fat Networks ( S,L]FNs) and multimedia WWW traffic have created different requirements for TCP congestion and window control to those originally implemented [7] Recent TCP extensions such as Window Scaling [7] and Fast Retransmit Recovery [20] have done much to cope with increasingly reliable, high bandwidth, fibre based communications. However, issues related to TCP s sometimes inappropriate reaction to network congestion have not been addressed [7] In particular, reference has been made to TCP s ....

[Article contains additional citation context not shown here]

R. Fox.:TCP Big Window and Nak Options, RFC1106, 1989

....to the receiver and prevents the sender from flooding the network with a quickly increasing data stream. However, the advent of Short Long Fat Networks ( S,L]FNs) and multimedia WWW traffic have created different requirements for TCP congestion and window control to those originally implemented [7]. Recent TCP extensions such as Window Scaling [7] and Fast Retransmit Recovery [21] have done much to cope with increasingly reliable, high bandwidth, fibre based communications. However, issues related to TCP s sometimes inappropriate reaction to network congestion have not been addressed [7] ....

....the network with a quickly increasing data stream. However, the advent of Short Long Fat Networks ( S,L]FNs) and multimedia WWW traffic have created different requirements for TCP congestion and window control to those originally implemented [7] Recent TCP extensions such as Window Scaling [7] and Fast Retransmit Recovery [21] have done much to cope with increasingly reliable, high bandwidth, fibre based communications. However, issues related to TCP s sometimes inappropriate reaction to network congestion have not been addressed [7] In particular, reference has been made to TCP s ....

[Article contains additional citation context not shown here]

R. Fox.:TCP Big Window and Nak Options, RFC1106, 1989

....that one process can have. Exploiting message oriented protocols within additional user space processes (e.g. communication daemons) will only degrade overall system performance, because of increased resource usage, OS overheads, and process management overheads. There have been recent proposals [25, 32, 33, 34] for enhancing TCP, to improve its performance on networks with high bandwidth delay products. When incorporated in TCP, these enhancements increase the size of the kernel, even though they may be used optionally. Building too much functionality into a specific service protocol tends to decrease ....

....of TCP IP [4, 46] and other reliable transport mechanisms, without sacrificing simplicity or compromising portability to shared memory multiprocessors. We designed the TRAP protocol with the future in mind, with features to enable its efficient operation on high bandwidthdelay product networks [25, 32, 33, 34]. TRAP also supports remote thread activations and active messages [58] through use of the a register and a exec primitives provided by the Ariadne threads system [37] The a register primitive binds the ascii name of a function or thread to a pointer to the specified code. The a exec primitive ....

R. Fox. TCP Big Window and NAK Options. RFC-1106, June 1989.

....and retransmitting lost segments; however, TCP assumes the source of all packet loss is network congestion. Consequently, TCP invokes congestion control, reduces its congestion window, and in turn, its transmission rate as a result of any packet loss [Jac88] As has been pointed out previously [Fox89, CI95, BSAK95], this response is inappropriate when faced with loss due to corruption rather than congestion, as is often the case on space and other mobile communications links. TCP s congestion control algorithm works well in dealing with congestion induced loss, but only results in reduced throughput on ....

....to loss, SNACK is of particular benefit in keeping the pipe full and allowing transmission to continue at full throttle while recovering from losses. The SCPS TP SNACK option draws from both the TCP Selective Acknowledgment (SACK) option [MMFR96] and the TCP Negative Acknowledgment (NAK) option [Fox89], which was proposed in 1989, but never adopted as a standard. Both of these options address the problem described above, in which throughput suffers when TCP experiences more than one segment loss in a window. We briefly describe these options in the following paragraphs, explain why they are ....

R. Fox, "TCP Big Window and Nak Options," Request for Comments 1106, IETF, June 1989.

No context found.

R. Fox. TCP big window and NAK options. RFC 1106, IETF, June 1989.

No context found.

R. Fox, "TCP big window and NAK options", 06/01/1989, 13 pages.

No context found.

. R. Fox. TCP Big Window and Nak Options. Internet Request for Comments, RFC 1106, Network Information Center, SRI International, Menlo Park, CA, June, 1989.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC