The response spacing requires ACK to close the response interval router. When the response splitting router is also an intermediary node, the W-WAN environment is required to operate well.
Before we propose this recommendation, we need to have a deeper-deeper-deeper study by Limited byte Counting.
4.3.2.2 Ack-every-segment
The main idea of each response is this:
- Maintains a constant return ACK signal stream by closing the delayed ACK confirmation signal [RFC 1122]. Each section is limited to slow start, which avoids the problems caused by asymmetric bandwidth configurations. For example, the low bandwidth connection hinders the formation of the clogging window when returning the confirmation signal to the sender, even if the bandwidth of the connected client is large enough [BPK99].
The receiving party does not have to wait 200 milliseconds to obtain a delayed confirmation, and the second segment that is not modified directly from the sender. In order to make this technology, the receiver must obtain each segment when the sender is starting slowly. However, when the sender is in blocking to avoid the state, if it continues to do so, there will be a negative impact on the battery consumption of the mobile device and the traffic conditions of the network.
This violates the principles set out in [RFC2581]: The TCP recipient must use a latency confirmation.
"ACK confirmation signal" in the slow startup process "is a technology that cannot be implemented, because the recipient cannot know when the sender passes the slow start threshold, when is the use of blockage avoidance algorithms. If the recipient is made in accordance with the recommendations of the Initial Windows, the latency ACK confirmation signal is masked when the initialization window grows, which will make the TCP window to open faster, and usually do not cause double ACK traffic. However, if most connections are maintained in slow start, this solution may still lead to double ACK traffic.
Recommendation: Require the first segment of the new connection (ACK) immediately.
Montenegro, et al. Informational [Page 16]
4.3.3 Termination Slow Start
In order to reduce the possibility of network blockage, better use of bandwidth, thereby increasing the improvement of TCP, but also introduces a new mechanism, ie [adgghosstt98]. The mechanism will limit the end of the blocking window within 1 segment (exclude fast relay) and cause concurrent slow start to re-adjust the phase.
Therefore, the appropriate slow start threshold will make the connection utilize the bandwidth as much as possible, without causing 'overload' ('OVERSHOOT', which occupies too much bandwidth to generate the packet, and cause the plug to avoid the program to be called) .
Suggestion: Even if we know how to do it, it is not recommended to estimate the slow start threshold. Although this may be helpful, most people of TCP-IMPL and TCP-SAT mailing lists believe that this situation is not only probably in the TCP startup process.
4.3.4 Generating Acks During Slow Start in slow start
By injection additional response (the first response [Ack-first-segment] or slow start-up process [Ack-every-segment-during-start]) mitigation can only be used during the slow start phase of the connection . After the initial exchange, the connection usually ends slowly, TCP will only inject additional answers when the following cases: (1) connection is closed, the new connection is opened;
(2) The TCP process restarts the idle connection due to slow start.
Among them, the first is to use on HTTP / 1.0, and a new connection is required for each request response. The stable connection in HTTP / 1.1 helps keep the connection in the case of clogging, rather than replying to slow start. As a result, such optimizations can only be activated in slow start-up phase. As for the second, it is obvious that it is independent of the version of HTTP.
4.4 Ack Spacing (ACK SPACIN)
During the slow start, the sender responds to the upcoming response stream by transmitting N 1 segments for each response, where n is the number of new sections recognized by the upcoming response signal. This will cause data to be transmitted twice on the network. Correspondingly, a queue will also generate a bottleneck at the router due to lack of buffer, resulting in packet loss due to insufficient connection capability.
Montenegro, et al. Informational [Page 17]
The interval of increasing responses can effectively control the transmission rate of the sender on the network, and a small queue can be formed at a bottleneck router [Ackspacing], in addition, the response spacing also reduces the size of the short pulse string.
Suggestion: There is currently no suggestions, please continue to pay attention to the research in this area.
4.5 Repeat Answer Delay (Delayed Duplicate Acknowlements)
As mentioned above, most packet loss is caused by congestion. Link layer relay may greatly reduce the bitmap rate, but it is still no access to interruptions caused by switching networks or exceeding wireless coverage. Because the link layer and the TCP layer copies each other's function, there must be a relay between the link layer and the TCP layer, which can cause the TCP to generate a delay, thereby creating conditions for the recovery of the link layer. Based on this idea, in the Delay Copy Pack (DELAYED DUPACKS, [MV97, VAIDYA99]) scheme, the recipient is selectively delayed repetitive confirmation. The ideal way is to let local mechanisms to solve local problems without having to call TCP-to-End-to-End mechanisms, thereby reducing the cost of bandwidth waste.
Since the intermediate media node does not need to check the TCP header, the delay copy package can be used for IP encryption.
Usually, it is very well understood that the recipient delay is repeated. In special cases, when the Wireless Medium Access Control, Mac is selected when selecting a delay parameter. The MAC protocol may affect the ability to choose the appropriate delay (static or dynamic). Typically, important changes occurred during the link level relay will have a negative impact on the performance of the delay replication scheme. Moreover, in subsequent chapters (4.10.3), it also pointed out that delay replication and other programs (such as listening - Snoop, [snoop]) are only beneficial to a particular type of network connection.
Recommendation: Delay repetition confirmation may be useful for some specific network topologies, but as a general recommendation, more research and experiments are required. 4.6 Selective Answer (Selective Acknowledgements) [RFC2018]
According to the statement in [TCPHP] 1.1, the selective response (SACK) may not be suitable for many LTN networks. Under the LFN system, since the large window is used, and each window will have a considerable chance to lose multiple sections, Sack is useful.
Montenegro, et al. Informational [Page 18]
In the LTN system, the TCP window is much smaller, in order to destroy the repetition segment, the pulse error (Burst ErrorS) must last longer.
Correspondingly, the complexity of SACK may not be adjusted unless the pulse error on the wireless connection (Burst ErrorS) or congestion is higher. In short, providing TCP compatibility voices for non-LTN environments will force the LTN to support SACK.
[AGS98] It is recommended to use Sack with large TCP windows in satellite environments. Note that this suggests that PAWS (Protection Against Wrapped Sequence Space) and Round Trip Time Measurement are supported.
Berkeley pointed out in the study of the listening protocol (Snoop, [Snoop]), selective confirmation (SACK) does not increase the listening throughput when each window is lost [BPSK96]. Even if multiple sections are lost within a round-trip cycle, Sack can still allow listening recovery. Therefore, mobile devices need to implement this type of selectivity confirmation. If selective confirmation is not used, TCP spends more time spent in congestion avoidance than relay.
Suggestion: Sack should be implemented immediately in order to maintain compatibility with other TCPs and improve SNOOP performance.
4.7 Detecting bad bag losses (Detecting Corruption LOSS)
4.7.1 Non-explicit notification (WITHOUT EXPLICIT NOTIFICATION)
Since there is no obvious prompt from the network, some R & D perspectives suggest to use statistical methods to solve the congestion avoidance [Jain89, WC91, VEGAS]. Naturally, these explorations will help send the sender to distinguish the packet loss due to congestion or other reasons. Research results based on the reliability of sending ends are not ideal [BV97, BV98]. [BV98A] In the control environment, the number of times the package inside the package is measured, and the result is slightly better, but there are too many delay factors, such as battery switching in the wireless environment, etc., which makes the exploration process encountered frustration.
Suggestion: There is no suggestion at this time, please continue to pay attention to the results of the latest research.
Montenegro, et al. Informational [Page 19]
4.7.2 Explicit Notification (with explicit notifications)
Since the explicit notification can be obtained from the network, it can be confirmed whether the packet loss is caused by congestion. There are several suggestions:
- Explicit packet loss notification (Explicit Loss Notification, Eln [bpsk96])
- Explicit Bad State Notification, EBSN [BBKVP96]) - Explicit Loss Notification To The Receiver, Elnr and Explicit Delay Copy Package Activation Notification (Explicit Delayed Dupack) Activation Notification, Eddan, ie the notification of the mobile receiver [mv97]
- Explicit Congestion Notification, ECN [ECN]
In the above recommendations, Explicit Congestion Notification (ECN) seems to be closest to the configuration on the Internet, providing some good features for TCP connections (or all other types of TCP connections) in remote narrow-tape networks.
Suggestion: There is no suggestion. Already listed, as future studies have ELNR and EDDAN [MV97], both notices only need to modify the intermediate media nodes and systems for mobile devices. However, this solution has some limitations because the intermediate node must also interpret the TCP header, which means that the payload portion of IP cannot be encrypted.
ECN uses TOS bytes in the IP header to load congestion information (ECN support and generating congestion, ECN-Capable and Congestion-Encountered). This byte is not encrypted with IPsec, so ECN can be used to encrypt in the TCP connection using IPSec mode.
Recommendation: Implement ECN. Otherwise, it is also necessary to establish a corresponding explicit error notification and tracking mechanism.
Note: Some of the information provided by ECN helps to avoid further deterioration, but for wireless applications, there is still certain limitations. TCP connections supported by ECN (ECN-CAPABLE) should not explain the packets that are not marked ECN, which actively provides relatives, reverse, during extreme network congestion, the router may drop due to their buffers An information package containing an explicit notification mark, which is accurately, is Retransmitting Aggressively, which starts active in the error at the time.
Montenegro, et al. Informational [Page 20]
