协议分析网

　　RFC2246] or SOCKS [RFC1928], should be employed for end-to-end security. - Another drawback of breaking end-to-end semantics is that crashes of the intermediate node become unrecoverable resulting in termination of the TCP connections. Whether this should be considered a severe problem depends on the expected frequency of such crashes. - In many occasions claims have been stated that if TCP end-to-end semantics is broken, applications relying on TCP to provide reliable data delivery become more vulnerable. This, however, is an overstatement as a well-designed application should never fully rely on TCP in achieving end-to-end reliability at the application level. First, current APIs to TCP, such as the Berkeley socket interface, do not allow applications to know when an TCP acknowledgement for previously sent user data arrives at TCP sender. Second, even if the application is informed of the TCP acknowledgements, the sending application cannot know whether the receiving application has received the data: it only knows that the data reached the TCP receive buffer at the receiving end. Finally, in order to achieve end-to-end reliability at the application level an application level acknowledgement is required to confirm that the receiver has taken the appropriate actions on the data it received. - When a mobile device moves, it is subject to handovers by the serving base station. If the base station acts as the intermediate node for the split TCP connection, the state of both TCP endpoints on the previous intermediate node must be transferred to the new intermediate node to ensure continued operation over the split TCP connection. This requires extra work and causes overhead. However, in most of the W-WAN wireless networks, unlike in W-LANs, the W- WAN base station does not provide the mobile device with the connection point to the wireline Internet (such base stations may not even have an IP stack). Instead, the W-WAN network takes care of the mobility and retains the connection point to the wireline Internet unchanged while the mobile device moves. Thus, TCP state handover is not required in most W-WANs. - The packets traversing through all the protocol layers up to transport layer and again down to the link layer result in extra overhead at the intermediate node. In case of LTNs with low bandwidth, this extra overhead does not cause serious additional performance problems unlike with W-LANs that typically have much higher bandwidth. - Split TCP proposals are not applicable to networks with asymmetric routing. Deploying a split TCP approach requires that traffic to and from the mobile device be routed through the intermediate node. With some networks, this cannot be accomplished, or it requires that the intermediate node is located several hops away from the wireless network edge which in turn is unpractical in many cases and may result in non-optimal routing. - Split TCP, as the name implies, does not address problems related to UDP. It should noted that using split TCP does not necessarily exclude simultaneous usage of IP for end-to-end connectivity. Correct usage of split TCP should be managed per application or per connection and should be under the end-user control so that the user can decide whether a particular TCP connection or application makes use of split TCP or whether it operates end-to-end directly over IP. Recommendation: Split TCP proposals that alter TCP semantics are not recommended. Deploying custom protocols on the wireless link, such as MOWGLI proposes is not recommended, because this note gives preference to (1) improving TCP instead of designing a custom protocol and (2) allowing end-to-end sessions at all times. 4.10.2 Application Level Proxies Nowadays, application level proxies are widely used in the Internet. Such proxies include Web proxy caches, relay MTAs (Mail Transfer Agents), and secure transport proxies (e.g., SOCKS). In effect, employing an application level proxy results in a "split TCP connection" with the proxy as the intermediary. Hence, some of the problems present with wireless links, such as combining of a congested wide-area Internet path with a wireless LTN link, are automatically alleviated to some extent. The application protocols often employ plenty of (unnecessary) round trips, lots of headers and inefficient encoding. Even unnecessary data may get delivered over the wireless link in regular application protocol operation. In many cases a significant amount of this overhead can be reduced by simply running an application level proxy on the intermediate node. With LTN links, significant additional improvement can be achieved by introducing application level proxies with application-specific enhancements. Such a proxy may employ an enhanced version of the application protocol over the wireless link. In an LTN environment enhancements at the application layer may provide much more notable performance improvements than any transport level enhancements. The Mowgli system provides full support for adding application level agent-proxy pairs between the client and the server, the agent on the mobile device and the proxy on the intermediate node. Such a pair may be either explicit or fully transparent to the applications, but it is, at all times, under the end-user control. Good examples of enhancements achieved with application-specific proxies include Mowgli WWW [LAKLR95], [LHKR96] and WebExpress [HL96], [CTCSM97]. Recommendation: Usage of application level proxies is conditionally recommended: an application must be proxy enabled and the decision of employing a proxy for an application must be under the user control at all times. 4.10.3 Snoop and its Derivatives Berkeley's SNOOP protocol [SNOOP] is a hybrid scheme mixing link- layer reliability mechanisms with the split connection approach. It is an improvement over split TCP approaches in that end-to-end semantics are retained. SNOOP does two things: 1. Locally (on the wireless link) retransmit lost packets, instead of allowing TCP to do so end-to-end. 2. Suppress the duplicate acks on their way from the receiver back to the sender, thus avoiding fast retransmit and congestion avoidance at the latter. Thus, the Snoop protocol is designed to avoid unnecessary fast retransmits by the TCP sender, when the wireless link layer retransmits a packet locally. Consider a system that does not use the Snoop agent. Consider a TCP sender S that sends packets to receiver R via an intermediate node IN. Assume that the sender sends packet A, B, C, D, E (in that order) which are forwarded by IN to the wireless receiver R. Assume that the intermediate node then retransmits B subsequently, because the first transmission of packet B is lost due to errors on the wireless link. In this case, receiver R receives packets A, C, D, E and B (in that order). Receipt of packets C, D and E triggers duplicate acknowledgements. When the TCP sender receives three duplicate acknowledgements, it triggers fast retransmit (which results in a retransmission, as well as reduction of congestion window). The fast retransmit occurs despite the link level retransmit on the wireless link, degrading throughput. SNOOP [SNOOP] deals with this problem by dropping TCP dupacks appropriately (at the intermediate node). The Delayed Dupacks (see section 4.5) attempts to approximate Snoop without requiring modifications at the intermediate node. Such schemes are needed only if the possibility of a fast retransmit due to wireless errors is non-negligible. In particular, if the wireless link uses a stop-and- go protocol (or otherwise delivers packets in-order), then these schemes are not very beneficial. Also, if the bandwidth-delay product of the wireless link is smaller than four segments, the probability that the intermediate node will have an opportunity to send three new packets before a lost packet is retransmitted is small. Since at least three dupacks are needed to trigger a fast retransmit, with a wireless bandwidth-delay product less than four packets, schemes such as Snoop and Delayed Dupacks would not be necessary (unless the link layer is not designed properly). Conversely, when the wireless bandwidth-delay product is large enough, Snoop can provide significant performance improvement (compared with standard TCP). For further discussion on these topics, please refer to [Vaidya99]. The Delayed Dupacks scheme tends to provide performance benefit in environments where Snoop performs well. In general, performance improvement achieved by the Delayed Dupacks scheme is a function of packet loss rates due to congestion and transmission errors. When congestion-related losses occur, the Delayed Dupacks scheme unnecessarily delays retransmission. Thus, in the presence of congestion losses, the Delayed Dupacks scheme cannot achieve the same performance improvement as Snoop. However, simulation results [Vaidya99] indicate that the Delayed Dupacks can achieve a significant improvement in performance despite moderate congestion losses. WTCP [WTCP] is similar to SNOOP in that it preserves end-to-end semantics. In WTCP, the intermediate node uses a complex scheme to hide the time it spends recovering from local errors across the wireless link (this typically includes retransmissions due to error recovery, but may also include time spent dealing with congestion). The idea is for the sender to derive a smooth estimate of round-trip time. In order to work effectively, it assumes that the TCP endpoints implement the Timestamps option in RFC1323 [TCPHP]. Unfortunately, support for RFC1323 in TCP implementations is not yet widespread. Beyond this, WTCP requires changes only at the intermediate node. SNOOP and WTCP require the intermediate node to examine and operate on the traffic between the portable wireless device and the TCP server on the wired Internet. SNOOP and WTCP do not work if the IP traffic is encrypted, unless, of course, the intermediate node shares the security association between the mobile device and its end-to-end peer. They also require that both the data and the corresponding ACKs traverse the same intermediate node. Furthermore, if the intermediate node retransmits packets at the transport layer across the wireless link, this may duplicate efforts by the link-layer. SNOOP has been described by its designers as a TCP-aware link-layer. This is the right approach: the link and network layers can be much more aware of each other than traditional OSI layering suggests. Encryption of IP packets via IPSEC's ESP header (in either transport or tunnel mode) renders the TCP header and payload unintelligible to the intermediate node. This precludes SNOOP (and WTCP) from working, because it needs to examine the TCP headers in both directions. Possible solutions involve: - making the SNOOP (or WTCP) intermediate node a party to the security association between the client and the server - IPSEC tunneling mode, terminated at the SNOOPing intermediate node However, these techniques require that users trust intermediate nodes. Users valuing both privacy and performance should use SSL or SOCKS for end-to-end security. These, however, are implemented above the transport layer, and are not as resistant to some security attacks (for example, those based on guessing TCP sequence numbers) as IPSEC. Recommendation: Implement SNOOP on intermediate nodes now. Research results are encouraging, and it is an "invisible" optimization in that neither the client nor the server needs to change, only the intermediate node (for basic SNOOP without SACK). However, as discussed above there is little or no benefit from implementing SNOOP if: 1. The wireless link provides reliable, in-order packet delivery, or, 2. The bandwidth-delay product of the wireless link is smaller than four segments. 4.10.4 PEPs to handle Periods of Disconnection Periods of disconnection are very common in wireless networks, either during handoff, due to lack of resources (dropped connections) or natural obstacles. During these periods, a TCP sender does not receive the expected acknowledgements. Upon expiration of the retransmit timer, this causes TCP to close its congestion window with all the related drawbacks. Re-transmitting packets is useless since the connection is broken. [M-TCP] aims at enabling TCP to better handle handoffs and periods of disconnection, while preserving end-to-end semantics. M-TCP adds an element: supervisor host (SH- TCP) at the edge of the wireless network. This intermediate node monitors the traffic coming from the sender to the mobile device. It does not break end-to-end semantics because the ACKs sent from the intermediate node to the sender are effectively the ones sent by the mobile node. The principle is to generally leave the last byte unacknowledged. Hence, SH-TCP could shut down the sender's window by sending the ACK for the last byte with a window set to zero. Thus the sender will go to persist mode. The second optimization is done on both the intermediate node and the mobile host. On the latter, TCP is aware of the current state of the connection. In the event of a disconnection, it is capable of freezing all timers. Upon reconnection, the mobile sends a specially marked ACK with the number of the highest byte received. The intermediate node assumes that the mobile is disconnected because it monitors the flow on the wireless link, so in the absence of acknowledgments from the mobile, it will inform SH-TCP, which will send the ACK closing the sender window as described in the previous paragraph. The intermediate node learns that the mobile is again connected when it receives a duplicate acknowledgment marked as reconnected. At this point it sends a duplicate ACK to the sender and grows the window. The sender exits persist mode and resumes transmitting at the same rate as before. It begins by retransmitting any data previously unacknowledged by the mobile node. Non overlapping or non soft handoffs are lightweight because the previous intermediate system can shrink the window, and the new one modifies it as soon as it has received an indication from the mobile. Recommendation: M-TCP is not slated for adoption at this moment, because of the highly experimental nature of the proposal, and the uncertainty that TCP/IP implementations handle zero window updates correctly. Continue tracking developments in this space. 4.11 Header Compression Alternatives Because Long Thin Networks are bandwidth-constrained, compressing every byte out of over-the-air segments is worth while. Mechanisms for TCP and IP header compression defined in [RFC1144, IPHC, IPHC-RTP, IPHC-PPP] provide the following benefits: - Improve interactive response time - Allow using small packets for bulk data with good line efficiency - Allow using small packets for delay sensitive low data-rate traffic - Decrease header overhead (for a common TCP segment size of 512 the header overhead of IPv4/TCP within a Mobile IP tunnel can decrease from 11.7 to less than 1 per cent. - Reduce packet loss rate over lossy links (because of the smaller cross-section of compressed packets). Van Jacobson (VJ) header compression [RFC1144] describes a Proposed Standard for TCP Header compression that is widely deployed. It uses TCP timeouts to detect a loss of synchronization between the compressor and decompressor. [IPHC] includes an explicit request for transmission of uncompressed headers to allow resynchronization without waiting for a TCP timeout (and executing congestion avoidance procedures). Recommendation: Implement [IPHC], in particular as it relates to IP- in-IP [RFC2003] and Minimal Encapsulation [RFC2004] for Mobile IP, as well as TCP header compression for lossy links and links that reorder packets. PPP capable devices should implement [IPHC-PPP]. VJ header compression may optionally be implemented as it is a widely deployed Proposed Standard. However, it should only be enabled when operating over reliable LTNs, because even a single bit error most probably would result in a full TCP window being dropped, followed by a costly recovery via slow-start. 4.12 Payload Compression Compression of IP payloads is also desirable. "IP Payload Compression Protocol (IPComp)" [IPPCP] defines a framework where common compression algorithms can be applied to arbitrary IP segment payloads. IP payload compression is something of a niche optimization. It is necessary because IP-level security converts IP payloads to random bitstreams, defeating commonly-deployed link-layer compression mechanisms which are faced with payloads that have no redundant "information" that can be more compactly represented. However, many IP payloads are already compressed (images, audio, video, "zipped" files being FTPed), or are already encrypted above the IP layer (SSL/TLS, etc.). These payloads will not "compress" further, limiting the benefit of this optimization. HTTP/1.1 already supports compression of the message body. For example, to use zlib compression the relevant directives are: "Content-Encoding: deflate" and "Accept-Encoding: deflate" [HTTP- PERF]. HTTP-NG is considering supporting compression of resources at the HTTP level, which would provide equivalent benefits for common compressible MIME types like text/html. This will reduce the need for IPComp. If IPComp is deployed more rapidly than HTTP-NG, IPComp compression of HTML and MIME headers would be beneficial. In general, application-level compression can often outperform IPComp, because of the opportunity to use compression dictionaries based on knowledge of the specific data being compressed. Recommendation: IPComp may optionally be implemented. Track HTTP-NG standardization and deployment for now. Implementing HTTP/1.1 compression using zlib SHOULD is recommended. 4.13 TCP Control Block Interdependence [Touch97] TCP maintains per-connection information such as connection state, current round-trip time, congestion control or maximum segment size. Sharing information between two consecutive connections or when creating a new connection while the first is still active to the same host may improve performance of the latter connection. The principle could easily be extended to sharing information amongst systems in a LAN not just within a given system. [Touch97] describes cache update for both cases. Users of W-WAN devices frequently request connections to the same servers or set of servers. For example, in order to read their email or to initiate connections to other servers, the devices may be configured to always use the same email server or WWW proxy. The main advantage of this proposal is that it relieves the application of the burden of optimizing the transport layer. In order to improve the performance of TCP connections, this mechanism only requires changes at the wireless device. In general, this scheme should improve the dynamism of connection setup without increasing the cost of the implementation. Recommendation: This mechanism is recommended, although HTTP/1.1 with its persistent connections may partially achieve the same effect without it. Other applications (even HTTP/1.0) may find it useful. Continue monitoring research on this. In particular, work on a "Congestion Manager" [CM] may generalize this concept of sharing information among protocols and applications with a view to making them more adaptable to network conditions. 5 Summary of Recommended Optimizations The table below summarizes our recommendations with regards to the main proposals mentioned above. The first column, "Stability of the Proposal," refers to the maturity of the mechanism in question. Some proposals are being pursued within the IETF in a somewhat open fashion. An IETF proposal is either an Internet Drafts (I-D) or a Request for Comments (RFC). The former is a preliminary version. There are several types of RFCs. A Draft Standards (DS) is standards track, and carries more weight than a Proposed Standard (PS), which may still undergo revisions. Informational or Experimental RFCs do not specify a standard. Other proposals are isolated efforts with little or no public review, and unknown chances of garnering industry backing. "Implemented at" indicates which participant in a TCP session must be modified to implement the proposal. Legacy servers typically cannot be modified, so this column indicates whether implementation happens at either or both of the two nodes under some control: mobile device and intermediate node. The symbols used are: WS (wireless sender, that is, the mobile device's TCP send operation must be modified), WR (wireless receiver, that is, the mobile device's TCP receive operation must be modified), WD (wireless device, that is, modifications at the mobile device are not specific to either TCP send or receive), IN (intermediate node) and NI (network infrastructure). These entities are to be understood within the context of Section 1.1 ("Network Architecture"). NA simply means "not applicable." The "Recommendation" column captures our suggestions. Some mechanisms are endorsed for immediate adoption, others need more evidence and research, and others are not recommended. Name Stability of Implemented Recommendation the Proposal at ==================== ============= =========== ================= Increased Initial RFC2581 (PS) WS Yes Window (initial_window=2) Disable delayed ACKs NA WR When stable during slow start Byte counting NA WS No instead of ACK counting TCP Header RFC1144 (PS) WD Yes compression for PPP IN (see 4.11) IP Payload RFC2393 (PS) WD Yes Compression (simultaneously (IPComp) needed on Server) Header RFC2507 (PS), WD Yes Compression RFC2509 (PS) IN (For IPv4, TCP and Mobile IP, PPP) SNOOP plus SACK In limited use IN Yes WD (for SACK) Fast retransmit/fast RFC2581 (PS) WD Yes (should be recovery there already) Transaction/TCP RFC1644 WD No (Experimental) (simultaneously needed on Server) Estimating Slow NA WS No Start Threshold (ssthresh) Delayed Duplicate Not stable WR When stable Acknowledgements IN (for notifications) Class-based Queuing NA WD When stable on End Systems Explicit Congestion RFC2481 (EXP) WD Yes Notification NI TCP Control Block RFC2140 WD Yes Interdependence (Informational) (Track research) Of all the optimizations in the table above, only SNOOP plus SACK and Delayed duplicate acknowledgements are currently being proposed only for wireless networks. The others are being considered even for non- wireless applications. Their more general applicability attracts more attention and analysis from the research community. Of the above mechanisms, only Header Compression (for IP and TCP) and "SNOOP plus SACK" cease to work in the presence of IPSec. 6 Conclusion In view of the unpredictable and problematic nature of long thin networks, arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks (LTNs). 7 Acknowledgements The authors are deeply indebted to the IETF tcpsat and tcpimpl working groups. The following individuals have also provided valuable feedback: Mark Allman (NASA), Vern Paxson (ACIRI), Raphi Rom (Technion/Sun), Charlie Perkins (Nokia), Peter Stark (Phone.com). 8 Security Considerations The mechanisms discussed and recommended in this document have been proposed in previous publications. The security considerations outlined in the original discussions apply here as well. Several security issues are also discussed throughout this document. Additionally, we present below a non-exhaustive list of the most salient issues concerning our recommended mechanisms: - Larger Initial TCP Window Size No known security issues [RFC2414, RFC2581]. - Header Compression May be open to some denial of service attacks. But any attacker in a position to launch these attacks would have much stronger attacks at his disposal [IPHC, IPHC-RTP]. - Congestion Control, Fast Retransmit/Fast Recovery An attacker may force TCP connections to grind to a halt, or, more dangerously, behave more aggressively. The latter possibility may lead to congestion collapse, at least in some regions of the network [RFC2581]. - Explicit Congestion Notification It does not appear to increase the vulnerabilities in the network. On the contrary, it may reduce them by aiding in the identification of flows unresponsive to or non-compliant with TCP congestion control [ECN]. - Sharing of Network Performance Information (TCP Control Block Sharing and Congestion Manager module) Some information should not be shared. For example, TCP sequence numbers are used to protect against spoofing attacks. Even limiting the sharing to performance values leaves open the possibility of denial-of-service attacks [Touch97]. - Performance Enhancing Proxies These systems are men-in-the-middle from the point of view of their security vulnerabilities. Accordingly, they must be used with extreme care so as to prevent their being hijacked and misused. This last point is not to be underestimated: there is a general security concern whenever an intermediate node performs operations different from those carried out in an end-to-end basis. This is not specific to performance-enhancing proxies. In particular, there may be a tendency to forego IPSEC-based privacy in order to allow, for example, a SNOOP module, header compression (TCP, UDP, RTP, etc), or HTTP proxies to work. Adding end-to-end security at higher layers (for example via RTP encryption, or via TLS encryption of the TCP payload) alleviates the problem. However, this still leaves protocol headers in the clear, and these may be exploited for traffic analysis and denial-of-service attacks. 9 References [ACKSPACING] Partridge, C., "ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering", Work in Progress. [ADGGHOSSTT98] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, T., Heidemann, J., Kruse, H., Osterman, S., Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research Related to Satellites", Work in Progress. [AGS98] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC2488, January 1999. [Allman98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998. [AHO98] Allman, M., Hayes, C., Ostermann, S., "An Evaluation of TCP with Larger Initial Windows," Computer Communication Review, 28(3), July 1998. [BBKT96] Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi, S., "Enhancing Throughput over Wireless LANs Using Channel State Dependent Packet Scheduling," in Proc. IEEE INFOCOM'96, pp. 1133-40, March 1996. [BBKVP96] Bakshi, B., P., Krishna, N., Vaidya, N., Pradhan, D.K., "Improving Performance of TCP over Wireless Networks," Technical Report 96-014, Texas A&M University, 1996. [BPSK96] Balakrishnan, H., Padmanabhan, V., Seshan, S., Katz, R., "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links," in ACM SIGCOMM, Stanford, California, August 1996. [BPK99] Balakrishnan, H., Padmanabhan, V., Katz, R., "The effects of asymmetry on TCP performance," ACM Mobile Networks and Applications (MONET), Vol. 4, No. 3, 1999, pp. 219-241. [BV97] S. Biaz and N. H. Vaidya, "Distinguishing Congestion Losses from Wireless Transmission Losses: A Negative Result," Seventh International Conference on Computer Communications and Networks (IC3N), New Orleans, October 1998. [BV98] Biaz, S., Vaidya, N., "Sender-Based heuristics for Distinguishing Congestion Losses from Wireless Transmission Losses," Texas A&M University, Technical Report 98-013, June 1998. [BV98a] Biaz, S., Vaidya, N., "Discriminating Congestion Losses from Wireless Losses using Inter-Arrival Times at the Receiver," Texas A&M University, Technical Report 98-014, June 1998. [BW97] Brasche, G., Walke, B., "Concepts, Services, and Protocols of the New GSM Phase 2+ general Packet Radio Service," IEEE Communications Magazine, Vol. 35, No. 8, August 1997. [CB96] Cheshire, S., Baker, M., "Experiences with a Wireless Network in MosquitoNet," IEEE Micro, February 1996. Available online as: http://rescomp.stanford.edu/~cheshire/papers /wireless.ps. [CDMA] Electronic Industry Alliance(EIA)/Telecommunications Industry Association (TIA), IS-95: Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System, 1993. [CDPD] Wireless Data Forum, CDPD System Specification, Release 1.1, 1995. [CM] Hari Balakrishnan and Srinivasan Seshan, "The Congestion Manager," Work in Progress. [CTCSM97] Chang, H., Tait, C., Cohen, N., Shapiro, M., Mastrianni, S., Floyd, R., Housel, B., Lindquist, D., "Web Browsing in a Wireless Environment: Disconnected and Asynchronous Operation in ARTour Web Express," in Proc. MobiCom'97, Budapest, Hungary, September 1997. [Demers90] Demers, A., Keshav, S., and Shenker, S., Analysis and Simulation of a Fair Queueing Algorithm, Internetworking: Research and Experience, Vol. 1, 1990, pp. 3-26. [ECN] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999. [Floyd95] Floyd, S., and Jacobson, V., Link-sharing and Resource Management Models for Packet Networks. IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995. [FSS98] Fragouli, C., Sivaraman, V., Srivastava, M., "Controlled Multimedia Wireless Link Sharing via Enhanced Class-Based Queueing with Channel-State- Dependent Packet Scheduling," Proc. IEEE INFOCOM'98, April 1998. [GPRS] ETSI, "General Packet Radio Service (GPRS): Service Description, Stage 2," GSM03.60, v.6.1.1 August 1998. [GSM] Rahnema, M., "Overview of the GSM system and protocol architecture," IEEE Communications Magazine, vol. 31, pp 92-100, April 1993. [HL96] Hausel, B., Lindquist, D., "WebExpress: A System for Optimizing Web Browsing in a Wireless Environment," in Proc. MobiCom'96, Rye, New York, USA, November 1996. [HTTP-PERF] Henrik Frystyk Nielsen (W3C, MIT), Jim Gettys (W3C, Digital), Anselm Baird-Smith (W3C, INRIA), Eric Prud'hommeaux (W3C, MIT), Hon Lie (W3C, INRIA), Chris Lilley (W3C, INRIA), "Network Performance Effects of HTTP/1.1, CSS1, and PNG," ACM SIGCOMM '97, Cannes, France, September 1997. Available at: http://www.w3.org/Protocols/HTTP/Performance /Pipeline.html [IPPCP] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC2393, December 1998. [IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC2507, February 1999. [IPHC-RTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC2508, February 1999. [IPHC-PPP] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC2509, February 1999. [ITCP] Bakre, A., Badrinath, B.R., "Handoff and Systems Support for Indirect TCP/IP. In Proceedings of the Second USENIX Symposium on Mobile and Location- Independent Computing, Ann Arbor, Michigan, April 10- 11, 1995. [Jain89] Jain, R., "A Delay-Based Approach for Congestion Avoidance in Interconnected Heterogeneous Computer Networks," Digital Equipment Corporation, Technical Report DEC-TR-566, April 1989. [Karn93] Karn, P., "The Qualcomm CDMA Digital Cellular System" Proc. USENIX Mobile and Location-Independent Computing Symposium, USENIX Association, August 1993. [KRLKA97] Kojo, M., Raatikainen, K., Liljeberg, M., Kiiskinen, J., Alanko, T., "An Efficient Transport Service for Slow Wireless Telephone Links," in IEEE Journal on Selected Areas of Communication, volume 15, number 7, September 1997. [LAKLR95] Liljeberg, M., Alanko, T., Kojo, M., Laamanen, H., Raatikainen, K., "Optimizing World-Wide Web for Weakly-Connected Mobile Workstations: An Indirect Approach," in Proc. 2nd Int. Workshop on Services in Distributed and Networked Environments, Whistler, Canada, pp. 132-139, June 1995. [LHKR96] Liljeberg, M., Helin, H., Kojo, M., Raatikainen, K., "Mowgli WWW Software: Improved Usability of WWW in Mobile WAN Environments," in Proc. IEEE Global Internet 1996 Conference, London, UK, November 1996. [LS98] Lettieri, P., Srivastava, M., "Adaptive Frame Length Control for Improving Wireless Link Throughput, Range, and Energy Efficiency," Proc. IEEE INFOCOM'98, April 1998. [MNCP] Piscitello, D., Phifer, L., Wang, Y., Hovey, R., "Mobile Network Computing Protocol (MNCP)", Work in Progress. [MOWGLI] Kojo, M., Raatikainen, K., Alanko, T., "Connecting Mobile Workstations to the Internet over a Digital Cellular Telephone Network," in Proc. Workshop on Mobile and Wireless Information Systems (MOBIDATA), Rutgers University, NJ, November 1994. Available at: http://www.cs.Helsinki.FI/research/mowgli/. Revised version published in Mobile Computing, pp. 253-270, Kluwer, 1996. [MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm," in Computer Communications Review, a publication of ACM SIGCOMM, volume 27, number 3, July 1997. [MTCP] Brown, K. Singh, S., "A Network Architecture for Mobile Computing," Proc. IEEE INFOCOM'96, pp. 1388- 1396, March 1996. Available at ftp://ftp.ece.orst.edu/pub/singh/papers /transport.ps.gz [M-TCP] Brown, K. Singh, S., "M-TCP: TCP for Mobile Cellular Networks," ACM Computer Communications Review Vol. 27(5), 1997. Available at ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz [MV97] Mehta, M., Vaidya, N., "Delayed Duplicate- Acknowledgements: A Proposal to Improve Performance of TCP on Wireless Links," Texas A&M University, December 24, 1997. Available at http://www.cs.tamu.edu/faculty/vaidya/mobile.html [NETBLT] White, J., "NETBLT (Network Block Transfer Protocol)", Work in Progress. [Paxson97] V. Paxson, "End-to-End Internet Packet Dynamics," Proc. SIGCOMM '97. Available at ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-sigcomm97.ps.Z [RED] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC2309, April 1998. [RLP] ETSI, "Radio Link Protocol for Data and Telematic Services on the Mobile Station - Base Station System (MS-BSS) interface and the Base Station System - Mobile Switching Center (BSS-MSC) interface," GSM Specification 04.22, Version 3.7.0, February 1992. [RFC908] Velten, D., Hinden, R. and J. Sax, "Reliable Data Protocol", RFC908, July 1984. [RFC1030] Lambert, M., "On Testing the NETBLT Protocol over Divers Networks", RFC1030, November 1987. [RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC1122, October 1989. [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low- Speed Serial Links", RFC1144, February 1990. [RFC1151] Partridge, C., Hinden, R., "Version 2 of the Reliable Data Protocol (RDP)", RFC1151, April 1990. [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [RFC1397] Braden, R., "Extending TCP for Transactions -- Concepts", RFC1397, November 1992. [RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC1644, July 1994. [RFC1661] Simpson, W., "The Point-To-Point Protocol (PPP)", STD 51, RFC1661, July 1994. [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC1928, March 1996. [RFC1986] Polites, W., Wollman, W., Woo, D. and R. Langan, "Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)", RFC1986, August 1996. [RFC2002] Perkins, C., "IP Mobility Support", RFC2002, October 1996. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC2003, October 1996. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC2018, October 1996. [RFC2188] Banan, M., Taylor, M. and J. Cheng, "AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2", RFC2188, September 1997. [RFC2246] Dierk, T. and E. Allen, "TLS Protocol Version 1", RFC 2246, January 1999. [RFC2414] Allman, M., Floyd, S. and C. Partridge. "Increasing TCP's Initial Window", RFC2414, September 1998. [RFC2415] Poduri, K.and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC2415, September 1998. [RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC2416, September 1998. [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC2581, April 1999. [RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC2582, April 1999. [SNOOP] Balakrishnan, H., Seshan, S., Amir, E., Katz, R., "Improving TCP/IP Performance over Wireless Networks," Proc. 1st ACM Conf. on Mobile Computing and Networking (Mobicom), Berkeley, CA, November 1995. [Stevens94] R. Stevens, "TCP/IP Illustrated, Volume 1," Addison- Wesley, 1994 (section 2.10 for MTU size considerations and section 11.3 for weak checksums). [TCPHP] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC1323, May 1992. [TCPSATMIN] TCPSAT Minutes, August, 1997. Available at: http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich- minutes.txt. [Touch97] Touch, T., "TCP Control Block Interdependence", RFC 2140, April 1997. [Vaidya99] N. H. Vaidya, M. Mehta, C. Perkins, G. Montenegro, "Delayed Duplicate Acknowledgements: A TCP-Unaware Approach to Improve Performance of TCP over Wireless," Technical Report 99-003, Computer Science Dept., Texas A&M University, February 1999. [VEGAS] Brakmo, L., O'Malley, S., "TCP Vegas, New Techniques for Congestion Detection and Avoidance," SIGCOMM'94, London, pp 24-35, October 1994. [VMTP] Cheriton, D., "VMTP: Versatile Message Transaction Protocol",