RFC 2757

Long Thin Networks

📅 published January 2000, from ietf

Status of this Memo ✨

Okay so this bit is the legal-ish disclaimer 💅 This memo is informational only, so it's giving "here's some good info for the Internet community" and it does NOT specify an Internet standard of any kind 🙈 Distribution is unlimited too, so share it with everyone 🌸

Copyright (C) The Internet Society (2000). All Rights Reserved. Mine, yours, the Internet Society's 💜

Abstract 🦋

Okay, so long thin networks (think wireless WANs 📡) are super unpredictable and kind of a mess, which makes finding an optimized transport feel like a daunting task 😭 The authors looked at the existing proposals plus future research items, and based on that overview they also recommend mechanisms you could actually implement in long thin networks 🔥

The goal is to figure out a TCP that works for everyone, including users on long thin networks 👑 They started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group, with that end in mind ✨

They also admit that not every tcpsat recommendation will be needed for long thin networks, so they're working toward a set of TCP recommendations that are 'benign' in environments that don't require them 🫶

Table of Contents 🎀

   1 Introduction .................................................    3
      1.1 Network Architecture ....................................    5
      1.2 Assumptions about the Radio Link ........................    6
   2 Should it be IP or Not?  .....................................    7
      2.1 Underlying Network Error Characteristics ................    7
      2.2 Non-IP Alternatives .....................................    8
         2.2.1 WAP ................................................    8
         2.2.2 Deploying Non-IP Alternatives ......................    9
      2.3 IP-based Considerations .................................    9
         2.3.1 Choosing the MTU [Stevens94, RFC1144] ..............    9
         2.3.2 Path MTU Discovery [RFC1191] .......................   10
         2.3.3 Non-TCP Proposals ..................................   10
   3 The Case for TCP .............................................   11
   4 Candidate Optimizations ......................................   12
      4.1 TCP: Current Mechanisms .................................   12
         4.1.1 Slow Start and Congestion Avoidance ................   12
         4.1.2 Fast Retransmit and Fast Recovery ..................   12
      4.2 Connection Setup with T/TCP [RFC1397, RFC1644] ..........   14
      4.3 Slow Start Proposals ....................................   14
         4.3.1 Larger Initial Window ..............................   14
         4.3.2 Growing the Window during Slow Start ...............   15
            4.3.2.1 ACK Counting ..................................   15
            4.3.2.2 ACK-every-segment .............................   16
         4.3.3 Terminating Slow Start .............................   17
         4.3.4 Generating ACKs during Slow Start ..................   17
      4.4 ACK Spacing .............................................   17
      4.5 Delayed Duplicate Acknowlegements .......................   18
      4.6 Selective Acknowledgements [RFC2018] ....................   18
      4.7 Detecting Corruption Loss ...............................   19
         4.7.1 Without Explicit Notification ......................   19
         4.7.2 With Explicit Notifications ........................   20
      4.8 Active Queue Management .................................   21
      4.9 Scheduling Algorithms ...................................   21
      4.10 Split TCP and Performance-Enhancing Proxies (PEPs) .....   22
         4.10.1 Split TCP Approaches ..............................   23
         4.10.2 Application Level Proxies .........................   26
         4.10.3 Snoop and its Derivatives .........................   27
         4.10.4 PEPs to handle Periods of Disconnection ...........   29
      4.11 Header Compression Alternatives ........................   30
      4.12 Payload Compression ....................................   31
      4.13 TCP Control Block Interdependence [Touch97] ............   32
   5 Summary of Recommended Optimizations .........................   33
   6 Conclusion ...................................................   35
   7 Acknowledgements .............................................   35
   8 Security Considerations ......................................   35
   9 References ...................................................   36
   Authors' Addresses .............................................   44
   Full Copyright Statement .......................................   46

1 Introduction ✨

Okay bestie, so optimized wireless networking is one of the biggest hurdles Mobile Computing has to clear if we want ubiquitous access to networking resources 🌈 The thing is, current data networking protocols were mostly optimized for wired networks 💀 Wireless environments are super different when it comes to latency, jitter, and error rate compared to wired ones, so traditional protocols are ill-suited to this medium 🙈

Mobile Wireless networks come in two flavours: W-LANs (for example, 802.11 compliant networks) and W-WANs (for example, CDPD [CDPD], Ricochet, CDMA [CDMA], PHS, DoCoMo, GSM [GSM] to name a few) 🦋 W-WANs are the most serious challenge, because the length of the wireless link (expressed as the delay*bandwidth product) is typically 4 to 5 times as long as its W-LAN counterparts 😭

Let's do the math, it's giving nerd 🤓 For an 802.11 network, assuming the delay (round-trip time) is about 3 ms. and the bandwidth is 1.5 Mbps, the delay*bandwidth product is 4500 bits. For a W-WAN like Ricochet, a typical round-trip time may be around 500 ms. (the best is about 230 ms.), and the sustained bandwidth is about 24 Kbps. That gives a delay*bandwidth product roughly equal to 1.5 KB 🍓

Now the future is giving 3rd Generation wireless services, which will offer 384Kbps and more ✨ Assuming a 200 ms round-trip, the delay*bandwidth product in this case is 76.8 Kbits (9.6 KB). That's bigger than the default 8KB buffer space used by lots of TCP implementations 👀 So while the default buffer is enough for W-LANs, future W-WANs will operate inefficiently (that is, they won't be able to fill the pipe) unless they override the default value 💅 A 3rd Generation wireless service offering 2 Mbps with 200-millisecond latency needs a 50 KB buffer. Major buffer energy 🫠

Most importantly, latency across a link adversely affects throughput 💔 For example, [MSMO97] derives an upper bound on TCP throughput, and the resulting expression is inversely related to the round-trip time 📉

The long latencies also push the limits (and commonly transgress them) for what users of interactive applications will tolerate 😤

If you look at our list of references, there's a wealth of proposals trying to solve the wireless networking problem 📚 In this document we survey the different solutions that are available or under investigation, and we issue the corresponding recommendations 🫶

There's also a big body of work on improving TCP performance over satellite links 🛰️ The documents under development by the tcpsat working group of the IETF [AGS98, ADGGHOSSTT98] are very relevant. In both cases, it's essential to start by improving the characteristics of the medium by using forward error correction (FEC) at the link layer, to reduce the BER (bit error rate) from values as high as 10-3 to 10-6 or better 🔥 This makes the BER manageable. Once you're in this realm, retransmission schemes like ARQ (automatic repeat request) can be used to bring it down even further 🎀

Heads up: sometimes it may be desirable to forego ARQ because of the additional delay it implies. Time-sensitive traffic (video, audio) must be delivered within a certain time limit, beyond which the data is obsolete. Exhaustive retransmissions in this case just waste time delivering data that will be discarded once it arrives at its destination 🙈 This is why it's desirable to augment the protocol stack implementation on devices, so the upper protocol layers can inform the link and MAC layer when to avoid such costly retransmission schemes 🧚

Networks that include satellite links are examples of "long fat networks" (LFNs or "elephants") 🐘 They're "long" because their round-trip time is quite high (for example, 0.5 sec and higher for geosynchronous satellites). Not all satellite links are in the LFN regime though 🤷‍♀️ In particular, round-trip times in a low-earth orbiting (LEO) satellite network may be as little as a few milliseconds (and never extend beyond 160 to 200 ms). W-WANs share the "L" with LFNs 💜 Satellite networks are also "fat," in the sense that they may have high bandwidth, and they may often have a delay*bandwidth product above 64 KBytes, which poses additional problems to TCP [TCPHP]. W-WANs don't generally show this behaviour. So this document only deals with links that are "long thin pipes," and the networks that contain them: "long thin networks." We call these "LTNs" 🌸

This document doesn't give an overview of the API used to access the underlying transport. The authors believe that's an orthogonal issue, even though some of the proposals below were put forth assuming a given interface 🙃 For example, it's possible to support the traditional socket semantics without fully relying on TCP/IP transport [MOWGLI] ✨

