- Allows delay sensitive low-speed communication using packets.
- Reduce head load (the usual TCP segment size is 512). The headload of IPv4 / TCP in the mobile IP channel can be reduced from 11.7% to less than 1%.
- Reduce the loss of losses (because smaller compressed packs are used to interact).
The TCP header compression described in VAN Jacobson (VJ) header [RFC1144] is a wide range of applications that have been proposed. It uses TCP timeout to detect synchronous packets (LOSS) between compression squares and decompression. [IPhc] contains an explicit request to handle the TCP timeout (or enter the congestion avoidance program) when handling the non-compression head transfer.
Recommendation: Implementing [iPhc], especially because it is the minimum package of IP-in-IP [RFC2003] and mobile IP (Minimal Encapsulation [RFC2004]), and its connection to the losses connected TCP header compression and record packs also have relationship. Supported Device Device (PPP) devices should implement [iPhc-PPP]. VJ head compression can be achieved, because it is a wide application recommended standard. However, it should only be applied in a reliable LTN network operation because even a bit of errors can cause the entire TCP window to be turned off, and the cost of expensive slow start recovery will be triggered.
4.12 Payload Compression (PAYLOAD COMPRESSION)
The payload of the compressed IP is also a good solution. The IP Treated Load Compression Protocol (IP PayLoad Compression Protocol -ipComp, "IPPCP] defines a framework for any IP segment load. IP load compression is a suitable mode of optimization, in the IP level security system, it is necessary, because the security system converts IP load into random bitstream, so that the usual application link layer compression mechanism cannot be Get sufficient information, so that it cannot be processed.
However, many IP loads have been compressed (such as image, audio, video, and uploaded ZIP files, or have been added secrets (such as SSL / TLS, etc.) in the IP layer (such as SSL / TLS, etc.). These loads will not be compressed again, thus limiting the benefits of this optimization.
HTTP / 1.1 has supported the compression of Message Body. For example, the corresponding indication corresponding to the ZLIB compression is: "Content-Encoding: deflate" and "Accept-Encoding: deflate" [http-perf].
Montenegro, et al. Informational [Page 31]
HTTP-NG appears to support HTTP-level resource compression, which can provide corresponding support for some of the compressed MIME files such as Text / HTML, which reduces the need for IPComp. But if IPComp is faster than HTTP-NG configuration, it will be beneficial to compress HTML and MIME headers.
Typically, the application level compression will be better than IPComp, as they have the opportunity to use a compressed dictionary for specifying the compressed data.
Recommendation: IPComp can be selected. From now on, pay attention to the standardization and application of HTTP-NG now. It is recommended to use ZLIB to implement HTTP / 1.1 compression.
4.13 Internal dependence of TCP Control Block (TPCP Control Block Interdependence "TCP maintains information of each connection, such as connection status, current round-trip cycle, congestion control, or maximum segment size. The TCP can share information between two connections, or when maintaining an old connection with a host, the new connection to the host can improve performance. This principle can be easily expanded to the LAN system, not just a given system. [Touch97] describes cache update under both scenarios.
Users of W-WAN devices often request to connect to the same or same set of servers. For example, in order to read mail or initialization and other servers, these devices may be configured to always use the same Email server or WWW proxy server. The benefit of this recommendation is that it alleviates the burden on the application to optimize the transport layer. In order to improve the performance of the TCP connection, the mechanism only needs to be changed at the wireless device.
Generally, the program can improve the vitality of the connection equipment without increasing the cost of achieving the cost.
Recommendation: Although HTTP / 1.1 persistent stable connection may also play the same effect, this mechanism is still recommended. Other applications (even http / 1.0) will feel it is useful. Please continue to pay attention, especially in the "Congestion Manager, Congestion Manager [cm]" work, the manager will open the concept of sharing information between the agreement and the application, making it more suitable for the situation of the network. .
Montenegro, et al. Informational [Page 32]
5 Recommended Optimization Summary (Summary of Recommended Optimization)
The following table is a summary of the recommendations we are worthy of concern in the previously described.
The first column, "Stability of the Proposal] discusses the maturity of the mechanism. Some recommendations are tracked inside the IETF. The IETF is either an Internet draft (I-D) or is the request for Comments, RFCs, before the preparatory version. There are several types of RFC: Draft Standards (DS) is a standard tracking file, which contains more information than proposed standard (PS), which is still revised. Intelligence or experimental RFC cannot be considered standard. Other recommendations are too small or not known, and there is no chance to be isolated in practical applications.
"IMPLEMENTED AT" prompts what suggestions must modify the TCP session during the implementation process. The traditional server cannot be modified, so the column indicates whether it is to be implemented at two nodes, or only one, ie the mobile device and the intermediate media node. Used as follows: WS (wireless sender, Wireless Sender, that is, the mobile device TCP sending operation must be modified); WR (wireless receiver, Wireless Receiver, ie mobile device TCP receiver must be modified); WD (wireless device Wireless Device, that is, the modification at the mobile device does not indicate the TCP sender or receiver); in (Intermediate Media Node, Intermediate Node), and Ni (Network Construction, Infrastructure). The concept of these entities has been described in the 1.1 section (network structure) of the body. NA simply represents "Not Applicable). The "Recommendation" is written in our suggestion. Some mechanisms have been recognized; some mechanisms need to be argued and studied; some are not recommended.
Recommended Name (Name)
Suggested stability
(Stability of
The proposal
Realize
(Implement AT)
Whether the recommendation
(Recommendation)
Increased Initial
Window
RFC 2581 (PS)
WS
YES
(Initial_Window = 2)
Disable delayed
Acks during solution start
NA
WR
When Stable
Byte countryinginstead of
Ack country
NA
WS
NO
Montenegro, et al. Informational [Page 33]
(Continued on the page)
Recommended Name (Name)
Suggested stability
(Stability of
The proposal
Realize
(Implement AT)
Whether the recommendation
(Recommendation)
TCP Header
Compression for PPP
RFC 1144 (PS)
WD
In
YES
(See 4.11)
IP PayLoad Compression
(Ipcomp)
RFC 2393 (PS)
WD
(SIMULTAOUSLY
NEEDED ON Server
YES
HEADER
Compression
RFC 2507 (PS),
RFC 2509 (PS)
WD
In
YES
(For IPv4, TCP
And Mobile IP, PPP)
Snoop Plus Sack
IN LIMITED USE
In
WD (for Sack)
YES
Fast Retransmit / FAST
Recovery
RFC 2581 (PS)
WD
Yes (SHOULD BE
There already
TRANSACTION / TCP
RFC 1644
(Experimental)
WD
(Simultaneously
NEEDED ON Server
NO
Estimating Slow
Start Threshold (SSTHRESH)
NA
WS
NO
Delayed Duplicate
Acknowledgements
Not Stable
WR
For Notifications
When Stable
Class-based queuing
On End Systems
NA
WD
When Stable
Explicit Congestion
RFC 2481 (EXP)
WD
YES
Notification
Ni
TCP Control Block
Interdependence
RFC 2140
(Informational)
WD
Yes (Track Research)
The various optimizations described in the table above, only Snoop plus Sack and delay delayed DuPlicate Acknowledgement is currently used under wireless networks. Others are still in the discussion stage or even some not to use wireless applications. More availability will attract the attention and analysis of research groups.
In the above mechanism, only header compression, IP and TCP use) and "Snoop plus SACK" stopped using IPSEC.
Montenegro, et al. Informational [Page 34]
6 Conclusion
After reviewing the unpredictable and problematic characteristics of the remote narrow-band network, we know that optimizing its transmission is a daunting task. We also introduce the existing research. Based on this view, we also recommend the establishment of the implementation mechanism of the remote narrowband network (LTNS).
7 Thank Acknowledgements
The author is very grateful to the IETF TCPSAT and TCPIMPL Working Group. The following members also offer valuable comments:
Mark Allman (NASA), Vern Paxson (ACIRI), Raphi ROM (Technion / Sun),
Charlie Perkins (Nokia), Peter Stark (Phone.com).
8 Safety considerations (Security considity)
The mechanisms discussed and suggested in this paper are early announcement. The discussion of security in the original discussion is also listed here, and several of them have been discussed in this article, in addition, it will column with valuable issues related to our recommendation mechanism for reference:
- Larger initial window size (Larger Initial TCP Window Size)
Unknown security issues (NO KNOWN Security Issues "[RFC2414, RFC2581].
Header compression
May be subject to Denial of Service Attacks. But an attacker with an capable attack is needed to have a more controlled attack [IPHC, IPHC-RTP].
- Congestion Control, Express Control, Fast Retriation / Fast Recovery
Attackers may force TCP connections, or more serious, more aggressive behavior. The latter may lead to congestical collapse [RFC2581].
- Explicit Congestion Notification does not increase the network's resistance attack capabilities. Instead, it may reduce the ability of the network due to stream identifiers that generate response slows and congestion control [ECN] incompatible with TCP.
Montenegro, et al. Informational [Page 35]
