- ESRO [RFC2188]
- RDP [RFC908, RFC1151]
- VMTP [VMTP]
3 TCP protocol status (The Case for TCP)
This is the most intense problem in the wireless field, which lists several main objections:
- It is generally considered that TCP is not good enough in achieving no blockage loss. The opponents of TCP believe that it is convenient to repair TCP as a wireless medium. Bamboo
- TCP's header overhead is too large.
- is the timing of the stunning mechanism, the TCP protocol is really cumbersome, not suitable for light and movable equipment.
Of course, there are many views on TCP:
- From the perspective of compatibility, use the same protocol in the surplus field of the Internet, which is a perfect solution. Any wireless connection to expand specifications should be considered.
- Traditional mechanisms can be reused (for example: Three-Way Handshake, i.e., three-way handshake)
- The FEC and ARQ techniques of the link layer can reduce BER so that the main reason for the TCP packet is just a persistent interruption of clogging or network connection. Modern W-WAN Technology ((CDPD, US-TDMA, CDMA, GSM) has been done, greatly improves TCP throughput.
- You can achieve switching between different technologies by moving IP (Mobile IP [RFC2002]), but the same protocol is started from beginning to end, that is, TCP / IP protocol.
- If there are TCPs so rich research and development experience, which agreement will look relatively insufficient enough, this is not as widely understood as TCP applications.
All in all, we believe that the performance of TCP on the remote-narrowband network can also be significantly improved. In the subsequent chapter we will discuss its implementation mechanism.
Montenegro, et al. Informational [Page 11]
4 candidate optimizations (Candidate Optimization)
Optimizing TCP operations on wireless media also has a lot of work to do. Even if the satellite network is usually attributed to the LFN (remote obesity network) system, our current LTN (remote narrow-band network) can still benefit from it. For example, the work of the IETF's Satellite TCP Working Group provides great help for this section [AGS98, AdGghosstt98].
4.1 TCP: Current Mechanism (TCP: Current Mechanisms)
The TCP sender adjusts its use of the bandwidth based on the feedback signal of the recipient, and this adjustment is relatively slower than the network of other delayed networks due to the long wait time of the LTN network. Similarly, the latency confirmation (ACKS) is also not conducive to the estimation of the waiting time. Assume that TCP can increase the congestion window of the unit within its segment, a small amount of MTU may slow down this adjustment process.
4.1.1 Slow start and congestion avoidance (Slow Start and Congestion Avoidance)
Slow start and congestion to avoid the essence of [RFC2581] is the stability of the Internet. There are two reasons to explain the reverse effect of the wireless medium:
- As long as the TCP relay period is full, the sender will think that the network is crowded and calls slow start. As the TCP is desirable, the loss caused by the congestion is thrown, and the loss caused by the corruption is reduced as much as possible.
- The sender increases its window based on the received confirmation (ACKS) signal, of course, its arrival rate depends on the round trip cycle between the sender and the reception, which means that the long wait Time connection (like the LTN network), has a longer slope time (Ramp-Up), which will continue until the pipeline is filled. - During the slow start, the sender will increase the window of the unit in its segment, which is an important reason for this, that is, use the appropriate size MTU, and to reduce the loss of the link layer.
4.1.2 Fast Solids and Fast Recovery (Fast Retransmit and Fast Recovery)
When the TCP sender receives a repetitive confirmation (ACKS), fast completion will be inferred in a paragraph, so that the sender will re-send this package without waiting for timeout, saving time.
Montenegro, et al. Informational [Page 12]
After the trial, the sender will call the Quick Recovery [RFC2581] algorithm. Fast recovery allows the sender to avoid slow start by halving the transmission rate (increasing growth of the window) to avoid slowing.
Typically, in addition to bandwidth delay product, TCP can grow their windows. However, in the LTN connection, the plug window may remain very small, less than four, for a long time because of the following reasons:
1. Typically, through the size of the file delivered relatively small (such as web request, web file object, email message, file, etc.), especially the user of the LTN, in the case where the response time has long been , More reluctant to carry out the transmission of large-size files.
2. If the inclination rate is high (BER), the clogging window tends to stop in a small state.
3. When the LTN is combined with the highly blocked wired Internet inlet, the effect caused by the packet loss caused by the plug is similar to 2.
4. Typically, ISP / operators are small in their dial-up router (even less than 3 packages) in their dial-up router.
5. Typically, small Socket buffers are recommended in the LTN to avoid data expansion in real-time operations (RTO, Real Time Operation, and reduce the number of competitive transport packages.
The small window greatly hinders the benefits of the sender's use of fast relay, and the efficient recovery of multiple losses in a single window also needs to adopt new recommendations (NewReno [RFC2582]). In addition, on the slow channel without the order of weight, wait three repeated ACK confirmation signals to arrive, so that the delay relay is not necessary.
Recommendation: Realization of fast relay and fast recovery as soon as possible, is a common way to optimize implementation, but also the implementation of the high-end relay / fast recovery in the satellite environment recommended by the recommendation standard ([AGS98]). Obviously, NEWRENO [RFC2582] is also very helpful in the sender's local ACK confirmation signal and multiple losses in a single window, but is not recommended because of its experimental mechanism. As an alternative, Sack [RFC2018] is a mechanism for recommending. Montenegro, et al. Informational [Page 13]
4.2 Connection Settings Based on T / TCP [RFC1397, RFC1644] (Connection Setup with T / TCP [RFC1397, RFC1644])
TCP is a three-way handshake ("Three-Way Handshake") when the new connection is established, and only the data can be transmitted after this session is successful. The T / TCP allows the traffic to save the data in parallel while establishing a connection, thereby saving the operation time of small transactions.
Recommendation: T / TCP is not recommended, the reasons are as follows:
- It is experimental RFC.
- It is not very wide, and must be configured at both ends of the connection.
- From the perspective of security, T / TCP is more vulnerable to TCP itself to an attack of an address camouflage.
- Some good features of T / TCP (such as eliminating the three-way handshake process in concurrent procedures, query-response transaction processing, etc.) is also used by connectors on HTTP / 1.1, and the latter is more stable, applied The range is also more wide range.
There is no suggestion in the [AdggHOSSTT98] and does not make recommendations in the satellite environment.
4.3 Slow Start Suggestions (Slow Start ProPosals)
Interactive users can see the network response due to slow start in the TCP connection, so a large number of recommendations are proposed, and slow start in the environment for a long waiting time.
The stability of the Internet is extremely important, so these recommendations must be demonstrated that it does not have a negative impact on the clogging level of the Internet on important routes.
4.3.1 Large initialization window (Larger Initial Window)
The traditional slow start contains an initial window of a segment, which is a bandwidth modification scheme at the LTN. Due to the maximum support for TCP standards, the initialization window greater than one segment is still in the research phase [RFC2414, AHO98], as for higher value, essentially experimental.
Montenegro, et al. Informational [Page 14]
In [RFC2415], the simulation of adding three packets of the initialization window is described, but it does not provide a valid solution for the packet failure rate, but it still helps to start slowly at the end device (see next suggestion) Stage shorten the initial response time.
[RFC2416] The situation is the same as the status of the number of buffers available to the TCP protocol, and indicated that this condition is the same as the case where the clog window exceeds the number of buffers.
In [RFC2581], the initialization plug window of two segments is allowed. In the future, when the performance of LFN and LTN is greatly improved, a greater up to four initialization windows may occur.
Recommendation: This offer is immediately implemented on the device. Optimization studies have shown that 3 paragraphs are safe initialization settings, that is, in the three options in 2, 3, 4. Now, at least the client allows the client to obtain the initial ACK confirmation signal from the unmodified server, without a modified server, which is not a modified server, which is not a modified server. I took two round-trip processes. The future use of 3 sections [RFC2415] seems to be in the future research and experiments. 4.3.2 Increasing Windows during Slow Start (Growing The Window During Slow Start)
The sender can increase its window according to the ACK response signal flow returned from the receiver. Especially during slow start, this signal stream is very important. Two recommendations have been studied, one is the ACK response count, and the other is the ACK a response.
4.3.2.1 Ack Counting (ACK Counting)
The ACK response count is the main thinking:
- In accordance with the acquired data (by byte count), not the number of ACKs (ie, ACK Answer) to increase the window to make each ACK acknowledgment count to the most state, which will cause the information to cause clogging. [ALLMAN98] explains the Limited Byte Counting, LBC, that is, the window increase is limited to 2 segments that do not generate serious information expansion, thereby contributing to improve performance.
Recommendation: Do not use non-restricted bytes. Since the byte count will cause the information to expand, warning [TCPSATMIN] is proposed for this Van Jacobson, and it is recommended to use the answering interval ([Ackspacing]) as an alternative.
Montenegro, et al. Informational [Page 15]