Our focus is on the on-the-wire protocols 🎀 We try to include the most relevant ones and briefly mention their most salient points (since we give you the references you need for further study) 🦋

1.1 Network Architecture 🦋

Okay so the big difference between LFNs and LTNs is that we assume the W-WAN link is the last hop to the end user 💅. That means a single intermediate node sees every packet going between the wireless mobile device and the rest of the Internet 👀. This is only one of the topologies the TCP Satellite community is looking at 🛰️✨.

Since we're all about mobile wireless apps, we only look at one very specific setup 🎀:

  • a wireless mobile device, connected via
  • a wireless link (which may, in fact, be several hops at the link layer), to
  • an intermediate node (sometimes called a base station), connected via
  • a wireline link, which in turn hooks up to
  • the landline Internet and millions of legacy servers and websites 🌐.

We're specifically not that worried about paths with two wireless segments separated by a wired one 🙅‍♀️. That could happen if one mobile device connects over its own wireless segment through an intermediate node to the Internet, and then over a second wireless segment to another mobile device. Honestly, though, mobile devices usually connect to a legacy server on the wired Internet, so that's the main vibe 💖.

Usually the endpoints of the wireless segment are the intermediate node and the mobile device. But the mobile device could also be a wireless router for a mobile network 📡. This is important too, and it has uses in things like disaster recovery 🆘.

Here's the deployability tea ☕. An important requirement is that we cannot change the networking stack on the legacy servers. Full stop 🚫. It would be nicer to only change the networking stack at the intermediate node, although changing it on the mobile devices is totally an option and maybe even a necessity 🥹.

We picture mobile devices that use the wireless medium super efficiently while getting around some of its old-school limits 🔥. Full mobility means the devices are flexible and agile enough to use whichever network connection is the best one available at any given point in time or space 🧚. So a device could switch from a wired office LAN and carry its ongoing connections over to, say, a wireless WAN 🦋. This kind of agility also needs Mobile IP [RFC2002] 💜.

Okay, the system we just described assumes at most one wireless link (which might be more than one wireless hop) 🙌. But that's not enough to fully describe a wireless link, so here are a few more things to think about 🤔:

  • What are the error characteristics of the wireless medium? The link may have a higher BER than a wireline network, thanks to burst errors and disconnections 😭. The techniques below usually don't cover every type of error, so a complete solution should blend the best of all the proposals 🍓. Still, this document cares most about (and prefers solving) the most typical case: (1) a higher BER from random errors (which means longer, more variable delays because of link-layer error corrections and retransmissions) rather than (2) a service interruption from a handoff or a disconnection 🙈. The second one matters too, and we do include relevant proposals for it in this survey 💅.
  • Is the wireless service datagram oriented, or is it a virtual circuit? Right now, switched virtual circuits are more common, but packet networks are starting to show up, like Metricom's Starmode [CB96], CDPD [CDPD], and General Packet Radio Service (GPRS) [GPRS],[BW97] in GSM 📶✨.
  • What kind of reliability does the link provide? Wireless services usually retransmit a packet (frame) until the target acknowledges it 🔁. They may let the user turn that behavior off. For example, GSM lets you turn off RLP [RLP] (Radio Link Protocol) 🙃. Metricom has a similar "lightweight" mode 🪶. In GSM RLP, a frame gets retransmitted until the maximum number of retransmissions (a protocol parameter) is reached 🫠. What happens after that limit is up to the telecom operator: the physical link connection is either disconnected, or a link reset is enforced. In a reset, the sequence numbers get resynchronized and the transmit and receive buffers are flushed, which means data is lost 💀. Some wireless services, like CDMA IS95-RLP [CDMA, Karn93], limit latency on the wireless link by retransmitting a frame only a couple of times 🏃‍♀️. That cuts the residual frame error rate significantly, but it doesn't give you fully reliable link service 😬.
  • Does the mobile device transmit and receive at the same time? Doing that makes the electronics on the mobile device cost more 💸. Typically, it doesn't happen, and in this document we assume that mobile devices do not transmit and receive simultaneously 🌸.
  • Does the mobile device directly address more than one peer on the wireless link? Packets to each different peer may travel over spatially distinct wireless paths, so the path to each peer can have very different characteristics 🗺️. Quite commonly, though, the mobile device only addresses one peer (the intermediate node) at any given point in time 💜. When that's not the case, techniques like Channel-State Dependent Packet Scheduling come into play (see the section "Packet Scheduling" below) 🧠.

2 Should it be IP or Not? 🤷‍♀️✨

Okay, the first decision is whether to use IP as the underlying network protocol at all 🌈. Some data protocols that grew out of wireless telephony are not always layered on top of IP, though sometimes they are [MOWGLI, WAP] 📞. These proposals are built on proxies that provide adaptation services between the wireless and wireline segments 🧚‍♀️.

That's a reasonable model for mobile devices that always talk through the proxy 👍. But we expect a lot of wireless mobile devices to use wireline networks whenever they're available 💻. This matches how laptops are used today: devices usually run on LANs and only fall back to dial-up when they're "out of the office" 🏢.

For these devices, building on IP is the best approach, because IP will be needed for communications that don't go through the intermediate node. An example is reconnecting to a W-LAN or a 10BaseT network at the office 🏠🔌.

2.1 Underlying Network Error Characteristics 🩹

Using IP as the underlying network protocol needs a certain (low) level of link robustness, the kind that's expected of wireless links 📡.

