idnits 2.17.1 draft-pohlmann-http-traffic-satellite-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 189 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1997) is 9683 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 148 looks like a reference -- Missing reference section? '2' on line 151 looks like a reference -- Missing reference section? '3' on line 154 looks like a reference -- Missing reference section? '4' on line 160 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Robert Pohlmann 2 Expire in six months October 1997 4 HTTP Traffic over Satellite 5 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are 10 working documents of the Internet Engineering Task Force 11 (IETF), its areas, and its working groups. Note that other 12 groups may also distribute working documents as Internet 13 Drafts. 15 Internet-Drafts are draft documents valid for a maximum of 16 six months and may be updated, replaced, or obsoleted by 17 other documents at any time. It is inappropriate to use 18 Internet-Drafts as reference material or to cite them other 19 than as "work in progress." 21 To view the entire list of current Internet-Drafts, please 22 check the "lid-abstracts.txt" listing in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US 25 East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 Internet use over satellites (LEO, MEO and GEO) has not 30 received enough attention. Satellites have an inherent 31 broadcasting ability useful for transmitting Internet 32 traffic. They can send information to many locations 33 simultaneously depending on the coverage beam of the 34 satellite. The issue of Internet use over satellites needs 35 to be addressed so that future implementations of networking 36 protocols can be used with this medium. The vast majority 37 of Internet traffic is TCP traffic resulting from the HTTP 38 protocol so this issue will be addressed here. It is hoped 39 that this facilitates the transition from the use of 40 terrestial networks, to networks incorporating satellite 41 links. 43 Acknowledgements 45 The TCP algorithms that are mentioned were developed by Van 46 Jacobsen. An excellent explanation of their use is 47 described in [1]. 49 1. The Issues 51 Several issues arise when using satellites (LEO, MEO and 52 GEO) for information transmission. The delay, or latency, 53 of a satellite link (sender to receiver) is greater than a 54 terrestrial communications link. This varies depending on 55 the type of satellite. LEO satellites typically have a 56 latency on the order of 100 milliseconds and GEO satellites 57 have a latency of approximately 250 milliseconds. The data 58 traveling over a satellite will also travel over terrestrial 59 links in addition to the satellite link. Consequently the 60 latency from sender to receiver can grow to as much as 400 61 msec when using a GEO satellite. These latency values raise 62 questions. What effect will the latency have on HTTP 63 traffic, and am I using the communications link effectively? 65 The other issue in a satellite link is that errors may be 66 bursty rather than random and so lost packets may be an 67 indication of discarding due to errors rather than 68 congestion. Although there are powerful error-correcting 69 codes used on a satellite link, the distribution of errors 70 in packets that have traversed a satellite link are not as 71 uniformly distributed as errors seen on terrestrial 72 connections such as fiber-optic cable. This can cause 73 problems for networks using technology where the error 74 correction mechanisms are not meant to deal with multiple 75 errored bits in a cell. ATM is one such technology. In 76 this case it may be helpful to reduce the bit error rate of 77 the link in order to reduce the probability of grouping 78 errored bits. 80 2. Consequences for HTTP Traffic 82 TCP's receive buffer or receive window is very important for 83 good performance of TCP. A rule of thumb is that the 84 optimum receive buffer size is the bandwidth-delay product 85 of the link. The Internet user would like to make efficient 86 use of bandwidth by using a TCP receive buffer approximately 87 equal to the bandwidth-delay product. Assuming an 88 individual is downloading a web page using a 56.6 kbps 89 modem, the bandwidth they would use is around 7 kbytes/sec. 90 Assuming an end to end delay of 1.0 second, an optimum 91 receive window would be 7 kbytes. Since most PC's use 92 receive windows of 8 kbytes or slightly more, they make 93 efficient use of the connection. Doubling the speed of the 94 connection means that a window size of 14 kbytes would be 95 needed. This would mean the user cannot increase their 96 window size enough to make efficient use of the TCP 97 connection. 99 RFC1323 [2], specifies "large windows", which are windows 100 greater than TCP's maximum theoretical window of 64 kbytes 101 and practical window of 32 kbytes. Large windows increase 102 the theoretical maximum window size of TCP to 2^32 bytes. 103 Unfortunately, the adoption and use of TCP with RFC1323 104 support is not widespread even though its importance is 105 increasing. Newer versions of HTTP state that HTTP will use 106 a single TCP connection rather than multiple connections as 107 in HTTP/1.0. With all of the HTTP data flowing through a 108 single connection, it is critical for TCP to efficiently use 109 the channel bandwidth. TCP is making efficient use of the 110 bandwidth when it is in congestion avoidance mode. 111 Congestion avoidance mode is where the importance of the 112 receive window is greatest since TCP is trying to have many 113 segments "in route" between the sender and receiver. A 114 smaller than optimum window means that all of the available 115 bandwidth is not being used. Recent work [3] shows that the 116 penalty suffered for using "smaller than optimum" window 117 sizes increases with increasing file size and increasing 118 latency. Consequently, the importance of large windows is 119 increasing. 121 When TCP is in slow-start mode it is not making efficient 122 use of the channel's bandwidth. TCP is initially in slow 123 start mode and falls back into slow-start if no data is sent 124 in a period approximately equal to the round trip time of a 125 segment. HTTP/1.1, which sends data through a single TCP 126 connection rather than multiple TCP connections, will reduce 127 the chances of TCP falling back into slow-start. When slow 128 start begins, TCP starts the sender's congestion window at 129 one segment. This lets TCP determine the bandwidth that is 130 available to it. One technique that is being investigated 131 for using TCP over satellites is to start the congestion 132 window at a value greater than one segment. This would mean 133 that TCP starts out using a larger percentage of the 134 available bandwidth. Since the available bandwidth will 135 usually allow sending many segments per window, it is overly 136 conservative for TCP to start out sending a single segment. 137 Other techniques are implemented in the routers in a 138 network. One such protocol is called RED [4] and it will 139 help in congested networks. RED will allow TCP to prepare 140 itself for increasing congestion in a controlled manner. By 141 discarding a few TCP segments as congestion begins, TCP will 142 stop increasing its congestion window. This will prevent 143 the loss of many segments that could force TCP to severely 144 reduce its congestion window. By preventing a large 145 reduction in the congestion window, the available bandwidth 146 can be better used. 147 3. References 148 [1] W. R. Stevens, "TCP Slow Start, Congestion 149 Avoidance, Fast Retransmit, and Fast Recovery Algorithms" 150 RFC 2001, Jan 1997. 151 [2] V. Jacobson, R. Braden, and D. Borman, "TCP 152 Extensions for High Performance" RFC 1323, May 1992. 154 [3] Y Zhang, D DeLucia, B Ryu, S Dao, "Satellite 155 Communications in the Global Internet: Issues, Pitfalls, and 156 Potential", 157 http://www.isoc.org/isoc/whatis/conferences/inet/97/proceedi 158 ngs/F5/F5-1.HTM 160 [4] S. Floyd and V. Jacobson. "Random early dectection 161 gateways for congestion avoidance", IEEE/ACM Transactions on 162 Networking, 1(4):397-413, Aug 1993 164 Author's Address: 166 Robert Pohlmann 167 1761 Business Center Drive 168 Reston, VA 20190 170 Phone: (703) 438-7805 172 Email: pohlmann@sed.stel.com