IP, and the protocols carried in IP packets, are protected end-to-end by checksums that are relatively weak [Stevens94, Paxson97] (and in some cases they're optional too) 🫣. For much of the Internet, those checksums are enough. But in wireless environments, the error characteristics of the raw wireless link are much less robust than the rest of the end-to-end path 📉. So for paths that include wireless links, relying only on end-to-end mechanisms to detect and correct transmission errors is undesirable 🙅‍♀️. End-to-end mechanisms should be complemented by local link-level mechanisms 🫶. Otherwise, damaged IP packets get passed along through the network just to be thrown away at the destination host 🗑️. For example, intermediate routers are required to check the IP header checksum, but not the UDP or TCP checksums 🧐. So when the payload of an IP packet gets corrupted, nobody notices until the packet reaches its ultimate destination 😱.

A better approach is to use link-layer mechanisms like FEC, retransmissions, and so on, to improve the characteristics of the wireless link and give IP a much more reliable service 🔥. CDPD, Ricochet, and CDMA have all taken this approach 💜.

It's roughly the same idea as the successful rollout of Point-to-Point Protocol (PPP) on wireline networks. PPP has robust framing and 16-bit checksumming, and it replaced the Serial Line Interface Protocol (SLIP), which had only a single framing byte and no checksumming 🎀.

[AGS98] recommends using FEC in satellite environments 🛰️.

Also, notice that the link layer could adapt its frame size to the prevalent BER 🧩. It would do its own fragmentation and reassembly so that IP could still enjoy a large enough MTU size [LS98] 🍰.

A common worry about using IP as a transport is the header overhead it adds 😩. Typically, the underlying link layer shows up to the IP layer above as PPP [RFC1661]. That opens the door to header compression schemes [IPHC, IPHC-RTP, IPHC-PPP], which greatly ease the problem ✨.

2.2 Non-IP Alternatives 🙋‍♀️

A bunch of non-IP alternatives aimed at wireless environments have been proposed 🌷. We'll look at one representative proposal here 👀.

2.2.1 WAP 📱

The Wireless Application Protocol (WAP) specifies an application framework and network protocols for wireless devices like mobile phones, pagers, and PDAs [WAP] 📲. The architecture needs a proxy between the mobile device and the server 🧑‍🤝‍🧑. The WAP protocol stack is layered over a datagram transport service 📦. Most wireless networks provide a service like that; for example, IS-136, GSM SMS/USSD, and UDP in IP networks like CDPD and GSM GPRS 🛜. The core of the WAP protocols is a binary HTTP/1.1 protocol, with extra features like header caching between requests and shared state between client and server 💾.

2.2.2 Deploying Non-IP Alternatives 🚧

IP is such a fundamental part of the Internet that non-IP alternatives run into big obstacles getting deployed, because they don't use the IP infrastructure 😤. Any non-IP alternative used to provide gatewayed access to the Internet has to map between IP addresses and non-IP addresses 🗺️. It also has to terminate IP-level security at a gateway, and it can't use IP-oriented discovery protocols (Dynamic Host Configuration Protocol, Domain Name Services, Lightweight Directory Access Protocol, Service Location Protocol, etc.) without translation at a gateway 🫠.

It gets even more complicated when a device supports both wireless and wireline operation 🔀. If the device uses IP for wireless operation, uninterrupted operation when it's connected to a wireline network is possible (using Mobile IP) ✅. If a non-IP alternative is used, that switchover is harder to pull off 😵‍💫.

Non-IP alternatives carry the burden of proof: they have to show that IP is so ill-suited to a wireless environment that it isn't a viable technology 🕵️‍♀️. Bestie, that's a high bar 🔥.

2.3 IP-based Considerations 💜

Because IP is deployed worldwide, it's an obvious choice for the underlying network technology 🌍. Optimizations made at this level benefit traditional Internet application protocols, plus new ones layered on top of IP or UDP 🦋✨.

2.3.1 Choosing the MTU [Stevens94, RFC1144] 🎀

okay so in slow networks, sending the biggest possible packet can take forever ⏳😭 interactive response time should not go past the famous human factors limit of 100 to 200 ms, which is giving "human brain gives up after this" energy. that's the max time budget for (1) sending a packet and (2) getting a response back. in most networking stack implementations, (1) depends heavily on the MTU (maximum transmission unit) 💅 worst case, a tiny packet from an interactive app has to sit there waiting for a huge packet from a bulk transfer app before it's allowed to go 💀 so a good rule of thumb is to pick an MTU whose transmission time is less than (or not much bigger than) 200 ms ✨

of course, compression and type-of-service queuing (where interactive data packets get a higher priority) can help with this 🫶 the latter may cut the average wait time down to about half the MTU's transmission time 🦋

2.3.2 Path MTU Discovery [RFC1191] 🌸

path MTU discovery benefits any protocol built on top of IP, and it's honestly so useful 😤 it lets a sender figure out the maximum end-to-end transmission unit to a given destination. without path MTU discovery, the default IPv4 MTU size is 576. going with a larger MTU has a couple of perks:

  • smaller ratio of header overhead to data
  • lets TCP grow its congestion window faster, since it increases in units of segments

of course, for a given BER, a larger MTU has a correspondingly larger probability of error within any given segment 🙈 the BER may be reduced using lower level techniques like FEC and link-layer retransmissions. the catch is that delays may now become a problem because of those extra retransmissions, and packet transmission time goes up with a larger MTU too 😩

Recommendation: path MTU discovery is recommended. [AGS98] already recommends its use in satellite environments. 🛰️✨

2.3.3 Non-TCP Proposals 🧚

other proposals assume an underlying IP datagram service and build an optimized transport either directly on top of IP [NETBLT] or on top of UDP [MNCP]. not relying on TCP is a bold move, bestie, considering the wealth of experience and research behind it 👑 it could be argued that the Internet hasn't collapsed because its main protocol, TCP, is very careful about how it uses the network. it basically treats the network as a black box, assumes all packet losses are due to congestion, and prudently backs off, which avoids further congestion 🫶

however, on the wireless medium, packet losses may also be caused by corruption from high BER, fading, and so on 😳 here, the right approach is to try harder instead of backing off 💪 the alternative transport protocols are:

3 The Case for TCP 💜

this is one of the most hotly debated issues in the wireless arena, no cap 🍿 here are some arguments against it:

  • it is generally recognized that TCP does not perform well in the presence of significant levels of non-congestion loss. TCP detractors argue that the wireless medium is one such case, and that it's hard enough to fix TCP. they argue that it's easier to start from scratch.
  • TCP has too much header overhead.
  • by the time the mechanisms are in place to fix it, TCP is very heavy and ill-suited for lightweight, portable devices.

and here are some in support of TCP:

  • it is preferable to keep using the same protocol that the rest of the Internet uses, for compatibility reasons. any extensions specific to the wireless link may be negotiated.
  • legacy mechanisms may be reused (for example, the three-way handshake).
  • link-layer FEC and ARQ can reduce the BER such that any losses TCP does see are, in fact, caused by congestion (or a sustained interruption of link connectivity). modern W-WAN technologies do this (CDPD, US-TDMA, CDMA, GSM), which improves TCP throughput 📈
  • handoffs among different technologies are made possible by Mobile IP [RFC2002], but only if the same protocols, namely TCP/IP, are used throughout 🦋
  • given TCP's wealth of research and experience, alternative protocols are relatively immature, and the full implications of their widespread deployment are not clearly understood 🤔

overall, we feel that the performance of TCP over long-thin networks can be improved significantly ✨ the mechanisms to do so are discussed in the next sections 💅

4 Candidate Optimizations 🌈

there is a large volume of work on optimizing TCP for operation over wireless media, and it's a lot 📚 even though satellite networks generally fall in the LFN regime, our current LTN focus has so much to benefit from it. for example, the work of the TCP-over-Satellite working group of the IETF has been extremely helpful in preparing this section [AGS98, ADGGHOSSTT98] 🛰️🫶

4.1 TCP: Current Mechanisms 🍓

a TCP sender adapts its use of bandwidth based on feedback from the receiver. the high latency characteristic of LTNs means TCP's adaptation is correspondingly slower than on networks with shorter delays 🐢 delayed ACKs make the perceived latency on the link even worse 😭 and since TCP grows its congestion window in units of segments, small MTUs may slow adaptation down even further.

4.1.1 Slow Start and Congestion Avoidance ⏫

Slow Start and Congestion Avoidance [RFC2581] are essential to the Internet's stability 🫶 however, there are two reasons why the wireless medium adversely affects them:

  • whenever TCP's retransmission timer expires, the sender assumes that the network is congested and invokes slow start. this is why it's important to minimize the losses caused by corruption, leaving only those caused by congestion (as TCP expects) 🧹
  • the sender increases its window based on the number of ACKs received. their rate of arrival depends on the RTT (round-trip-time) between sender and receiver, which implies long ramp-up times on high latency links like LTNs. this dependency lasts until the pipe is filled 🥲
  • during slow start, the sender increases its window in units of segments. this is why it's important to use an appropriately large MTU, which in turn requires link layers with low loss 🔥

4.1.2 Fast Retransmit and Fast Recovery 🏃‍♀️

when a TCP sender receives several duplicate ACKs, fast retransmit [RFC2581] lets it infer that a segment was lost. the sender retransmits what it considers to be this lost segment without waiting for the full timeout, which saves time ⏱️

after a fast retransmit, a sender invokes the fast recovery [RFC2581] algorithm. fast recovery lets the sender transmit at half its previous rate (regulating the growth of its window based on congestion avoidance) instead of having to begin a slow start. this also saves time 💖

in general, TCP can increase its window beyond the delay-bandwidth product. however, on LTN links the congestion window may stay rather small (less than four segments) for long periods of time, for any of the following reasons:

  1. typical "file size" transferred over a connection is relatively small (Web requests, Web document objects, email messages, files, etc.). users of LTNs are not very willing to carry out large transfers, since the response time is so long 🙃
  2. if the link has high BER, the congestion window tends to stay small 📉
  3. when an LTN is combined with a highly congested wireline Internet path, congestion losses on the Internet have the same effect as 2.
  4. commonly, ISPs/operators configure only a small number of buffers (even as few as for 3 packets) per user in their dial-up routers 😬
  5. often small socket buffers are recommended with LTNs in order to prevent the RTO from inflating and to reduce the number of packets competing with other traffic 🧠

a small window effectively stops the sender from taking advantage of Fast Retransmits 😢 efficient recovery from multiple losses within a single window requires adoption of new proposals (NewReno [RFC2582]). on slow paths with no packet reordering, waiting for three duplicate ACKs to arrive also postpones retransmission unnecessarily ⏳

Recommendation: implement Fast Retransmit and Fast Recovery at this time. this is a widely-implemented optimization and is currently at Proposed Standard level. [AGS98] recommends implementation of Fast Retransmit/Fast Recovery in satellite environments. NewReno [RFC2582] apparently does help a sender better handle partial ACKs and multiple losses in a single window, but at this point it is not recommended due to its experimental nature. instead, SACK [RFC2018] is the preferred mechanism 🎀✨

4.2 Connection Setup with T/TCP [RFC1397, RFC1644] 🦋

TCP engages in a "three-way handshake" whenever a new connection is set up. data transfer is only possible after this phase has completed successfully 🤝 T/TCP lets data be exchanged in parallel with the connection setup, which saves valuable time for short transactions on long-latency networks ⏩

Recommendation: T/TCP is not recommended, for these reasons:

  • it is an Experimental RFC.
  • it is not widely deployed, and it has to be deployed at both ends of a connection.
  • security concerns have been raised that T/TCP is more vulnerable to address-spoofing attacks than TCP itself. 🚨
  • at least some of the benefits of T/TCP (eliminating the three-way handshake on subsequent query-response transactions, for instance) are also available with persistent connections on HTTP/1.1, which is more widely deployed 💅

[ADGGHOSSTT98] does not have a recommendation on T/TCP in satellite environments. 🛰️

4.3 Slow Start Proposals 🌷

because slow start dominates the network response that interactive users see at the beginning of a TCP connection, a number of proposals have been made to modify or eliminate slow start in long latency environments 😤

stability of the Internet is paramount 👑 so these proposals must demonstrate that they will not adversely affect Internet congestion levels in significant ways 🫶

4.3.1 Larger Initial Window ✨

Okay so traditional slow start, which begins with an initial window of one segment, is a super slow way to figure out bandwidth over LTNs 😭. Studies on starting with a bigger initial window than one segment [RFC2414, AHO98] ended with the TCP standard supporting a max value of 2 [RFC2581]. Higher values are still experimental, bestie 🧪.

In simulations with an initial window of three packets [RFC2415], this proposal doesn't really add to packet drop rates 👀. It also has the bonus of improving initial response times when the peer device delays acknowledgements during slow start (see next proposal) 🎀.

[RFC2416] covers situations where the initial window is bigger than the number of buffers TCP has available. It says this is no different from the case where the congestion window grows beyond the number of buffers available 💅.

[RFC2581] now allows an initial congestion window of two segments. A larger initial window, maybe as many as four segments, might be allowed in the future in environments where it makes a big difference to performance (LFNs and LTNs) 🌈.

Recommendation: Implement this on devices now. The research on this optimization says 3 segments is a safe initial setting, and it's centering on choosing between 2, 3, and 4. For now, use 2 (following RFC2581). That at least lets clients running query-response applications get an initial ACK from unmodified servers without waiting for a typical delayed ACK timeout of 200 milliseconds, and it saves two round-trips 🫶. An initial window of 3 [RFC2415] looks promising and may be adopted in the future, pending further research and experience 🔥.

4.3.2 Growing the Window during Slow Start 🦋

The sender grows its window based on the flow of ACKs coming back from the receiver. Especially during slow start, this flow is super important. Two of the proposals that have been studied are (1) ACK counting and (2) ACK-every-segment.

4.3.2.1 ACK Counting 🧮

The main idea behind ACK counting is:

  • Make each ACK count to its fullest by growing the window based on the data being acknowledged (byte counting) instead of the number of ACKs (ACK counting). This has been shown to cause bursts, which lead to congestion. [Allman98] shows that Limited Byte Counting (LBC), where the window growth is limited to 2 segments, doesn't lead to as much burstiness and offers some performance gains.

Recommendation: Unlimited byte counting is not recommended 🙅‍♀️. Van Jacobson cautions against byte counting [TCPSATMIN] because it leads to burstiness, and he recommends ACK spacing [ACKSPACING] instead.

ACK spacing requires ACKs to consistently pass through a single ACK-spacing router. This works well for W-WAN environments if the ACK-spacing router is also the intermediate node 📡.

Limited byte counting warrants further investigation before we can recommend this proposal, but it shows promise ✨.

4.3.2.2 ACK-every-segment 🎀

The main idea behind ACK-every-segment is:

  • Keep a constant stream of ACKs coming back by turning off delayed ACKs [RFC1122] during slow start. ACK-every-segment must be limited to slow start so it doesn't penalize asymmetric-bandwidth configurations. For instance, a low bandwidth link carrying acknowledgements back to the sender hinders the growth of the congestion window, even if the link toward the client has greater bandwidth [BPK99].

Even though simulations confirm its promise (it lets receivers get the second segment from unmodified senders without waiting for a typical delayed ACK timeout of 200 milliseconds), for this technique to be practical, the receiver must acknowledge every segment only when the sender is in slow start. Continuing to do so when the sender is in congestion avoidance may have adverse effects on the mobile device's battery consumption and on traffic in the network 🔋.

This violates a SHOULD in [RFC2581]: delayed acknowledgements SHOULD be used by a TCP receiver. Not ideal, bestie 🙈.

"Disabling Delayed ACKs During Slow Start" is technically unimplementable 💀. The receiver has no way of knowing when the sender crosses ssthresh (the "slow start threshold") and begins using the congestion avoidance algorithm. If receivers follow the recommendations for increased initial windows, disabling delayed ACKs during an increased initial window would open the TCP window more rapidly without doubling ACK traffic in general. However, this scheme might double ACK traffic if most connections remain in slow-start.

Recommendation: ACK only the first segment on a new connection with no delay 🚀.

4.3.3 Terminating Slow Start 🛑

New mechanisms [ADGGHOSSTT98] are being proposed to improve TCP's adaptive properties, so the available bandwidth is better utilized while reducing the possibility of congesting the network. This results in the congestion window getting closed down to 1 segment (which precludes fast retransmit), and then the slow start phase kicks back in 😤.

Theoretically, an optimum value for the slow-start threshold (ssthresh) lets connection bandwidth utilization ramp up as aggressively as possible without "overshoot" (using so much bandwidth that packets are lost and congestion avoidance procedures are invoked) 🏎️.

Recommendation: Estimating the slow start threshold is not recommended. Although it would be helpful if we knew how to do it, rough consensus on the tcp-impl and tcp-sat mailing lists is that in non-trivial operational networks there's no reliable method to probe during TCP startup and estimate the available bandwidth 🤷‍♀️.

4.3.4 Generating ACKs during Slow Start 🌸

Mitigations that inject additional ACKs (whether "ACK-first-segment" or "ACK-every-segment-during-slow-start") beyond what today's conformant TCPs inject are only applicable during the slow-start phases of a connection. After an initial exchange, the connection usually completes slow-start, so TCPs only inject additional ACKs when (1) the connection is closed and a new connection is opened, or (2) the TCPs handle idle connection restart correctly by performing slow start.

Item (1) is typical when using HTTP/1.0, where each request-response transaction requires a new connection. Persistent connections in HTTP/1.1 help keep a connection in congestion avoidance instead of constantly reverting to slow-start 🔁. Because of this, these optimizations, which are only enabled during slow-start, don't get as much of a chance to act. Item (2), of course, is independent of HTTP version.

4.4 ACK Spacing 🦋

During slow start, the sender responds to the incoming ACK stream by transmitting N+1 segments for each ACK, where N is the number of new segments acknowledged by the incoming ACK. This means data is being sent at twice the speed at which it can be processed by the network 😳. So queues form, and because of insufficient buffering at the bottleneck router, packets may get dropped before the link's capacity is full.

Spacing out the ACKs effectively controls the rate at which the sender transmits into the network, and it may result in little or no queueing at the bottleneck router [ACKSPACING]. Ack spacing also reduces the size of the bursts 🎀.

Recommendation: No recommendation at this time. Keep monitoring research in this area 👀.

4.5 Delayed Duplicate Acknowlegements 🙈

As was mentioned above, link-layer retransmissions may decrease the BER enough that congestion accounts for most packet losses. Still, nothing can be done about interruptions due to handoffs, moving beyond wireless coverage, etc. In this scenario, it is imperative to prevent interaction between link-layer retransmission and TCP retransmission, because these layers duplicate each other's efforts 😩. In such an environment, it may make sense to delay TCP's efforts so the link-layer has a chance to recover. With this in mind, the Delayed Dupacks [MV97, Vaidya99] scheme selectively delays duplicate acknowledgements at the receiver. It's better to let a local mechanism resolve a local problem than to invoke TCP's end-to-end mechanism and take on the associated costs, both in wasted bandwidth and in its effect on TCP's window behavior 💅.

The Delayed Dupacks scheme can be used despite IP encryption, since the intermediate node doesn't need to examine the TCP headers 🔐.

Right now, it's not well understood how long the receiver should delay the duplicate acknowledgments. In particular, the impact of wireless medium access control (MAC) protocol on the choice of delay parameter needs to be studied. The MAC protocol may affect the ability to choose the appropriate delay, either statically or dynamically. In general, significant variability in link-level retransmission times can have an adverse impact on the performance of the Delayed Dupacks scheme. Furthermore, as discussed later in section 4.10.3, Delayed Dupacks and some other schemes (such as Snoop [SNOOP]) are only beneficial in certain types of network links 🧐.

Recommendation: Delaying duplicate acknowledgements may be useful in specific network topologies, but a general recommendation requires further research and experience 🌈.

4.6 Selective Acknowledgements [RFC2018] 🧚

According to Section 1.1 of [TCPHP], SACK may not be useful in many LTNs. SACK is more useful in the LFN regime, especially if large windows are being used, because there's a considerable probability of multiple segment losses per window 🌊. In the LTN regime, TCP windows are much smaller, and burst errors must be much longer in duration to damage multiple segments.

So the complexity of SACK may not be justifiable, unless there's a high probability of burst errors and congestion on the wireless link. A desire for compatibility with TCP recommendations for non-LTN environments may dictate LTN support for SACK anyway 🤔.

[AGS98] recommends the use of SACK with Large TCP Windows in satellite environments, and notes that this implies support for PAWS (Protection Against Wrapped Sequence space) and RTTM (Round Trip Time Measurement) as well 🛰️.

Berkeley's SNOOP protocol research [SNOOP] indicates that SACK does improve throughput for SNOOP when multiple segments are lost per window [BPSK96]. SACK lets SNOOP recover from multi-segment losses in one round-trip. In this case, the mobile device needs to implement some form of selective acknowledgements. If SACK isn't used, TCP may enter congestion avoidance, because the time needed to retransmit the lost segments may be greater than the retransmission timer ⏰.

Recommendation: Implement SACK now for compatibility with other TCPs and improved performance with SNOOP 👑.

4.7 Detecting Corruption Loss 🔍

4.7.1. Without Explicit Notification

Okay so, when the network doesn't tell you anything explicitly 🫣, some researchers have suggested statistical methods for congestion avoidance [Jain89, WC91, VEGAS]. A natural extension of these heuristics would enable a sender to distinguish between losses caused by congestion and other causes. ngl, the research results on the reliability of sender-based heuristics is unfavorable [BV97, BV98]. [BV98a] reports better results in constrained environments using packet inter-arrival times measured at the receiver, but highly-variable delay (the type you get in wireless environments during intercell handoff) confounds these heuristics 😭

Recommendation: No recommendation at this time - continue to monitor research results 🔍

4.7.2. With Explicit Notifications

With explicit notification from the network, it's possible to determine when a loss is due to congestion ✨. Several proposals along these lines include:

  • Explicit Loss Notification (ELN) [BPSK96]
  • Explicit Bad State Notification (EBSN) [BBKVP96]
  • Explicit Loss Notification to the Receiver (ELNR), and Explicit Delayed Dupack Activation Notification (EDDAN) (notifications to mobile receiver) [MV97]
  • Explicit Congestion Notification (ECN) [ECN]

Of these, Explicit Congestion Notification (ECN) seems closest to deployment on the Internet, and it'll give some benefit to TCP connections on long thin networks (as well as to all other TCP connections) 💅

Recommendation: No recommendation at this time. Schemes like ELNR and EDDAN [MV97], where the only systems that need to be modified are the intermediate node and the mobile device, are slated for adoption pending further research. However, this solution has some limitations 🙈 Since the intermediate node must have access to the TCP headers, the IP payload must not be encrypted.

ECN uses the TOS byte in the IP header to carry congestion information (ECN-capable and Congestion-encountered). This byte is not encrypted in IPSEC, so ECN can be used on TCP connections that are encrypted using IPSEC 🔐

Recommendation: Implement ECN. In spite of this, mechanisms for explicit corruption notification are still relevant and should be tracked 🎀

Note: ECN provides useful information to avoid deteriorating further a bad situation, but it has some limitations for wireless applications. Absence of packets marked with ECN should not be interpreted by ECN-capable TCP connections as a green light for aggressive retransmissions. On the contrary, during periods of extreme network congestion, routers may drop packets marked with explicit notification because their buffers are exhausted. That's exactly the wrong time for a host to begin retransmitting aggressively 💀

4.8. Active Queue Management ✨

As has been pointed out above, TCP responds to congestion by closing down the window and invoking slow start. Long-delay networks take a particularly long time to recover from this condition, so it is imperative to avoid congestion in LTNs 🐢 To fix this, active queue management techniques have been proposed as enhancements to routers throughout the Internet [RED]. The primary motivation for deploying these mechanisms is to prevent "congestion collapse" (a severe degradation in service) by controlling the average queue size at the routers. As the average queue length grows, Random Early Detection [RED] increases the possibility of dropping packets.

The benefits are:

  • Reduce packet drops in routers. By dropping a few packets before severe congestion sets in, RED avoids dropping bursts of packets. In other words, the objective is to drop m packets early to prevent n drops later on, where m is less than n 🫶
  • Provide lower delays. This follows from the smaller queue sizes, and it's especially important for interactive applications, for which the inherent delays of wireless links already push the user experience to the limits of the non-acceptable 🥹
  • Avoid lock-outs. Lack of resources in a router (and the resultant packet drops) may, in effect, obliterate throughput on certain connections. Because of active queue management, it is more probable for an incoming packet to find available buffer space at the router 👑

Active Queue Management has two components: (1) routers detect congestion before exhausting their resources, and (2) they provide some form of congestion indication. Dropping packets via RED is only one example of the latter. Another way to indicate congestion is to use ECN [ECN], as discussed above under "Detecting Corruption Loss: With Explicit Notifications." 🦋

Recommendation: RED is currently being deployed in the Internet, and LTNs should follow suit. ECN deployment should complement RED's 💜

4.9. Scheduling Algorithms 🧚

Active queue management helps control the length of the queues. Additionally, a general solution requires replacing FIFO with other scheduling algorithms that improve:

  1. Fairness (by policing how different packet streams utilize the available bandwidth), and
  2. Throughput (by improving the transmitter's radio channel utilization).

For example, fairness is necessary for interactive applications (like telnet or web browsing) to coexist with bulk transfer sessions. Proposals here include:

  • Fair Queueing (FQ) [Demers90]
  • Class-based Queueing (CBQ) [Floyd95]

Even if they are only implemented over the wireless link portion of the communication path, these proposals are attractive in wireless LTN environments, because new connections for interactive applications can have difficulty starting when a bulk TCP transfer has already stabilized using all available bandwidth 🌸

In our base architecture described above, the mobile device typically communicates directly with only one wireless peer at a given time: the intermediate node. In some W-WANs, it is possible to directly address other mobiles within the same cell. Direct communication with each such wireless peer may traverse a spatially distinct path, and each of these may exhibit statistically independent radio link characteristics. Channel State Dependent Packet Scheduling (CSDP) [BBKT96] tracks the state of the various radio links (as defined by the target devices), and gives preferential treatment to packets destined for radio links in a "good" state. This avoids attempting to transmit to (and expect acknowledgements from) a peer on a "bad" radio link, thus improving throughput 📶

A further refinement of this idea suggests that both fairness and throughput can be improved by combining a wireless-enhanced CBQ with CSDP [FSS98] 🌈

Recommendation: No recommendation at this time, pending further study 🔍

4.10. Split TCP and Performance-Enhancing Proxies (PEPs) 🍓

Given the dramatic differences between wired and wireless links, a very common approach is to provide some impedance matching where the two different technologies meet: at the intermediate node 🤝

The idea is to replace an end-to-end TCP connection with two clearly distinct connections: one across the wireless link, and the other across its wireline counterpart. Each of the two resulting TCP sessions operates under very different networking characteristics, and may adopt the policies best suited to its particular medium. For example, in a specific LTN topology it may be desirable to modify TCP Fast Retransmit to resend after the first duplicate ack, and Fast Recovery to not shrink the congestion window, if the LTN link has an extremely long RTT, is known to not reorder packets, and is not subject to congestion. Moreover, on a long-delay link or on a link with a relatively high bandwidth-delay product, it may be desirable to "slow-start" with a relatively large initial window, even larger than four segments. While these kinds of TCP modifications can be negotiated to be employed over the LTN link, they would not be deployed end-to-end over the global Internet. In LTN topologies where the underlying link characteristics are known, various similar types of performance enhancements can be employed without endangering operations over the global Internet 🛠️

In some proposals, in addition to a PEP mechanism at the intermediate node, custom protocols are used on the wireless link (for example, [WAP], [YB94] or [MOWGLI]) 📱

Even if the gains from using non-TCP protocols are moderate or better, the wealth of research on optimizing TCP for wireless, and compatibility with the Internet, are compelling reasons to adopt TCP on the wireless link (enhanced as suggested in section 5 below) 💖

4.10.1 Split TCP Approaches 🎀

Okay so split TCP proposals like I-TCP [ITCP] and MTCP [YB94] get their performance boosts by ditching end-to-end semantics 🙈

The Mowgli architecture [MOWGLI] is a split approach too, but it's giving full-stack glow-up. It adds enhancements at all the protocol layers, not just transport ✨ It even lets you replace the TCP/IP core protocols on the LTN link with a custom protocol tuned for LTN links [KRLKA97]. It also has priority-based multiplexing of concurrent connections with shared flow control, so interactive apps get link capacity in a timely manner even when bandwidth-hungry background transfers are running. And with that option, Mowgli keeps socket semantics on the mobile device so legacy apps can run unmodified. Iconic 💅

Employing split TCP approaches has benefits and drawbacks, so let's look at both. 🦋

Benefits related to split TCP approaches include the following:

  • Splitting the end-to-end TCP connection into two parts is a straightforward way to shield the problems of the wireless link from the wireline Internet path, and vice versa. That means you can apply local fixes to local problems on the wireless link 🫶 It automatically sorts out congestion losses on the wireline Internet from transmission-error losses on the wireless link, since they live on separate TCP connections. Even if both segments are congested, the congestion may be different in nature and can be treated that way. Temporary disconnections of the wireless link can also be shielded from the wireline Internet.
  • When one of the TCP connections crosses only a single-hop wireless link or a very limited number of hops, some or all link characteristics for that TCP path are known. For example, we may know the link provides reliable delivery, packets are not delivered out of order, or the link is not subject to congestion. With that info, picking the TCP mitigations becomes a way easier task. Several mitigations that can't be safely used over the global Internet can be used successfully over the wireless link too ✨
  • Splitting one TCP connection into two allows much earlier deployment of recent proposals to improve TCP performance over wireless links. Only the TCP implementations of the mobile device and intermediate node need to be modified, so the vast number of Internet hosts can keep running legacy TCP unmodified. Mitigations that would require modifying TCP on those wireline hosts may take far too long to become widely deployed 🐢
  • It allows exploitation of various application level enhancements, which may give significant performance gains (see section 4.10.2).

Drawbacks related to split TCP approaches include the following:

  • The big criticism is that split TCP breaks TCP end-to-end semantics. This has various drawbacks, and some are more severe than others 😬 The most detrimental one is probably that splitting the TCP connection disables end-to-end use of IP layer security mechanisms, so IPSec can't be applied for end-to-end security. IPSec could be used separately in each of the two parts, but that means the intermediate node has to become a party to the security association between the mobile device and the remote host. That's an undesirable or unacceptable alternative in most cases. For end-to-end security, other mechanisms above the transport layer, like TLS [RFC2246] or SOCKS [RFC1928], should be employed.
  • Crashes of the intermediate node become unrecoverable, which results in termination of the TCP connections. Whether this is a severe problem depends on how often such crashes are expected to happen 💀
  • People often say that if TCP end-to-end semantics get broken, apps relying on TCP for reliable delivery become more vulnerable. Honestly, that's an overstatement 🙄 A well-designed app should never fully rely on TCP for end-to-end reliability at the application level anyway. First, current APIs to TCP, like the Berkeley socket interface, don't let apps know when a TCP acknowledgement for previously sent user data arrives at the TCP sender. Second, even if the app is told about TCP acknowledgements, the sending app can't know whether the receiving app has gotten the data. It only knows the data reached the TCP receive buffer at the receiving end. Finally, to get end-to-end reliability at the application level, an application level acknowledgement is required to confirm the receiver has taken the appropriate actions on the data it received.
  • When a mobile device moves, it gets handed over by the serving base station. If the base station is 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 keep the split TCP connection running. That's extra work and overhead 😮‍💨 However, in most W-WAN networks, unlike W-LANs, the W-WAN base station doesn't give the mobile device its connection point to the wireline Internet (those base stations may not even have an IP stack). Instead, the W-WAN network handles the mobility and keeps the connection point to the wireline Internet unchanged while the mobile device moves. So TCP state handover is not required in most W-WANs 🙌
  • Packets traversing all the protocol layers up to transport and then back down to the link layer cause extra overhead at the intermediate node. With LTNs that have low bandwidth, this extra overhead doesn't cause serious additional performance problems, unlike W-LANs that typically have much higher bandwidth.
  • Split TCP proposals aren't 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. Some networks can't do that, or the intermediate node has to sit several hops away from the wireless network edge. That's impractical in many cases and may result in non-optimal routing 🗺️
  • Split TCP, as the name implies, doesn't address problems related to UDP.

It should be noted that using split TCP doesn't 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 it should be under end-user control, so the user can decide whether a particular TCP connection or application makes use of split TCP or operates end-to-end directly over IP. Main character energy 👑

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. No notes, bestie 💖

4.10.2 Application Level Proxies 🧚

Application level proxies are everywhere on the Internet these days 🌈 Think Web proxy caches, relay MTAs (Mail Transfer Agents), and secure transport proxies (e.g., SOCKS). Basically, employing an application level proxy results in a "split TCP connection" with the proxy as the middle person. So some of the problems that come with wireless links, like a congested wide-area Internet path combined with a wireless LTN link, get automatically eased to some extent 💅

Application protocols often use plenty of (unnecessary) round trips, lots of headers, and inefficient encoding 💀 Even unnecessary data can end up crossing the wireless link during regular application protocol operation. In many cases you can cut a big chunk of this overhead just by running an application level proxy on the intermediate node. With LTN links, you can get significant extra improvement by adding application level proxies with application-specific enhancements. Such a proxy may run an enhanced version of the application protocol over the wireless link ✨

In an LTN environment, enhancements at the application layer may give way more notable performance improvements than any transport level enhancements. Obsessed 😭

The Mowgli system fully supports adding application level agent-proxy pairs between the client and the server, with 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 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 to employ a proxy for an application must be under user control at all times. Periodt 🎀

4.10.3. Snoop and its Derivatives ✨

okay so Berkeley's SNOOP protocol [SNOOP] is a hybrid scheme 🧚 that mixes link-layer reliability mechanisms with the split connection approach. it's giving improvement over split TCP approaches because end-to-end semantics are retained 💖 SNOOP does two things:

  1. Locally (on the wireless link) retransmit lost packets, instead of letting TCP do it end-to-end.
  2. Suppress the duplicate acks on their way from the receiver back to the sender, so the sender skips fast retransmit and congestion avoidance 🙈

So the Snoop protocol is built to avoid unnecessary fast retransmits by the TCP sender when the wireless link layer retransmits a packet locally 🦋 picture a system without a Snoop agent. a TCP sender S sends packets to receiver R through an intermediate node IN. the sender sends packets A, B, C, D, E (in that order), and IN forwards them to the wireless receiver R. then the first transmission of packet B gets lost to wireless errors, so IN retransmits B later. the receiver ends up getting A, C, D, E and then B (in that order). ngl this is where it gets messy 😭 packets C, D and E each trigger duplicate acknowledgements. once the TCP sender gets three duplicate acknowledgements, it fires a fast retransmit, which means a retransmission and a cut to the congestion window. that fast retransmit happens even though the link-level retransmit already handled it on the wireless link, so throughput takes a hit 💀

SNOOP [SNOOP] fixes this by dropping TCP dupacks appropriately at the intermediate node 💅 the Delayed Dupacks (see section 4.5) tries to copy Snoop's vibe without needing any changes at the intermediate node 🫶 these schemes only matter if a fast retransmit caused by wireless errors is a real possibility. specifically, if the wireless link uses a stop-and-go protocol (or otherwise delivers packets in-order), these schemes aren't very beneficial. also, if the bandwidth-delay product of the wireless link is smaller than four segments, the chance that the intermediate node gets 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, a wireless bandwidth-delay product under four packets means schemes like Snoop and Delayed Dupacks wouldn't be necessary (unless the link layer isn't designed properly) 🙃 but when the wireless bandwidth-delay product is big enough, Snoop can give a significant performance boost compared with standard TCP 🚀 for more on all this, check out [Vaidya99] 📚

The Delayed Dupacks scheme tends to perform well in the same environments where Snoop performs well 🌸 generally, the performance gain from Delayed Dupacks depends on packet loss rates from congestion and from transmission errors. when congestion-related losses happen, Delayed Dupacks unnecessarily delays retransmission, so with congestion losses it can't match Snoop's performance gain. still, simulation results [Vaidya99] show that Delayed Dupacks can get a significant performance improvement even with moderate congestion losses 👑

WTCP [WTCP] is similar to SNOOP in that it preserves end-to-end semantics 🎀 in WTCP, the intermediate node uses a complicated scheme to hide the time it spends recovering from local errors across the wireless link (this usually includes retransmissions from error recovery, but it can also include time spent dealing with congestion). the goal is for the sender to come up with a smooth estimate of round-trip time 🧠 to work well, WTCP assumes that the TCP endpoints implement the Timestamps option in RFC 1323 [TCPHP]. unfortunately, RFC 1323 support in TCP implementations isn't widespread yet 😤 other than that, WTCP only needs changes at the intermediate node ✨

SNOOP and WTCP both require the intermediate node to examine and operate on the traffic between the portable wireless device and the TCP server on the wired Internet 👀 they don't work if the IP traffic is encrypted, unless the intermediate node shares the security association between the mobile device and its end-to-end peer. they also need both the data and the corresponding ACKs to go through the same intermediate node. and if the intermediate node retransmits packets at the transport layer across the wireless link, that can duplicate the link-layer's work 🙈 the designers of SNOOP describe it as a TCP-aware link-layer, and honestly that's the right approach: the link and network layers can be way more aware of each other than traditional OSI layering suggests 💜

Encryption of IP packets with IPSEC's ESP header (in either transport or tunnel mode) makes the TCP header and payload unreadable to the intermediate node 🔒 that blocks SNOOP (and WTCP) from working, because they need to examine the TCP headers in both directions. possible solutions include:

  • 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

but these techniques require users to trust intermediate nodes 🥺 users who value both privacy and performance should use SSL or SOCKS for end-to-end security. those are implemented above the transport layer, though, and they aren't as resistant to some security attacks (for example, ones based on guessing TCP sequence numbers) as IPSEC is 🛡️

Recommendation: Implement SNOOP on intermediate nodes now 🍓 the research results are encouraging, and it's an "invisible" optimization, since neither the client nor the server needs to change, only the intermediate node (for basic SNOOP without SACK). however, as discussed above, there's 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 super common in wireless networks, whether they happen during handoff, from lack of resources (dropped connections), or because of natural obstacles 🌧️ during these periods, a TCP sender doesn't get the acknowledgements it expects. when the retransmit timer expires, TCP closes its congestion window, and that comes with all the related drawbacks 😩 retransmitting packets is pointless since the connection is broken. [M-TCP] is trying to help TCP handle handoffs and periods of disconnection better, while still preserving end-to-end semantics ✨ M-TCP adds an element: a supervisor host (SH-TCP) at the edge of the wireless network 🧚

this intermediate node monitors the traffic going from the sender to the mobile device. it doesn't break end-to-end semantics, because the ACKs the intermediate node sends to the sender are effectively the ones the mobile node would send 🫶 the principle is to generally leave the last byte unacknowledged. so SH-TCP can shut down the sender's window by sending the ACK for the last byte with a window set to zero, and then the sender goes into persist mode 🧊

the second optimization happens on both the intermediate node and the mobile host. on the mobile host, TCP knows the current state of the connection, so when a disconnection happens, it can freeze all timers 🥶 when reconnection happens, the mobile sends a specially marked ACK carrying the number of the highest byte received. the intermediate node assumes the mobile is disconnected because it monitors the flow on the wireless link, so if acknowledgments from the mobile stop coming, it tells SH-TCP, which sends the ACK that closes the sender's window (like in the paragraph above) 🙌 the intermediate node learns the mobile is connected again when it receives a duplicate acknowledgment marked as reconnected. at that 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 starts by retransmitting any data the mobile node hasn't acknowledged yet 🔁 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 gets an indication from the mobile 🥰

Recommendation: M-TCP isn't slated for adoption at this moment 🚫 the proposal is highly experimental, and it's uncertain whether TCP/IP implementations handle zero window updates correctly. keep 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 it 💅

Mechanisms for TCP and IP header compression defined in [RFC1144, IPHC, IPHC-RTP, IPHC-PPP] give you 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 drop from 11.7 to less than 1 per cent) 📉
  • Reduce packet loss rate over lossy links (because compressed packets have a smaller cross-section) 🎯

Van Jacobson (VJ) header compression [RFC1144] describes a Proposed Standard for TCP header compression that's 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, so resynchronization can happen without waiting for a TCP timeout (and running 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, since it's a widely deployed Proposed Standard. however, it should only be enabled when operating over reliable LTNs, because even a single bit error most probably results in a full TCP window being dropped, followed by a costly recovery via slow-start 💀🫠

4.12 Payload Compression 🎀

okay so compressing IP payloads is ALSO super desirable, bestie 💅 "IP Payload Compression Protocol (IPComp)" [IPPCP] is the framework that lets common compression algorithms get applied to arbitrary IP segment payloads. ngl it's kind of a niche optimization 🙈 It's needed because IP-level security turns payloads into random bitstreams, which totally defeats the link-layer compression that usually gets deployed, since those payloads have no redundant "information" left to represent more compactly 💀

However, a lot of IP payloads are already compressed (images, audio, video, "zipped" files being FTPed) or already encrypted above the IP layer (SSL/TLS, etc.) 😭 These payloads won't "compress" any further, so the benefit is limited 🥲

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 give equivalent benefits for common compressible MIME types like text/html. This will reduce the need for IPComp. If IPComp gets deployed faster than HTTP-NG, IPComp compression of HTML and MIME headers would be beneficial ✨

In general, application-level compression can often outperform IPComp, because it gets 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 keeps per-connection info like connection state, current round-trip time, congestion control or maximum segment size 📦 Sharing that info between two consecutive connections, or when a new connection is made while the first is still active to the same host, may improve performance of the latter connection ✨ The idea could easily stretch to sharing info amongst systems in a LAN, not just within a single 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, to read their email or start connections to other servers, the devices may be configured to always use the same email server or WWW proxy. The main advantage here is that it relieves the application of the burden of optimizing the transport layer 🫶 To improve TCP performance, 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 🔥

The table below sums up our recommendations for the main proposals mentioned above 📋

The first column, "Stability of the Proposal," refers to how mature the mechanism is. Some proposals are being pursued within the IETF in a somewhat open fashion. An IETF proposal is either an Internet Draft (I-D) or a Request for Comments (RFC). The former is a preliminary version. There are several types of RFCs. A Draft Standard (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 shows whether implementation happens at either or both of the two nodes under some control: mobile device and intermediate node. The symbols are: WS (wireless sender, meaning the mobile device's TCP send operation must be modified), WR (wireless receiver, meaning the mobile device's TCP receive operation must be modified), WD (wireless device, meaning 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      RFC 2581 (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             RFC 1144 (PS)    WD            Yes
compression for PPP                     IN            (see 4.11)

IP Payload             RFC 2393 (PS)    WD            Yes
Compression                             (simultaneously
(IPComp)                                needed on Server)

Header                 RFC 2507 (PS),   WD            Yes
Compression            RFC 2509 (PS)    IN            (For IPv4, TCP and
                                                      Mobile IP, PPP)

SNOOP plus SACK        In limited use   IN            Yes
                                        WD (for SACK)

Fast retransmit/fast   RFC 2581 (PS)    WD            Yes (should be
recovery                                              there already)

Transaction/TCP        RFC 1644         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    RFC 2481 (EXP)   WD            Yes

Notification                            NI

TCP Control Block      RFC 2140         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, and 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've 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 also provided valuable feedback: Mark Allman (NASA), Vern Paxson (ACIRI), Raphi Rom (Technion/Sun), Charlie Perkins (Nokia), Peter Stark (Phone.com) ✨

8 Security Considerations 💀🔐

okay this section is serious bestie, so pay attention 🥺

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, here's 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 on 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 let, for example, a SNOOP module, header compression (TCP, UDP, RTP, etc), or HTTP proxies 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, RFC 2488, January 1999.
  • [Allman98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998.

okay bestie, the citations are where the receipts live 📚💅

  • [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)", RFC 2393, December 1998.
  • [IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
  • [IPHC-RTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
  • [IPHC-PPP] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, 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", RFC 2309, 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", RFC 908, July 1984.
  • [RFC1030] Lambert, M., "On Testing the NETBLT Protocol over Divers Networks", RFC 1030, November 1987.
  • [RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989. 🎀
  • [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
  • [RFC1151] Partridge, C., Hinden, R., "Version 2 of the Reliable Data Protocol (RDP)", RFC 1151, April 1990.
  • [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
  • [RFC1397] Braden, R., "Extending TCP for Transactions -- Concepts", RFC 1397, November 1992.
  • [RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994. 🧚

Okay bestie, the receipts drawer is next 🧾✨ Every source this spec leans on is listed below, word for word, so you can go check any of them yourself 💅

   [RFC1661]      Simpson, W., "The Point-To-Point Protocol (PPP)", STD
                  51, RFC 1661, July 1994.

   [RFC1928]      Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.
                  and L. Jones, "SOCKS Protocol Version 5", RFC 1928,
                  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)", RFC 1986, August 1996.

   [RFC2002]      Perkins, C., "IP Mobility Support", RFC 2002, October
                  1996.

   [RFC2003]      Perkins, C., "IP Encapsulation within IP", RFC 2003,
                  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", RFC 2018,
                  October 1996.

   [RFC2188]      Banan, M., Taylor, M. and J. Cheng, "AT&T/Neda's
                  Efficient Short Remote Operations (ESRO) Protocol
                  Specification Version 1.2", RFC 2188, 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", RFC 2414, September 1998.

   [RFC2415]      Poduri, K.and K. Nichols, "Simulation Studies of
                  Increased Initial TCP Window Size", RFC 2415,
                  September 1998.

   [RFC2416]      Shepard, T. and C. Partridge, "When TCP Starts Up With
                  Four Packets Into Only Three Buffers", RFC 2416,
                  September 1998.

   [RFC2581]      Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
                  Control", RFC 2581, April 1999.

   [RFC2582]      Floyd, S. and T. Henderson, "The NewReno Modification
                  to TCP's Fast Recovery Algorithm", RFC 2582, 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", RFC 1323, 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", RFC 1045, February 1988.

   [WAP]          Wireless Application Protocol Forum.
                  http://www.wapforum.org/

   [WC91]         Wang, Z., Crowcroft, J., "A New Congestion Control
                  Scheme:  Slow Start and Search," ACM Computer
                  Communication Review, vol 21, pp 32-43, January 1991.

   [WTCP]         Ratnam, K., Matta, I., "WTCP: An Efficient
                  Transmission Control Protocol for Networks with
                  Wireless Links," Technical Report NU-CCS-97-11,
                  Northeastern University, July 1997. Available at:
                  http://www.ece.neu.edu/personal/karu/papers/WTCP-
                  NU.ps.gz

   [YB94]         Yavatkar, R., Bhagawat, N., "Improving End-to-End
                  Performance of TCP over Mobile Internetworks," Proc.
                  Workshop on Mobile Computing Systems and Applications,
                  IEEE Computer Society Press, Los Alamitos, California,
                  1994.

Authors' Addresses ✨

Questions about this document may be directed at these lovely people 🎀

   Gabriel E. Montenegro
   Sun Labs Networking and Security Group
   Sun Microsystems, Inc.
   901 San Antonio Road
   Mailstop UMPK 15-214
   Mountain View, California 94303

   Phone: +1-650-786-6288
   Fax:   +1-650-786-6445
   EMail: gab@sun.com


   Spencer Dawkins
   Nortel Networks
   P.O. Box 833805
   Richardson, Texas 75083-3805

   Phone: +1-972-684-4827
   Fax:   +1-972-685-3292
   EMail: sdawkins@nortel.com
   Markku Kojo
   Department of Computer Science
   University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   FIN-00014 HELSINKI
   Finland

   Phone: +358-9-1914-4179
   Fax:   +358-9-1914-4441
   EMail: kojo@cs.helsinki.fi


   Vincent Magret
   Corporate Research Center
   Alcatel Network Systems, Inc
   1201 Campbell
   Mail stop 446-310
   Richardson Texas 75081 USA
   M/S 446-310

   Phone: +1-972-996-2625
   Fax:   +1-972-996-5902
   EMail: vincent.magret@aud.alcatel.com


   Nitin Vaidya
   Dept. of Computer Science
   Texas A&M University
   College Station, TX 77843-3112

   Phone: 979-845-0512
   Fax: 979-847-8578
   EMail: vaidya@cs.tamu.edu

The legal bits stay exactly as written, no edits, because this one is not up for remixing 🙈

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Last but not least, the funding shoutout 🌈

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
📦 where this page comes from