RFC 2760

RFC 2760: Ongoing TCP Research Related to Satellites 🛰️✨

Okay bestie, let's start with the basics 🎀

• Series and number: RFC 2760, from the Network Working Group
• Title: Ongoing TCP Research Related to Satellites
• Editor: M. Allman, from NASA Glenn Research Center/BBN Technologies
• Other authors: S. Dawkins (Nortel), D. Glover, J. Griner, and D. Tran (NASA Glenn Research Center), T. Henderson (University of California at Berkeley), J. Heidemann and J. Touch (University of Southern California/ISI), H. Kruse and S. Ostermann (Ohio University), K. Scott (The MITRE Corporation), and J. Semke (Pittsburgh Supercomputing Center)
• Category: Informational
• Date: February 2000
• Obsoletes and updates: this title block doesn't list anything it obsoletes or updates 💅

---

Status of this Memo 💖

This memo is here to give info to the Internet community. It doesn't specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice 🌸

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

Abstract ✨

So this doc is all about possible TCP upgrades that may help TCP make better use of the bandwidth on networks with satellite links 🛰️ The algorithms and mechanisms in here haven't been judged mature enough for the IETF to recommend yet, so the goal is to educate researchers on the current TCP research and progress happening around satellite networks 🧚

Table of Contents 🍓

1         Introduction. . . . . . . . . . . . . . . . . . . .  2
2         Satellite Architectures . . . . . . . . . . . . . .  3
2.1       Asymmetric Satellite Networks . . . . . . . . . . .  3
2.2       Satellite Link as Last Hop. . . . . . . . . . . . .  3
2.3       Hybrid Satellite Networks     . . . . . . . . . . .  4
2.4       Point-to-Point Satellite Networks . . . . . . . . .  4
2.5       Multiple Satellite Hops . . . . . . . . . . . . . .  4
3         Mitigations . . . . . . . . . . . . . . . . . . . .  4
3.1       TCP For Transactions. . . . . . . . . . . . . . . .  4
3.2       Slow Start. . . . . . . . . . . . . . . . . . . . .  5
3.2.1     Larger Initial Window . . . . . . . . . . . . . . .  6
3.2.2     Byte Counting . . . . . . . . . . . . . . . . . . .  7
3.2.3     Delayed ACKs After Slow Start . . . . . . . . . . .  9
3.2.4     Terminating Slow Start. . . . . . . . . . . . . . . 11
3.3       Loss Recovery . . . . . . . . . . . . . . . . . . . 12
3.3.1     Non-SACK Based Mechanisms . . . . . . . . . . . . . 12
3.3.2     SACK Based Mechanisms . . . . . . . . . . . . . . . 13
3.3.3     Explicit Congestion Notification. . . . . . . . . . 16
3.3.4     Detecting Corruption Loss . . . . . . . . . . . . . 18
3.4       Congestion Avoidance. . . . . . . . . . . . . . . . 21
3.5       Multiple Data Connections . . . . . . . . . . . . . 22
3.6       Pacing TCP Segments . . . . . . . . . . . . . . . . 24
3.7       TCP Header Compression. . . . . . . . . . . . . . . 26
3.8       Sharing TCP State Among Similar Connections . . . . 29
3.9       ACK Congestion Control. . . . . . . . . . . . . . . 32
3.10      ACK Filtering . . . . . . . . . . . . . . . . . . . 34
4         Conclusions . . . . . . . . . . . . . . . . . . . . 36
5         Security Considerations . . . . . . . . . . . . . . 36
6         Acknowledgments . . . . . . . . . . . . . . . . . . 37
7         References. . . . . . . . . . . . . . . . . . . . . 37
8         Authors' Addresses. . . . . . . . . . . . . . . . . 43
9         Full Copyright Statement. . . . . . . . . . . . . . 46

---

1. Introduction 🎀

Okay so this doc lays out mechanisms that may help the Transmission Control Protocol (TCP) [Pos81] make better use of the bandwidth you get over long-delay satellite environments 🦋 These mechanisms may also help in other environments or for other protocols, which is kinda iconic. The proposals here are still being studied all over the research community, so they're not mature enough for the IETF to recommend for wide-spread use yet. BUT some of them may be safely used today ✨ The hope is that this doc sparks more study into the mechanisms it describes. If, at some point, they prove safe and appropriate for general use, the right IETF documents will get written 💅

Also, non-TCP mechanisms that help performance over satellite links do exist (think application-level changes, queueing disciplines, etc.) 🧚 Outlining those non-TCP fixes is beyond the scope of this doc, so it's left as future work. There are also a bunch of TCP performance fixes that involve very active intervention by gateways along the end-to-end path from sender to receiver. Documenting the pros and cons of those is left as future work too 🫶

2. Satellite Architectures 🛰️

The specific characteristics of satellite links, and how they affect TCP, are covered in RFC 2488 [AGS99] 💖 This section walks through several possible topologies where satellite links may be integrated into the global Internet. The mitigation outlined in section 3 will talk about which environment the mechanism is expected to benefit.

2.1. Asymmetric Satellite Networks 🌈

Some satellite networks have a bandwidth asymmetry, meaning a bigger data rate in one direction than the reverse. That happens because of limits on the transmission power and antenna size at one end of the link 📡 Meanwhile, some other satellite systems are unidirectional and use a non-satellite return path, like a dialup modem link 🙈 Most TCP traffic is already asymmetric, with data flowing one way and acknowledgments going the opposite way. But in this document, "asymmetric" specifically means different physical capacities on the forward and return links. And asymmetry has been shown to be a problem for TCP [BPK97,BPK98] 😭

2.2. Satellite Link as Last Hop 🏡

Satellite links that serve end users directly (as opposed to satellite links sitting in the middle of a network) may allow for specialized protocol design over the last hop 💜 Some satellite providers use the satellite link as a shared high-speed downlink to users. The return link is a lower-speed, non-shared terrestrial link that carries requests and acknowledgments. Lots of the time this makes an asymmetric network, like we talked about above 🔥

2.3. Hybrid Satellite Networks 🌸

In the more general case, a satellite link can sit at any point in the network topology. Here the satellite link acts as just another link between two gateways 🧚 In this setup, a given connection may be sent over terrestrial links (including terrestrial wireless) as well as satellite links. On the other hand, a connection could also travel only over the terrestrial network, or only over the satellite portion of the network 💖

2.4. Point-to-Point Satellite Networks 🛰️

In point-to-point satellite networks, the only hop is the satellite link itself. This pure satellite environment only has the problems associated with satellite links, as outlined in [AGS99] 🎀 Since it's a private network, some mitigations that wouldn't be appropriate for shared networks can be considered 👑

2.5. Multiple Satellite Hops ✨

Sometimes network traffic traverses multiple satellite hops between source and destination. That kind of environment makes the satellite characteristics described in [AGS99] even worse 😭

3. Mitigations 🦋

The next sections talk about various techniques for mitigating the problems TCP faces in the satellite environment ✨ Each section is organized the same way. First, each mitigation gets briefly outlined. Next, research involving the mechanism gets briefly discussed. Then come the implementation issues (including whether or not the mechanism poses any dangers to shared networks). After that, there's a discussion of the mechanism's potential with regard to the topologies we just covered. Finally, the relationships and possible interactions with other TCP mechanisms get outlined 💅 The reader is expected to already know the TCP terminology used in [AGS99] 🤓

3.1. TCP For Transactions 💖

3.1.1. Mitigation Description 🌷

TCP uses a three-way handshake to set up a connection between two hosts [Pos81] 🤝 That setup takes 1-1.5 round-trip times (RTTs), depending on whether the data sender started the connection actively or passively. This startup time can be eliminated by using TCP extensions for transactions (T/TCP) [Bra94] 🎀 Once the first connection between a pair of hosts is established, T/TCP can skip the three-way handshake. That lets the data sender start transmitting data in the very first segment, right along with the SYN 🚀 This is especially helpful for short request/response traffic, because it saves a potentially long setup phase when no useful data is moving yet 🙌

3.1.2. Research 📚

T/TCP is outlined and analyzed in [Bra92,Bra94] 🧠

3.1.3. Implementation Issues 🛠️

T/TCP needs changes in the TCP stacks of both the data sender and the data receiver 👀 T/TCP is safe to implement in shared networks from a congestion control perspective. But several security implications of sending data in the first data segment have been identified [ddKI99] 😬

⚠️ Heads up: the security implications of putting data in that first segment are real, so read [ddKI99] before you implement anything 🔐

3.1.4. Topology Considerations 🌍

T/TCP is expected to be equally beneficial in all of the environments outlined in section 2 🌈

3.1.5. Possible Interaction and Relationships with Other Research 🫶

T/TCP lets data transfer start more rapidly, kind of like using a larger initial congestion window (see section 3.2.1), delayed ACKs after slow start (section 3.2.3), or byte counting (section 3.2.2) 💜

3.2 Slow Start ✨

okay so slow start is the algorithm that gently ramps up TCP's congestion window (cwnd) [Jac88,Ste97,APS99] 🌸 it's basically the bouncer at the door, making sure you don't shove an inappropriate amount of data into the network the second a connection wakes up 💅 but ngl it can also waste capacity that's just sitting there, especially on long-delay networks [All97a,Hay97] 😭 it's extra inefficient for transfers that are short compared to the delay*bandwidth product of the network (think WWW transfers) 🫶

delayed ACKs are another sneaky source of wasted capacity during slow start 🙈 RFC 1122 [Bra89] suggests that data receivers hold off on ACKing every single incoming data segment, but every second full-sized segment should still get an ACK 🎀 if a second full-sized segment doesn't show up before a timeout, an ACK has to go out anyway (and that timeout can't be longer than 500 ms ⏱️). here's the tea: the sender grows cwnd based on how many ACKs come back, so fewer ACKs means cwnd grows slower 🐢 and when TCP first starts sending, it sends 1 segment. with delayed ACKs, a second segment has to arrive before anything is ACKed, so the receiver is always stuck waiting for the delayed ACK timer to run out before it ACKs that first segment, which makes the whole transfer take longer too 💀

there have been a bunch of proposals for making slow start less time consuming 🦋 here's a quick rundown, with the research linked for each one ✨

3.2.1 Larger Initial Window

3.2.1.1 Mitigation Description

one way to cut the time slow start eats up (and therefore the wasted capacity) is to bump up the initial value of cwnd 🚀 an experimental TCP extension outlined in [AFP98] lets the initial size of cwnd go up from 1 segment to whatever equation (1) gives you 👑

               min (4*MSS, max (2*MSS, 4380 bytes))               (1)

so the bigger initial cwnd means more packets get sent during the first RTT of data transmission, which triggers more ACKs, and that lets the congestion window open up faster 🏃‍♀️ plus, by sending at least 2 segments at the start, the first segment doesn't have to sit around waiting for the delayed ACK timer to expire like it does when the initial cwnd is 1 segment (as we talked about above) 🌈 so the cwnd value from equation 1 saves up to 3 RTTs and a delayed ACK timeout compared to an initial cwnd of 1 segment 🎉

also, RFC 2581 [APS99], which is a standards-track document, lets a TCP use an initial cwnd of up to 2 segments ✨ and this change is highly recommended for satellite networks 🛰️💖

3.2.1.2 Research

a bunch of researchers have looked at using a larger initial window in different environments 🔍 [Nic97] and [KAGT98] show a reduction in WWW page transfer time over hybrid fiber coax (HFC) and satellite links, respectively 🙌 it's also been shown that an initial cwnd of 4 segments doesn't hurt overall performance over dialup modem links with a small number of buffers [SP98] 🧚 [AHO98] shows transfer time improving for 16 KB files across the Internet and dialup modem links with a larger initial cwnd, but there was also a slight increase in dropped segments, so not totally flawless 🙈 and finally, [PN98] shows improved transfer time for WWW traffic in simulations with competing traffic, plus a small increase in the drop rate 🍓

3.2.1.3 Implementation Issues

using a larger initial cwnd value means changing the sender's TCP stack 🛠️ an initial congestion window of 2 segments is allowed by RFC 2581 [APS99] ✅ an initial congestion window of 3 or 4 segments isn't expected to be dangerous in terms of congestion collapse [AFP98], but it may degrade performance in some networks ⚠️

3.2.1.4 Topology Considerations

a large initial window is expected to be equally beneficial across all the network architectures outlined in section 2 🌍💜

3.2.1.5 Possible Interaction and Relationships with Other Research

using a fixed, larger initial congestion window reduces how much a long RTT hurts transfer time (especially for short transfers), but the cost is bursting data into a network whose conditions are unknown 💥 a mechanism that mitigates bursts might make a larger initial congestion window more appropriate, like limiting the size of line-rate bursts [FF96] or pacing the segments in a burst [VH97a] 🎀

also, using delayed ACKs only after slow start (as outlined in section 3.2.3) is another way to immediately ACK the first segment of a transfer and open the congestion window more rapidly 🦋 and finally, using some form of TCP state sharing among a number of connections (as discussed in 3.8) might offer an alternative to a fixed larger initial window 🫶

3.2.2 Byte Counting

3.2.2.1 Mitigation Description

as discussed above, widespread use of delayed ACKs slows down how fast a TCP sender grows the congestion window during slow start 😭 this is especially painful for flows crossing long-delay GEO satellite links 🛰️ one mechanism suggested to fix the delayed ACK problem is "byte counting," which replaces standard ACK counting [All97a,All98] 💅 with standard ACK counting, cwnd goes up by 1 segment for each ACK received during slow start 🌸 with byte counting, the cwnd increase is based on the number of previously unacknowledged bytes covered by each incoming ACK, not on how many ACKs showed up 🙌 so the increase tracks the amount of data sent, instead of depending on the ACK interval the receiver uses 💖

two forms of byte counting are studied in [All98] 🔍 the first is unlimited byte counting (UBC), which just uses the number of previously unacknowledged bytes to increase the congestion window every time an ACK arrives 💥 the second is limited byte counting (LBC), which caps the cwnd increase at 2 segments 🧢 that cap keeps the burst of data sent in response to a "stretch ACK" [Pax97] from getting too big 🎀 stretch ACKs are acknowledgments that cover more than 2 segments of previously unacknowledged data 📦 they can happen by design [Joh95] (though that isn't standard), because of implementation bugs [All97b,PADHV99], or because an ACK got lost 😬 [All98] shows that LBC prevents large line-rate bursts compared to UBC, so it offers fewer dropped segments and better performance ✨ UBC also causes large bursts during slow start-based loss recovery, thanks to the big cumulative ACKs that can arrive during loss recovery 🌪️ UBC's behavior during loss recovery can cause large drops in performance, and [All98] strongly recommends not deploying UBC without further study into mitigating those large bursts 🚫

Note: the standards track RFC 2581 [APS99] lets a TCP use byte counting to increase cwnd during congestion avoidance, but not during slow start. 📌

3.2.2.2 Research

byte counting (as opposed to standard ACK counting) has been shown to reduce the time needed to grow cwnd to an appropriate size in satellite networks [All97a] 🛰️💫 on top of that, [All98] runs a simulation comparing byte counting with the standard cwnd increase algorithm in uncongested networks and in networks with competing traffic 🔬 the study found that the limited form of byte counting described above can improve performance, though it also bumps up the drop rate slightly 🍓

[BPK97,BPK98] also looked at unlimited byte counting together with various ACK filtering algorithms (discussed in section 3.10) in asymmetric networks 🦋

3.2.2.3 Implementation Issues

switching from ACK counting to byte counting means changing the data sender's TCP stack 🛠️ byte counting also breaks the algorithm for increasing the congestion window that's outlined in RFC 2581 [APS99], since it makes cwnd growth more aggressive during slow start 😤 so it should not be used in shared networks 🚫

3.2.2.4 Topology Considerations

some people have suggested (and others have roundly criticized the idea) that byte counting lets TCP provide a uniform cwnd increase, no matter how the receiver ACKs 🤷‍♀️ byte counting also helps with the stunted window growth that receivers producing stretch ACKs cause because of the capacity of the return link, as discussed in [BPK97,BPK98] 💅 so this change is expected to be especially beneficial to asymmetric networks 🌈

3.2.2.5 Possible Interaction and Relationships with Other Research

unlimited byte counting should not be used without a method to mitigate the potentially large line-rate bursts the algorithm can cause 🚨 LBC might also send bursts that are too large for the given network conditions 💥 in that case, LBC could also benefit from an algorithm that lessens the impact of line-rate bursts of segments 🎀 and note that using delayed ACKs only after slow start (as outlined in section 3.2.3) negates the limited byte counting algorithm, because each ACK covers only one segment during slow start 🙃 so both ACK counting and byte counting yield the same increase in the congestion window at that point (in the first RTT) 🫶

3.2.3 Delayed ACKs After Slow Start

3.2.3.1 Mitigation Description

as discussed above, TCP senders use the number of incoming ACKs to increase the congestion window during slow start 🌸 and since delayed ACKs cut the number of ACKs the receiver returns by roughly half, cwnd grows more slowly 🐌 one proposed fix is to use delayed ACKs only after the slow start (DAASS) phase 🧚 this gives more ACKs while TCP is aggressively growing the congestion window, and fewer ACKs while TCP is in steady state, which conserves network resources ♻️ very efficient, very iconic 👑

3.2.3.2 Research

[All98] shows that, in simulation, using delayed ACKs after slow start (DAASS) improves transfer time compared to a receiver that always generates delayed ACKs 📈 however, DAASS also slightly increases the loss rate because cwnd grows faster 🙈

3.2.3.3 Implementation Issues

the major problem with DAASS is implementation 😭 the receiver has to somehow know when the sender is using the slow start algorithm 🕵️‍♀️ the receiver could run a heuristic that watches how the amount of data being received changes and adjusts its ACKing behavior to match 🧠 or the sender could send a message (maybe a flipped bit in the TCP header 🎀) indicating that it's using slow start 💌 so the implementation of DAASS is, for now, an open issue 🔓

using DAASS doesn't violate the TCP congestion control specification [APS99] ✅ however, the standards (RFC 2581 [APS99]) currently recommend using delayed acknowledgments, and DAASS goes (partially) against that recommendation 🫠

3.2.3.4 Topology Considerations

DAASS should work equally well in all the scenarios presented in section 2 🌍 however, in asymmetric networks it may make ACK congestion on the return link worse, because of the increased number of ACKs (see sections 3.9 and 3.10 for a more detailed discussion of ACK congestion) 🛰️💅

3.2.3.5 Possible Interaction and Relationships with Other Research

okay so DAASS has a bunch of possible interactions with other proposals in the research community 👀. DAASS can aggravate congestion on the path between the data receiver and the data sender because it sends back more returning acknowledgments 🫠. This can be an especially rough deal on asymmetric networks that are prone to ACK congestion 💀. As outlined in sections 3.9 and 3.10, several mitigations have been proposed to reduce the number of ACKs that get passed over a low-bandwidth return link ✨. Using DAASS increases the number of ACKs sent by the receiver, and how DAASS interacts with those ACK-reducing methods is still an open research question 🔍. Also, as noted in section 3.2.1.5 above, DAASS gives you some of the same benefits as using a larger initial congestion window, so it may not be desirable to use both mechanisms together 🤔. However, this remains an open question. Finally, DAASS and limited byte counting are both used to increase the rate at which the congestion window is opened, and the DAASS algorithm substantially reduces the impact limited byte counting has on that rate of congestion window increase 💅🎀

3.2.4 Terminating Slow Start 🛑✨

3.2.4.1 Mitigation Description

okay this one is giving main character energy 👑. The initial slow start phase is how TCP figures out an appropriate congestion window size for the current network conditions [Jac88] 🧠. Slow start ends when TCP detects congestion, or when the size of cwnd reaches the size of the receiver's advertised window. It also ends if cwnd grows beyond a certain size 🙈. The threshold where TCP stops slow start and switches to the congestion avoidance algorithm is called "ssthresh" [Jac88] 💜. In most implementations, the initial value for ssthresh is the receiver's advertised window. During slow start, TCP roughly doubles cwnd every RTT, so it can overwhelm the network with at most twice as many segments as the network can handle 😭. By setting ssthresh to a value that's less than the receiver's advertised window at the start, the sender may avoid overwhelming the network with twice the appropriate number of segments 🫶.

Hoe [Hoe96] proposes using the packet-pair algorithm [Kes91] together with the measured RTT to figure out a more appropriate value for ssthresh 🔥. The algorithm watches the spacing between the first few returning ACKs to work out the bandwidth of the bottleneck link. Combine that with the measured RTT and you get the delay*bandwidth product, and ssthresh gets set to that value 🌈. When TCP's cwnd reaches this reduced ssthresh, slow start ends and transmission continues using congestion avoidance, which is a more conservative algorithm for increasing the size of the congestion window 🦋.

3.2.4.2 Research

ngl the research here is kind of a plot twist 👀. It has been shown that estimating ssthresh can improve performance and decrease packet loss in simulations [Hoe96]. However, getting an accurate estimate of the available bandwidth in a dynamic network is very challenging, especially when you try to do it on the sending side of the TCP connection [AP99] 😩. So before this mechanism is widely deployed, bandwidth estimation needs to be studied in more detail 🔍.

3.2.4.3 Implementation Issues

okay the implementation side is where things get a little messy 🙃. As outlined in [Hoe96], estimating ssthresh requires changes to the data sender's TCP stack. As suggested in [AP99], bandwidth estimates may be more accurate when they're taken by the TCP receiver, so both sender and receiver changes would be required 🤝. Estimating ssthresh is safe to implement in production networks from a congestion control perspective 🫡, since it can only make TCP more conservative than outlined in RFC 2581 [APS99] (assuming the TCP implementation is using an initial ssthresh of infinity, as allowed by [APS99]) ✨.

3.2.4.4 Topology Considerations

it's expected that this mechanism will work equally well in all symmetric topologies outlined in section 2 🌸. But asymmetric links are a special problem, because the rate of the returning ACKs may not be the bottleneck bandwidth in the forward direction 😬. This can lead to the sender setting ssthresh too low. Ending slow start too early can hurt performance, since congestion avoidance opens cwnd more conservatively 💀. Receiver-based bandwidth estimators don't suffer from this problem 💅.

3.2.4.5 Possible Interaction and Relationships with Other Research

terminating slow start at the right time is useful for avoiding multiple dropped segments 🎀. However, using a selective acknowledgment-based loss recovery scheme (as outlined in section 3.3.2) can drastically improve TCP's ability to quickly recover from multiple lost segments. Therefore, it may not be as important to terminate slow start before a large loss event occurs 🫶. [AP99] shows that using delayed acknowledgments [Bra89] reduces the effectiveness of sender-side bandwidth estimation 📉. So using delayed ACKs only during slow start (as outlined in section 3.2.3) may make bandwidth estimation more feasible 🦋.

---

3.3 Loss Recovery 🛠️💖

3.3.1 Non-SACK Based Mechanisms 🌷

3.3.1.1 Mitigation Description

so there are a few similar algorithms that have been developed and studied, and they're all about helping TCP recover from multiple lost segments in a window of data 🥹. The goal is to do this without relying on the (often long) retransmission timeout ⏳. These sender-side algorithms are known as NewReno TCP, and they don't depend on the availability of selective acknowledgments (SACKs) [MMFR96] 🙌.

These algorithms generally work by updating the fast recovery algorithm to use information provided by "partial ACKs" to trigger retransmissions 🔁. A partial ACK covers some new data, but not all of the data that was outstanding when a particular loss event started 🧩. For example, say segment N gets retransmitted using the fast retransmit algorithm, and segment M is the last segment sent when segment N is resent. If segment N is the only segment lost, the ACK elicited by the retransmission of segment N would be for segment M. But if segment N+1 was also lost, the ACK elicited by the retransmission of segment N will be N+1. That can be taken as an indication that segment N+1 was lost, and it can be used to trigger a retransmission 🕵️‍♀️✨.

3.3.1.2 Research

Hoe [Hoe95,Hoe96] introduced the idea of using partial ACKs to trigger retransmissions and showed that doing so could improve performance 🌟. [FF96] shows that in some cases, using partial ACKs to trigger retransmissions reduces the time needed to recover from multiple lost segments ⏱️. However, [FF96] also shows that in some cases (like when many segments are lost), relying on the RTO timer can improve performance over simply using partial ACKs to trigger all retransmissions 🤷‍♀️. [HK99] shows that using partial ACKs to trigger retransmissions, in conjunction with SACK, improves performance compared to TCP using fast retransmit/fast recovery in a satellite environment 🛰️. Finally, [FH99] describes several slightly different variants of NewReno 🎀.

3.3.1.3 Implementation Issues

implementing these fast recovery enhancements requires changes to the sender-side TCP stack 🧑‍💻. These changes can safely be implemented in production networks and are allowed by RFC 2581 [APS99] ✅.

3.3.1.4 Topology Considerations

it's expected that these changes will work well in all environments outlined in section 2 🌈.

3.3.1.5 Possible Interaction and Relationships with Other Research

see section 3.3.2.2.5 👀.

3.3.2 SACK Based Mechanisms 🧁

3.3.2.1 Fast Recovery with SACK

3.3.2.1.1 Mitigation Description

Fall and Floyd [FF96] describe a conservative extension to the fast recovery algorithm that takes into account information provided by selective acknowledgments (SACKs) [MMFR96] sent by the receiver 🦢. The algorithm starts after fast retransmit triggers the resending of a segment. Just like with fast retransmit, the algorithm cuts cwnd in half when a loss is detected ✂️. It keeps a variable called pipe, which is an estimate of the number of outstanding segments in the network 🧮. The pipe variable is decremented by 1 segment for each duplicate ACK that arrives with new SACK information, and it's incremented by 1 for each new or retransmitted segment sent 📊. A segment may be sent when the value of pipe is less than cwnd. That segment is either a retransmission according to the SACK information, or a new segment if the SACK information says no more retransmits are needed 🎯.

This algorithm generally lets TCP recover from multiple segment losses in a window of data within one RTT of loss detection 🚀. Like the forward acknowledgment (FACK) algorithm described below, the SACK information lets the pipe algorithm decouple the choice of when to send a segment from the choice of what segment to send 🧠✨.

[APS99] allows the use of this algorithm, since it's consistent with the spirit of the fast recovery algorithm 💖.

3.3.2.1.2 Research

[FF96] shows that the SACK algorithm described above performs better than several non-SACK based recovery algorithms when 1--4 segments are lost from a window of data 🥇. [AHKO97] shows that the algorithm improves performance over satellite links 🛰️. Hayes [Hay97] shows the in certain circumstances, the SACK algorithm can hurt performance by generating a large line-rate burst of data at the end of loss recovery, which causes further loss 😭💔.

3.3.2.1.3 Implementation Issues

this algorithm is implemented in the sender's TCP stack, but it relies on SACK information generated by the receiver 🤝. It's safe for shared networks and is allowed by RFC 2581 [APS99] 🫶.

3.3.2.1.4 Topology Considerations

it's expected that the pipe algorithm will work equally well in all scenarios presented in section 2 🌸.

3.3.2.1.5 Possible Interaction and Relationships with Other Research

see section 3.3.2.2.5 🙈.

3.3.2.2 Forward Acknowledgments 🦋

3.3.2.2.1 Mitigation Description ✨

okay so the Forward Acknowledgment (FACK) algorithm [MM96a,MM96b] was built to make TCP congestion control better during loss recovery 💅 it uses the TCP SACK options to glean extra info about the congestion state, which gives you way more precise control over how new data gets injected into the network during recovery 🎀 FACK decouples the congestion control algorithms from the data recovery algorithms, so there's a simple, direct way to use SACK to improve congestion control. bc of that separation, new data can be sent during recovery to keep TCP's self-clock going when there's nothing left to retransmit 🦋

the most recent version of FACK is Rate-Halving [MM96b], where you send one packet for every two ACKs received during recovery 🌸 sending a segment for every-other ACK cuts the congestion window in one round trip down to half the number of packets the network actually handled (so even when cwnd is too large by more than a factor of two, it still gets reduced to half of what the network can sustain) 😭 and this is the part that's lowkey iconic: Rate-Halving keeps the ACK self-clock running during recovery, because sending a packet for every-other ACK doesn't need half a cwnd of data to drain out of the network before you transmit. the fast recovery algorithm does need that [Ste97,APS99] 🙈

FACK with Rate-Halving also gives each lost segment Thresholded Retransmission 🧚 "Tcprexmtthresh" is the number of duplicate ACKs TCP needs before it triggers a fast retransmit and enters recovery. FACK applies thresholded retransmission to all segments by waiting until tcprexmtthresh SACK blocks show that a given segment is missing before resending it. this lets things behave reasonably on links that reorder segments 💜 like we said above, FACK sends a segment for every second ACK received during recovery. new segments are transmitted, except when tcprexmtthresh SACK blocks have been observed for a dropped segment, and then that dropped segment gets retransmitted ✨

[APS99] allows the use of this algorithm, since it's consistent with the spirit of the fast recovery algorithm 👑

3.3.2.2.2 Research 🔬

the original FACK algorithm is outlined in [MM96a] 🌈 it was later enhanced to include Rate-Halving [MM96b] ✨ the real-world performance of FACK with Rate-Halving was shown to be way closer to the theoretical maximum for TCP than either TCP Reno or the SACK-based extensions to fast recovery outlined in section 3.3.2.1 [MSMO97] 🔥 literally a glow-up 💖

3.3.2.2.3 Implementation Issues 🛠️

to use FACK, the sender's TCP stack has to be modified 🫶 the receiver also has to be able to generate SACK options to get the full benefit of FACK. the FACK algorithm is safe for shared networks and is allowed by RFC 2581 [APS99] 🍓

3.3.2.2.4 Topology Considerations 🗺️

FACK is expected to improve performance in all the environments outlined in section 2 🌸 since it's better at sustaining its self-clock than TCP Reno, it may be considerably more attractive over long delay paths 🦋 long-distance paths really need it fr fr 💅

3.3.2.2.5 Possible Interaction and Relationships with Other Research 🧩

both SACK-based loss recovery algorithms described above (the fast recovery enhancement and the FACK algorithm) are similar in that they try to effectively repair multiple lost segments from one window of data 💜 which of the SACK-based loss recovery algorithms to use is still an open research question 🙈 these algorithms are also similar to the non-SACK NewReno algorithm described in section 3.3.1, in that they try to recover from multiple lost segments without falling back on the retransmission timer ⭐ as has been shown, the SACK-based algorithms above are more robust than NewReno. BUT the SACK algorithm needs a cooperating TCP receiver, and NewReno doesn't ngl 😭 a reasonable TCP implementation might include both a SACK-based and a NewReno-based loss recovery algorithm, so the sender can use whichever one fits best depending on whether or not the receiver supports SACKs 🎀 finally, both SACK-based and non-SACK-based versions of fast recovery have been shown to transmit a large burst of data upon leaving loss recovery, in some cases [Hay97] 💀 so these algorithms may benefit from some burst suppression algorithm 🫶

---

3.3.3 Explicit Congestion Notification 🚦

3.3.3.1 Mitigation Description 🌈

okay so explicit congestion notification (ECN) lets routers tell TCP senders about imminent congestion without dropping segments 🦋 two major forms of ECN have been studied. a router using backward ECN (BECN) sends messages directly to the data originator to tell it about the congestion 💖 IP routers can do this with an ICMP Source Quench message. a BECN signal may or may not mean a TCP data segment got dropped, but it's a clear sign that the TCP sender should reduce its sending rate (i.e., the value of cwnd) 🙌 the second major form is forward ECN (FECN). FECN routers mark data segments with a special tag when congestion is imminent, but they still forward the segment 🧚 then the data receiver echos the congestion info back to the sender in the ACK packet 🍓 a FECN mechanism for TCP/IP is described in [RF99] ✨

as described in [RF99], senders transmit segments with an "ECN-Capable Transport" bit set in the IP header of each packet 💅 if a router using an active queueing strategy, like Random Early Detection (RED) [FJ93,BCC+98], would otherwise drop the segment, a "Congestion Experienced" bit in the IP header gets set instead 🌸 when it's received, the information is echoed back to TCP senders using a bit in the TCP header 💜 the TCP sender then adjusts the congestion window just like it would if a segment had been dropped 👑

the ECN implementation specified in [RF99] requires active queue management mechanisms to be deployed in the affected routers 🔥 this lets routers signal congestion by sending TCP a small number of "congestion signals" (segment drops or ECN messages), instead of discarding a whole pile of segments, which can happen when TCP overwhelms a drop-tail router queue 😭

satellite networks generally have higher bit-error rates than terrestrial networks 🛰️ so figuring out whether a segment was lost to congestion or to corruption might let TCP perform better in high BER environments than it can now (because TCP assumes all loss is due to congestion). ECN isn't a solution to this problem by itself, but adding an ECN mechanism to TCP may be part of a mechanism that helps get there 🦋 see section 3.3.4 for a more detailed discussion of telling corruption-based and congestion-based losses apart 🎀

3.3.3.2 Research 🔬

[Flo94] shows that ECN is effective at reducing the segment loss rate, which yields better performance especially for short and interactive TCP connections 💖 [Flo94] also shows that ECN avoids some unnecessary and costly TCP retransmission timeouts ✨ and finally, [Flo94] considers some of the advantages and disadvantages of various forms of explicit congestion notification 🫶

3.3.3.3 Implementation Issues 🛠️

deploying ECN requires changes to the TCP implementation on both the sender and the receiver 🧩 it also requires deploying some active queue management infrastructure in routers 🍓 RED is assumed in most ECN discussions, because RED is already identifying segments to drop even before its buffer space runs out 🌈 ECN simply allows "marked" segments to be delivered while still notifying the end nodes that congestion is happening along the path ⭐ ECN is safe (from a congestion control perspective) for shared networks, since it keeps the same TCP congestion control principles used when congestion is detected through segment drops 👑

3.3.3.4 Topology Considerations 🗺️

it's expected that none of the environments outlined in section 2 will be biased toward or against ECN traffic 💅

3.3.3.5 Possible Interaction and Relationships with Other Research 🧩

heads up bestie: some form of active queueing is necessary to use ECN (e.g., RED queueing) 🚨

---

3.3.4 Detecting Corruption Loss 🕵️‍♀️

differentiating between congestion (loss of segments due to router buffer overflow or imminent buffer overflow) and corruption (loss of segments due to damaged bits) is a seriously hard problem for TCP 😭 it matters a LOT bc the action TCP should take in the two cases is totally different 💀 for corruption, TCP should just retransmit the damaged segment as soon as its loss is detected; there's no need for TCP to adjust its congestion window 🫶 but as we've been talking about, when the TCP sender detects congestion, it should immediately reduce its congestion window so it doesn't make the congestion worse 🚫📉

TCP's defined behavior, motivated by [Jac88,Jac90] and defined in [Bra89,Ste97,APS99], is to assume that all loss is due to congestion and to trigger the congestion control algorithms defined in [Ste97,APS99] 💅 the loss may be detected using the fast retransmit algorithm, or in the worst case, by the expiration of TCP's retransmission timer ⏰

TCP's assumption that loss is due to congestion rather than corruption is a conservative mechanism that prevents congestion collapse [Jac88,FF98] 🛡️ but over satellite networks, like in lots of wireless environments, loss due to corruption is more common than on terrestrial networks 🛰️ one common partial fix is adding Forward Error Correction (FEC) to the data sent over the satellite/wireless link 🧚 a more complete discussion of FEC's benefits is in [AGS99] ✨ however, FEC doesn't always work or can't be universally applied, so other mechanisms have been studied to help TCP tell congestion-based loss apart from corruption-based loss 🦋

TCP segments that have been corrupted are most often dropped by intervening routers when link-level checksum mechanisms detect that an incoming frame has errors 🚧 occasionally, a TCP segment with an error might slip through undetected until it reaches the TCP receiving host, and then it will almost always fail either the IP header checksum or the TCP checksum and get discarded, same as in the link-level error case 💜 unfortunately, in either of these cases, it's not generally safe for the node that detects the corruption to send information about the corrupt packet back to the TCP sender, because the sending address itself might have been corrupted 😭🙈

3.3.4.1 Mitigation Description

okay so satellite links get random bit errors WAY more often than wired ones 😭 which means it's super important that the TCP sender retransmits these lost segments WITHOUT shrinking its congestion window 🫶 corrupt segments don't mean congestion, so the sender doesn't need to go into congestion avoidance, which can waste bandwidth that's literally just sitting there 💀 simulations in [SF98] showed a real performance boost when TCP can tell corruption apart from congestion on wireless links 🔥

the biggest research challenge here is getting TCP (a transport-layer protocol 🧚) to actually receive the right info from either the network layer (IP) or the link layer. most of the work so far uses link-layer mechanisms that retransmit damaged segments, and the goal is making those repairs in a way where TCP understands what happened and can respond properly 👑

3.3.4.2 Research

research into corruption detection has mostly focused on making the link level detect errors and then do link-level retransmissions 🔍 this work is summarized in [BKVP97,BPSK96]. the tea is that this promising technique causes an effective reordering of segments from the TCP receiver's point of view 😬 for example, if segments A B C D are sent across a noisy link and segment B gets corrupted, then C and D may have already crossed the link before B can be retransmitted at the link level. so they arrive at the TCP receiver in the order A C D B. that reordering makes the TCP receiver generate duplicate ACKs when C and D show up, and if it's bad enough, the sender triggers the fast retransmit algorithm because of those duplicate ACKs 💀 [MV98] proposes suppressing or delaying the duplicate ACKs in the reverse direction to counteract this behavior 🙈 another option is proposals that make TCP more robust when segments arrive reordered [Flo99], which may reduce the side effects of the reordering caused by link-layer retransmissions ✨

a more high-level approach, outlined in [DMT96], uses a new "corruption experienced" ICMP error message generated by routers that detect corruption 🦋 these messages go in the forward direction, toward the packet's destination, instead of the reverse direction like ICMP Source Quench messages. sending them forward means this feedback can work over asymmetric paths 🌈 as noted above, making an error message for a damaged packet is tricky because the source and destination addresses may not be valid. [DMT96] gets around this by having routers keep a small cache of recent packet destinations. when a router's error rate goes above some threshold, it sends an ICMP corruption-experienced message to all the destinations in its cache 💅 then each TCP receiver has to pass this info back to its own TCP sender (through a TCP option). when the TCP sender gets an ACK with this "corruption-experienced" option, it assumes packet loss is due to corruption rather than congestion for two round trip times (RTT), or until it gets more link state info (like "link down", source quench, or more "corruption experienced" messages) 🧠 ngl, in shared networks, ignoring segment loss for 2 RTTs can aggravate congestion by making TCP unresponsive 😭

3.3.4.3 Implementation Issues

all of the techniques above need changes to at least the TCP sending and receiving stacks, plus intermediate routers 🛠️ because of the concerns about possibly ignoring congestion signals (aka segment drops), the above algorithm is not recommended for use in shared networks 🚫

3.3.4.4 Topology Considerations

corruption detection is expected to be beneficial in general, in all the environments outlined in section 2 🌍 it would be especially beneficial in the satellite/wireless environment, where these errors may be more prevalent ☁️

3.3.4.5 Possible Interaction and Relationships with Other Research

SACK-based loss recovery algorithms (as described in 3.3.2) may reduce the impact of corrupted segments on mostly clean links, because recovery can happen more rapidly and without relying on the retransmission timer ⏱️ but while SACK-based loss recovery helps, throughput will still suffer in the face of non-congestion related packet loss 🥲

3.4 Congestion Avoidance

3.4.1 Mitigation Description

during congestion avoidance, when there's no loss, the TCP sender adds about one segment to its congestion window every RTT [Jac88,Ste97,APS99] 📈 several researchers noticed this policy leads to unfair bandwidth sharing when multiple connections with different RTTs go through the same bottleneck link. the long RTT connections end up with only a small fraction of their fair share of bandwidth 😤

one effective fix is deploying fair queueing and TCP-friendly buffer management in network routers [Sut98] 👑 but if the network can't help, other researchers have looked at changing the congestion avoidance policy at the TCP sender instead, as described in [Flo91,HK98] 💖

3.4.2 Research

the "Constant-Rate" increase policy has been studied in [Flo91,HK98] 🎀 it tries to equalize how fast TCP senders increase their sending rate during congestion avoidance. both [Flo91] and [HK98] show cases where the "Constant-Rate" policy mostly fixes the bias against long RTT connections, though [HK98] has some evidence that this policy may be hard to deploy incrementally in an operational network 🙈 choosing the constant (for the constant rate of increase) is still an open issue 🤔

the "Increase-by-K" policy can be selectively used by long RTT connections in a heterogeneous environment 🌈 it just changes the slope of the linear increase. connections over a given RTT threshold add "K" segments to the congestion window every RTT instead of one ✨ [HK98] shows evidence that this policy, with small values of "K", may reduce the unfairness while keeping link utilization high when a small number of connections share a bottleneck link 🦋 picking the constant "K," the RTT threshold that triggers this policy, and performance with a large number of flows are all open issues 💀

3.4.3 Implementation Issues

implementing either the "Constant-Rate" or "Increase-by-K" policy requires a change to the congestion avoidance mechanism at the TCP sender 🛠️ for "Constant-Rate," the change must be implemented globally. the TCP sender also needs a reasonably accurate estimate of the connection's RTT 📏 the algorithms above violate the congestion avoidance algorithm as outlined in RFC 2581 [APS99], so they should not be implemented in shared networks at this time 🚫

3.4.4 Topology Considerations

these solutions apply to all satellite networks that are integrated with a terrestrial network 🛰️ in those setups, satellite connections may be competing with terrestrial connections for the same bottleneck link 🌍

3.4.5 Possible Interaction and Relationships with Other Research

as shown in [PADHV99], increasing the congestion window by multiple segments per RTT can make TCP drop multiple segments and force a retransmission timeout in some versions of TCP 😱 so the changes above to the congestion avoidance algorithm may need to come with a SACK-based loss recovery algorithm that can quickly repair multiple dropped segments 🩹

3.5 Multiple Data Connections

3.5.1 Mitigation Description

one method people have used to get past TCP's inefficiencies in the satellite environment is using multiple TCP flows to transfer a given file 🧚 using N TCP connections makes the sender N times more aggressive, so it can improve throughput in some situations. but using N connections can affect the transfer and the network in a bunch of ways, listed below 👇

1. the transfer can start with an effective congestion window of N segments, instead of the single segment one TCP flow uses 🚀 this lets the transfer ramp the effective cwnd up to an appropriate size for the network more quickly. however, in some circumstances an initial window of N segments is wrong for the network conditions. then a transfer using more than one connection may aggravate congestion 😬
2. during congestion avoidance, the transfer increases the effective cwnd by N segments per RTT, instead of the one segment per RTT a single TCP connection gets 📈 again, this can help by ramping the effective cwnd to an appropriate point faster. but this rate of increase can also be too aggressive for the network conditions. in that case, using multiple data connections can aggravate congestion in the network 💥
3. using multiple connections can give a very large overall congestion window 🪟 this can be an advantage for TCP implementations that don't support the TCP window scaling extension [JBB92]. however, the aggregate cwnd across all N connections is equivalent to using a TCP implementation that supports large windows 💅
4. the overall cwnd decrease in the face of dropped segments is reduced when using N parallel connections 🧈 a single TCP connection cuts the effective cwnd in half when a single segment loss is detected. when using N connections, each with a window of W bytes, a single drop reduces the window to:

(N * W) - (W / 2)

that's clearly a less dramatic reduction in effective cwnd size than with a single TCP connection 🥹 and the amount the cwnd gets decreased shrinks even more as N goes up 📉

using multiple data connections can help non-SACK TCP implementations recover from multiple dropped segments without resorting to a timeout, assuming the dropped segments cross connections 🔁

but using multiple parallel connections makes TCP overly aggressive for many environments, and it can contribute to congestive collapse in shared networks [FF99] 🚨 the advantages of multiple TCP connections are now mostly provided by TCP extensions (larger windows, SACKs, etc.) 🎀 so using a single TCP connection is more "network friendly" than using multiple parallel connections 🫶 that said, using multiple parallel TCP connections may give a performance improvement in private networks 🏠

3.5.2 Research

okay so bestie, researchers have been obsessed with multiple parallel TCP connections for ages 💅 Studies found they give improved performance [IL92,Hah94,AOK95,AKO96]. 🔥 Then there's the iconic plot twist: research showed several TCP connections can outperform one single modern TCP connection (with large windows and SACK) [AHKO97]. 😭 BUT these studies didn't check what happens to the other traffic sharing the network 🙈 [FF99] argues that using multiple simultaneous connections to transfer one file may lead to congestive collapse in shared networks. 💀 not me getting a little worried about the rest of the internet rn

3.5.3 Implementation Issues

bestie, to use multiple parallel TCP connections, the client application AND the matching server both have to be customized 🎀 As outlined in [FF99], using multiple parallel TCP connections is not safe (from a congestion control perspective) in shared networks, and it should not be used. 🙅‍♀️ it's giving "do not try this at home" energy

3.5.4 Topological Considerations

ok so as we said above, [FF99] points out that using multiple parallel connections in a shared network, like the Internet, may lead to congestive collapse 🌊 However, using multiple connections may be safe and beneficial in private networks ✨ The specific topology being used decides how many parallel connections are required 🧚 Some work has been done to figure out the right number of connections on the fly [AKO96], but that mechanism is far from complete 🥺

3.5.5 Possible Interaction and Relationships with Other Research

this one is so cute, okay 🎀 Using multiple concurrent TCP connections lets you use a large congestion window, kinda like the TCP window scaling option [JBB92]. 🦋 On top of that, you get a larger initial congestion window, similar to what you'd get from using [AFP98] or TCB sharing (see section 3.8). 🫶

3.6 Pacing TCP Segments

3.6.1 Mitigation Description

so slow-start takes several round trips to fully open the TCP congestion window over routes with high bandwidth-delay products 🐢 For short TCP connections (like WWW traffic with HTTP/1.0), the slow-start overhead can preclude effective use of high-bandwidth satellite links 🛰️ When senders implement slow-start restart after a TCP connection goes idle (an idea suggested by Jacobson and Karels [JK92]), performance drops for long-lived (but bursty) connections 📉 Think HTTP/1.1, which uses persistent TCP connections to transfer multiple WWW page elements [Hei97a]. 🌸

Rate-based pacing (RBP) is a technique, used when there are no incoming ACKs, where the data sender temporarily paces TCP segments at a given rate to restart the ACK clock ⏰ Once the first ACK arrives, pacing stops and normal TCP ACK clocking resumes 🙌 The pacing rate may come from recent traffic estimates (when restarting an idle connection or from recent prior connections), or it may be known through external means (perhaps in a point-to-point or point-to-multipoint satellite network where available bandwidth can be assumed to be large) 🌈

Also, pacing data during the first RTT of a transfer may let TCP make effective use of high bandwidth-delay links even for short transfers ✨ BUT, to pace segments during the first RTT, a TCP will have to be using a non-standard initial congestion window and a new mechanism to pace outgoing segments instead of sending them back-to-back 🧐 Figuring out an appropriate size for the initial cwnd is still an open research question 🔍 Pacing can also be used to reduce bursts in general (due to buggy TCPs or byte counting; see section 3.2.2 for a discussion on byte counting) 🍓

3.6.2 Research

the simulation studies of rate-paced pacing for WWW-like traffic showed reductions in router congestion and drop rates [VH97a] 📊 In that environment, RBP substantially improves performance compared to slow-start-after-idle for intermittent senders, and it slightly improves performance over burst-full-cwnd-after-idle (because of drops) [VH98]. 💖 More recently, pacing has been suggested to eliminate burstiness in networks with ACK filtering [BPK97]. 👑

3.6.3 Implementation Issues

RBP only requires sender-side changes to TCP 🙌 Prototype implementations of RBP are available [VH97b]. 🎀 RBP needs an additional sender timer for pacing. ⏲️ The overhead of timer-driven data transfer is often considered too high for practical use, but preliminary experiments suggest that in RBP this overhead is minimal, because RBP only requires this timer for one RTT of transmission [VH98]. 🥰 RBP is expected to make TCP more conservative in sending bursts of data after an idle period in hosts that do not revert to slow start after an idle period 🐌 On the other hand, RBP makes TCP more aggressive if the sender uses the slow start algorithm to start the ACK clock after a long idle period 🏎️ it's a whole balancing act, bestie

3.6.4 Topology Considerations

RBP could be used to restart idle TCP connections for all topologies in Section 2 🗺️ Using it at the beginning of new connections would be restricted to topologies where available bandwidth can be estimated out-of-band 🧚

3.6.5 Possible Interaction and Relationships with Other Research

pacing segments may benefit from sharing state among the various flows between two hosts, because of the time required to determine the needed information 🤝 Also, pacing segments (rather than sending back-to-back segments) may make estimating the available bandwidth (as outlined in section 3.2.4) more difficult 🫠

3.7 TCP Header Compression

okay the TCP and IP header info needed to reliably deliver packets to a remote site across the Internet can add serious overhead, especially for interactive applications 😩 Telnet packets, for example, typically carry only a few bytes of data per packet, and standard IPv4/TCP headers add at least 40 bytes to that, while IPv6/TCP headers add at least 60 bytes 💀 The lowkey genius part is that much of this info stays pretty constant over the course of a session, so it can be replaced by a short session identifier ✨🦋

3.7.1 Mitigation Description ✨

okay bestie, TCP and IP headers are lowkey so repetitive 🥺 Lots of fields either stay the same the whole session, change super rarely, or can be figured out from somewhere else. Like the source and destination addresses, plus the IP version, protocol, and port fields, usually don't change during a session 💅. Packet length can be deduced from the length field of the underlying link layer protocol, as long as the link layer packet isn't padded. Packet sequence numbers in a forward data stream change with basically every packet, but they go up in a predictable way 🦋.

So the TCP/IP header compression methods in [DNP99,DENP97,Jac90] cut down the overhead by swapping out the stuff that stays constant, changes slowly, or changes predictably for a short "connection number" 🎀. The sender first sends a full TCP/IP header, and that header includes the connection number the sender will use to reference the connection. The receiver stores the full header and uses it as a template, filling in some fields from the limited info in the later compressed headers. This can shrink an IPv4/TCP header from 40 to as few as 3 to 5 bytes (3 bytes for some common cases, 5 bytes in general) 🔥.

Compression and decompression generally happen below the IP layer, at the endpoints of a given physical link (like two routers connected by a serial line) 🧚. The hosts on either side of that link have to keep some state about the TCP connections using it 💜.

The decompresser must pass complete, uncompressed packets to the IP layer. So header compression is transparent to routing, because an incoming packet with compressed headers gets expanded before it's passed to IP 👑.

There are a bunch of ways the compressor and decompresser can negotiate whether to use header compression. For example, the PPP serial line protocol has an option exchange where they agree on it 🤝. For older SLIP implementations, [Jac90] describes a mechanism that uses the first bit in the IP packet as a flag 🌈.

The overhead savings are especially useful when the link is bandwidth-limited, like terrestrial wireless and mobile satellite links, where the overhead of sending the header bits is nontrivial 📡. Header compression also has a bonus: for uniformly distributed bit errors, compressing TCP/IP headers can give you better quality of service by decreasing the packet error probability 🫶. The shorter, compressed packets are less likely to get corrupted, and fewer errors means the connection's throughput goes up 🔥.

Extra space is saved by encoding changes in slowly changing fields as just their difference from their values in the previous packet, instead of their absolute values 🍓. To decode headers compressed this way, the receiver keeps a copy of each full, reconstructed TCP header after it's decoded, and applies the delta values from the next decoded compressed header to that reconstructed full header template ✨.

BUT there's a catch 😭. A disadvantage of this delta encoding scheme, where values are encoded as deltas from the previous packet, is that if a single compressed packet gets lost, the subsequent packets with compressed headers can become garbled if they contain fields that depend on the lost packet. Picture a forward data stream of compressed packets with increasing sequence numbers. If packet N is lost, the full header of packet N+1 gets reconstructed at the receiver using packet N-1's full header as a template. So the sequence number, which should've been calculated from packet N's header, will be wrong, the checksum will fail, and the packet gets discarded 💀. When the sending TCP times out and retransmits, a packet with a full header is forwarded to re-synchronize the decompresser 🔄.

It's really important to note that the compressor doesn't maintain any timers, and the decompresser doesn't know when an error happened. Only the receiving TCP knows this, when the TCP checksum fails 🙈.

A single bit error will make the decompresser lose sync. Then the subsequent packets with compressed headers get dropped by the receiving TCP, since they'll all fail the TCP checksum 😩. When this happens, no duplicate acknowledgments get generated, and the decompresser can only re-synchronize when it receives a packet with an uncompressed header. This means that when header compression is being used, neither fast retransmit nor selective acknowledgments can correct packets lost on a compressed link 💔. The "twice" algorithm, described below, may be a partial solution to this problem 🦋.

[DNP99] and [DENP97] describe TCP/IPv4 and TCP/IPv6 compression algorithms, including compressing the various IPv6 extension headers, plus methods for compressing non-TCP streams 🌸. [DENP97] also levels up TCP header compression by introducing the "twice" algorithm 👑. If a particular packet fails to decompress properly, twice modifies its assumptions about the inferred fields in the compressed header. It assumes that a packet identical to the current one was dropped between the last correctly decoded packet and the current one. Then twice tries to decompress the received packet under those new assumptions. If the checksum passes, the packet gets passed to IP and the decompresser state has been re-synchronized 🎉. This procedure can be extended to three or more decoding attempts. For extra robustness, you can cache full copies of packets that don't decompress properly, in the hopes that later arrivals will fix the problem 🙌. Finally, the performance improvement is discussed if the decompresser can explicitly request a full header 🧚. Simulation results show that twice, combined with the full header request mechanism, can improve throughput over uncompressed streams 💖.

3.7.2 Research

okay research time 📚✨ [Jac90] outlines a simple header compression scheme for TCP/IP 🎀.

In [DENP97], the authors present simulation results showing that header compression is advantageous for both low and medium bandwidth links 🔥. The simulations show that the twice algorithm, combined with an explicit header request mechanism, improved throughput by 10-15% over uncompressed sessions across a wide range of bit error rates 📈.

Much of this improvement may have been due to the twice algorithm quickly re-synchronizing the decompresser when a packet is lost 🫶. That's because twice, applied one or two times when the decompresser becomes unsynchronized, will re-sync the decompresser in between 83% and 99% of the cases examined 🙌. This means that packets received correctly after twice has resynchronized the decompresser will cause duplicate acknowledgments. And that re-enables the use of both fast retransmit and SACK in conjunction with header compression 🥳.

3.7.3 Implementation Issues

okay implementation vibes 🛠️ Implementing TCP/IP header compression requires changes at both the sending (compressor) and receiving (decompresser) ends of each link that uses compression 🔧. The twice algorithm requires very little extra machinery on top of header compression 💅. The explicit header request mechanism of [DENP97], on the other hand, requires more extensive modifications to the sending and receiving ends of each link that employs header compression 😤. The good news? Header compression does not violate TCP's congestion control mechanisms, so it can be safely implemented in shared networks 🕊️✨.

3.7.4 Topology Considerations

TCP/IP header compression applies to all of the environments discussed in section 2 🌍. But it gives relatively more improvement when packet sizes are small (i.e., overhead is large) and there's medium to low bandwidth and/or higher BER 📉. When TCP's congestion window size is large, implementing the explicit header request mechanism, the twice algorithm, and caching packets that fail to decompress properly becomes more critical 🚨.

3.7.5 Possible Interaction and Relationships with Other Research

As discussed above, losing synchronization between a sender and receiver can cause many packet drops 😵. The frequency of losing synchronization and the effectiveness of the twice algorithm may point toward using a SACK-based loss recovery algorithm to reduce the impact of multiple lost segments 🦋. However, even very robust SACK-based algorithms may not work well if too many segments are lost 💀.

3.8 Sharing TCP State Among Similar Connections 👯‍♀️

3.8.1 Mitigation Description

okay so persistent TCP state information can be used to overcome limitations in the configuration of the initial state 🧠. It can also automatically tune TCP to environments using satellite links, and coordinate multiple TCP connections sharing a satellite link 🛰️✨.

TCP has a whole bunch of parameters, and many are set to initial values that can seriously affect the performance of TCP connections traversing satellite links 😭. This is true even though most TCP parameters get adjusted later, after the connection is established. These parameters include the initial size of cwnd and the initial MSS size 🎀. People have suggested all sorts of ways to change these initial conditions so they work better for satellite links 💡. But it's hard to pick any single set of parameters that works well for every environment 🤷‍♀️.

An alternative to trying to pick these parameters a-priori is sharing state across TCP connections and using that state when initializing a new connection 🫶. For example, if all connections to a subnet end up with extended congestion windows of 1 megabyte, it's probably more efficient to start new connections with that value 🔥. The other option is rediscovering it by making the cwnd increase using slow start over a period of dozens of round-trip times 😴. No thanks, bestie 💅.

3.8.2 Research

Okay so sharing state between connections brings up a whole bunch of questions 🧠 like: what info should get shared, who should it be shared with, how should it be shared, and how do you age the shared info (aka when does it expire) ⏳. First up, we have to figure out WHAT info is okay to share. Some stuff is totally appropriate to share between TCP connections, while other sharing is inappropriate or just not useful 🙅. Next, we need to decide WHO gets to share it. Sharing can make sense for TCP connections that share a common path to a given host. Info can be shared among connections within one host, or even among connections between different hosts, like hosts on the same LAN 🏠. BUT sharing info between connections that don't traverse the same network may not be appropriate 🚫. Once we know the state and the parties, a mechanism for the sharing is required 🔧. Simple state, like MSS and RTT, is easy to share, but congestion window information can be shared a variety of ways 🪟. The sharing mechanism decides priorities among the sharing connections, and a bunch of fairness criteria need to be considered ⚖️. Also, the mechanisms for aging the info still need further study ⏳. See RFC 2140 for a discussion of the security issues in both sharing state within a single host and sharing state among hosts on a subnet 🔐. Finally, the security concerns with sharing any piece of information need to be carefully considered before introducing such a mechanism 😬. Honestly, many of these open research questions must be answered before state sharing can be widely deployed 💅.

The opportunity for this kind of sharing, both among a sequence of connections and among concurrent connections, is described in more detail in [Tou97] 📚. The state management itself is largely an implementation issue, however what information should be shared and the specific ways it should be shared is still an open question 🤷‍♀️.

Sharing parts of the TCB state was originally documented in T/TCP [Bra92] 🎀. It's used there to aggregate RTT values across connection instances, so you get meaningful average RTTs, even though most connections are expected to persist for only one RTT 🧮. T/TCP also shares a connection identifier, a sequence number separate from the window number and address/port pairs by which TCP connections are typically distinguished 🪪. Because of this shared state, T/TCP allows a receiver to pass data in the SYN segment to the receiving application, prior to the completion of the three-way handshake, without compromising the integrity of the connection 🤯. In effect, this shared state caches a partial handshake from the previous connection, which is a variant of the more general issue of TCB sharing 🧚.

Sharing state among connections (including transfers using non-TCP protocols) is further investigated in [BRS99] 🔍.

3.8.3 Implementation Issues

Sharing TCP state across connections requires changes to the sender's TCP stack, and possibly the receiver's TCP stack (as in the case of T/TCP, for example) 🛠️. Sharing TCP state may make a particular TCP connection more aggressive 😤. However, the aggregate traffic should be more conservative than a group of independent TCP connections 🫶. Therefore, sharing TCP state should be safe for use in shared networks 🌸. Note that state sharing does not present any new security problems within multiuser hosts 🙌. In that situation, users can steal network resources from one another with or without state sharing 💀.

3.8.4 Topology Considerations

It is expected that sharing state across TCP connections may be useful in all network environments presented in section 2 🗺️.

3.8.5 Possible Interaction and Relationships with Other Research

The state sharing outlined above is very similar to the Congestion Manager proposal [BRS99], which attempts to share congestion control information among both TCP and UDP flows between a pair of hosts 👯.

---

3.9 ACK Congestion Control

In highly asymmetric networks, a low-speed return link can restrict the performance of the data flow on a high-speed forward link by limiting the flow of acknowledgments returned to the data sender 🐢. For example, if the data sender uses 1500 byte segments and the receiver generates 40 byte acknowledgments (IPv4, TCP without options), the reverse link will congest with ACKs for asymmetries of more than 75:1 if delayed ACKs are used, and 37:1 if every segment is acknowledged 📉. For a 1.5 Mb/second data link, ACK congestion will occur for reverse link speeds below 20 kilobits/sec 😵. These levels of asymmetry will readily occur if the reverse link is shared among multiple satellite receivers, as is common in many VSAT satellite networks 🛰️. If a terrestrial modem link is used as a reverse link, ACK congestion is also likely, especially as the speed of the forward link increases 📶. Current congestion control mechanisms aim at controlling the flow of data segments, but they do not affect the flow of ACKs 🙃.

In [KVR98], the authors point out that the flow of acknowledgments can be restricted on the low-speed link not only by the bandwidth of the link, but also by the queue length of the router 🚦. The router may limit its queue length by counting packets, not bytes, and therefore begin discarding ACKs even if there is enough bandwidth to forward them 🗑️.

3.9.1 Mitigation Description

ACK Congestion Control extends the concept of flow control for data segments to acknowledgment segments ✨. In the method described in [BPK97], any intermediate router can mark an acknowledgment with an Explicit Congestion Notification (ECN) bit once the queue occupancy in the router exceeds a given threshold 🚩. The data sender (which receives the acknowledgment) must "echo" the ECN bit back to the data receiver (see section 3.3.3 for a more detailed discussion of ECN) 🔁. The proposed algorithm for marking ACK segments with an ECN bit is Random Early Detection (RED) [FJ93] 🎲. In response to the receipt of ECN marked data segments, the receiver will dynamically reduce the rate of acknowledgments using a multiplicative backoff 📉. Once segments without ECN are received, the data receiver speeds up acknowledgments using a linear increase, up to a rate of either 1 (no delayed ACKs) or 2 (normal delayed ACKs) data segments per ACK 📈. The authors suggest that an ACK be generated at least once per window, and ideally a few times per window 🪟.

As in the RED congestion control mechanism for data flow, the bottleneck gateway can randomly discard acknowledgments, rather than marking them with an ECN bit, once the queue fills beyond a given threshold 🎯.

3.9.2 Research

[BPK97] analyzes the effect of ACK Congestion Control (ACC) on the performance of an asymmetric network 🔬. They note that the use of ACC, and indeed the use of any scheme which reduces the frequency of acknowledgments, has potential unwanted side effects 😬. Since each ACK will acknowledge more than the usual one or two data segments, the likelihood of segment bursts from the data sender is increased 💥. In addition, congestion window growth may be impeded if the receiver grows the window by counting received ACKs, as mandated by [Ste97,APS99] 🚧. The authors therefore combine ACC with a series of modifications to the data sender, referred to as TCP Sender Adaptation (SA) 🧩. SA combines a limit on the number of segments sent in a burst, regardless of window size 🛑. In addition, byte counting (as opposed to ACK counting) is employed for window growth 🔢. Note that byte counting has been studied elsewhere and can introduce side effects as well [All98] 👀.

The results presented in [BPK97] indicate that using ACC and SA will reduce the bursts produced by ACK losses in unmodified (Reno) TCP 🍃. In cases where these bursts would lead to data loss at an intermediate router, the ACC and SA modifications significantly improve the throughput for a single data transfer 🚀. The results further suggest that the use of ACC and SA significantly improves fairness between two simultaneous transfers 🤝.

ACC is further reported to prevent the increase in round trip time (RTT) that occurs when an unmodified TCP fills the reverse router queue with acknowledgments 🙌.

In networks where the forward direction is expected to suffer losses in one of the gateways due to queue limitations, the authors report at best a very slight improvement in performance for ACC and SA, compared to unmodified Reno TCP 🥲.

3.9.3 Implementation Issues

Both ACC and SA require modification of the sending and receiving hosts, as well as the bottleneck gateway 🖥️. The current research suggests that implementing ACC without the SA modifications results in a data sender which generates potentially disruptive segment bursts 🚨. It should be noted that ACC does require host modifications if it is implemented in the way proposed in [BPK97] 📝. The authors note that ACC can be implemented by discarding ACKs (which requires only a gateway modification, but no changes in the hosts), as opposed to marking them with ECN 🗑️. Such an implementation may, however, produce bursty data senders if it is not combined with a burst mitigation technique 💣. ACC requires changes to the standard ACKing behavior of a receiving TCP, and therefore is not recommended for use in shared networks 🙅‍♀️.

3.9.4 Topology Considerations

Neither ACC nor SA require the storage of state in the gateway 🧘. These schemes should therefore be applicable for all topologies, provided that the hosts using the satellite or hybrid network can be modified 🌍. However, these changes are expected to be especially beneficial to networks containing asymmetric satellite links 🛰️.

3.9.5 Possible Interaction and Relationships with Other Research

Note that ECN is a pre-condition for using ACK congestion control 🔑. Additionally, the ACK Filtering algorithm discussed in the next section attempts to solve the same problem as ACC 👭. Choosing between the two algorithms (or another mechanism) is currently an open research question 🧐.

---

3.10 ACK Filtering

ACK Filtering (AF) is designed to address the same ACK congestion effects described in 3.9 🎀. Contrary to ACC, however, AF is designed to operate without host modifications 🙌.

3.10.1 Mitigation Description

AF takes advantage of the cumulative acknowledgment structure of TCP 🧠. The bottleneck router in the reverse direction (the low speed link) must be modified to implement AF 🛠️. Upon receipt of a segment which represents a TCP acknowledgment, the router scans the queue for redundant ACKs for the same connection, i.e. ACKs which acknowledge portions of the window which are included in the most recent ACK 🔍. All of these "earlier" ACKs are removed from the queue and discarded 🗑️.

The router does not store state information, but it does need to implement the additional processing required to find and remove segments from the queue upon receipt of an ACK 💖.

3.10.2 Research 🔍

okay so [BPK97] is the paper that actually digs into what AF does 👀. Like with ACC, using ACK filtering alone causes significant sender bursts 💀, because each ACK is now acknowledging way more previously-unacknowledged data, so the sender suddenly goes BOOM. The SA modifications from 3.9.2 could prevent those bursts, but ngl that means the host TCP stacks need changes too 🙄. So to avoid touching the TCP stack, AF is more likely to be paired with the ACK Reconstruction (AR) technique 🛠️, which can be implemented at the router where segments exit the slow reverse link.

AR looks at the ACKs exiting the link, and if it spots large "gaps" in the ACK sequence, it makes extra ACKs to rebuild an ACK flow that looks more like what the data sender would have seen if ACK Filtering had never been introduced 🪞. AR needs two parameters ⏱️: one is the desired ACK frequency, and the other controls the spacing, in time, between the release of consecutive reconstructed ACKs.

In [BPK97], the authors show that the combo of AF and AR increases throughput, in the networks they studied, over both unmodified TCP and the ACC/SA modifications 🚀. Their results also strongly suggest that AF alone, in networks where congestion losses are expected, decreases performance (even below the level of unmodified TCP Reno) because of sender bursting 😭.

AF delays acknowledgments from arriving at the receiver by dropping earlier ACKs in favor of later ACKs 🫠. This can cause a slight hiccup in the transmission of new data by the TCP sender.

3.10.3 Implementation Issues 🧪

Both ACK Filtering and ACK Reconstruction require only router modification ✨. However, AR needs some storage of state information in the exit router. AF doesn't require storing state, but using it without AR (or SA) could produce undesired side effects 👀. Furthermore, more research is required regarding appropriate ranges for the parameters needed in AR 🔬.

3.10.4 Topology Considerations 🗺️

AF and AR appear applicable to all topologies, assuming that the storage of state information in AR doesn't prove to be prohibitive for routers handling large numbers of flows 📊. The fact that TCP stack modifications aren't required for AF/AR makes this approach super attractive for hybrid networks and networks with diverse types of hosts 💖. These modifications, however, are expected to be most beneficial in asymmetric network paths 🌈.

On the other hand, implementing AF/AR requires the routers to examine the TCP header, which prohibits their use in secure networks where IPSEC is deployed 🚫. In such networks, AF/AR can be effective only inside the security perimeter of a private or virtual private network, or in private networks where the satellite link is protected only by link-layer encryption (as opposed to IPSEC) 🔐. ACK Filtering is safe to use in shared networks (from a congestion control point-of-view), since the number of ACKs can only be reduced, which makes TCP less aggressive 🕊️. However, while TCP is less aggressive, the delays that AF induces (outlined above) can lead to larger bursts than would otherwise occur 😬.

3.10.5 Possible Interaction and Relationships with Other Research 🤝

ACK Filtering attempts to solve the same problem as ACK Congestion Control (as outlined in section 3.9) 💅. Which of the two algorithms is more appropriate is currently an open research question 🧐.

4 Conclusions 🌸

This document outlines TCP items that may be able to mitigate the performance problems associated with using TCP in networks containing satellite links 🛰️. These mitigations are not IETF standards track mechanisms and require more study before being recommended by the IETF 📚. The research community is encouraged to examine the above mitigations in an effort to determine which are safe for use in shared networks such as the Internet 🌐.

5 Security Considerations 🚨

Several of the above sections noted specific security concerns which a given mitigation aggravates. Yikes, bestie 😬.

Additionally, any form of wireless communication link is more susceptible to eavesdropping security attacks than standard wire-based links 📡🔓, due to the relative ease with which an attacker can watch the network and the difficultly in finding attackers monitoring the network 👀.

6 Acknowledgments 🫶

Our thanks to Aaron Falk and Sally Floyd, who provided very helpful comments on drafts of this document 💜.

7 References 📖

[AFP98]   Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
          Initial Window", RFC 2414, September 1998.

[AGS99]   Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over
          Satellite Channels using Standard Mechanisms", BCP 28, RFC
          2488, January 1999.

[AHKO97]  Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann.  TCP
          Performance Over Satellite Links.  In Proceedings of the
          5th International Conference on Telecommunication Systems,
          March 1997.

[AHO98]   Mark Allman, Chris Hayes, Shawn Ostermann.  An Evaluation
          of TCP with Larger Initial Windows.  Computer Communication
          Review, 28(3), July 1998.

[AKO96]   Mark Allman, Hans Kruse, Shawn Ostermann.  An Application-
          Level Solution to TCP's Satellite Inefficiencies.  In
          Proceedings of the First International Workshop on
          Satellite-based Information Services (WOSBIS), November
          1996.

[All97a]  Mark Allman.  Improving TCP Performance Over Satellite
          Channels.  Master's thesis, Ohio University, June 1997.

[All97b]  Mark Allman.  Fixing Two BSD TCP Bugs.  Technical Report
          CR-204151, NASA Lewis Research Center, October 1997.

[All98]   Mark Allman. On the Generation and Use of TCP
          Acknowledgments.  ACM Computer Communication Review, 28(5),
          October 1998.

[AOK95]   Mark Allman, Shawn Ostermann, Hans Kruse.  Data Transfer
          Efficiency Over Satellite Circuits Using a Multi-Socket
          Extension to the File Transfer Protocol (FTP).  In
          Proceedings of the ACTS Results Conference, NASA Lewis
          Research Center, September 1995.

[AP99]    Mark Allman, Vern Paxson.  On Estimating End-to-End Network
          Path Properties. ACM SIGCOMM, September 1999.

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

[BCC+98]  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.

[BKVP97]  B. Bakshi and P. Krishna and N. Vaidya and D. Pradham,
          "Improving Performance of TCP over Wireless Networks", 17th
          International Conference on Distributed Computing Systems
          (ICDCS), May 1997.

[BPK97]   Hari Balakrishnan, Venkata N. Padmanabhan, and Randy H.
          Katz.  The Effects of Asymmetry on TCP Performance.  In
          Proceedings of the ACM/IEEE Mobicom, Budapest, Hungary,
          ACM.  September, 1997.

[BPK98]   Hari Balakrishnan, Venkata Padmanabhan, Randy H. Katz.  The
          Effects of Asymmetry on TCP Performance.  ACM Mobile
          Networks and Applications (MONET), 1998 (to appear).

[BPSK96]  H. Balakrishnan and V. Padmanabhan and S. Sechan and R.
          Katz, "A Comparison of Mechanisms for Improving TCP
          Performance over Wireless Links", ACM SIGCOMM, August 1996.

[Bra89]   Braden, R., "Requirements for Internet Hosts --
          Communication Layers", STD 3, RFC 1122, October 1989.

[Bra92]   Braden, R., "Transaction TCP -- Concepts", RFC 1379,
          September 1992.

[Bra94]   Braden, R., "T/TCP -- TCP Extensions for Transactions:
          Functional Specification", RFC 1644, July 1994.

[BRS99]   Hari Balakrishnan, Hariharan Rahul, and Srinivasan Seshan.
          An Integrated Congestion Management Architecture for
          Internet Hosts.  ACM SIGCOMM, September 1999.

[ddKI99]  M. deVivo, G.O. deVivo, R. Koeneke, G. Isern.  Internet
          Vulnerabilities Related to TCP/IP and T/TCP.  Computer
          Communication Review, 29(1), January 1999.

[DENP97]  Mikael Degermark, Mathias Engan, Bjorn Nordgren, Stephen
          Pink.  Low-Loss TCP/IP Header Compression for Wireless
          Networks.  ACM/Baltzer Journal on Wireless Networks, vol.3,
          no.5, p. 375-87.

[DMT96]   R. C. Durst and G. J. Miller and E. J. Travis, "TCP
          Extensions for Space Communications", Mobicom 96, ACM, USA,
          1996.

[DNP99]   Degermark, M., Nordgren, B. and S. Pink, "IP Header
          Compression", RFC 2507, February 1999.

[FF96]    Kevin Fall, Sally Floyd.  Simulation-based Comparisons of
          Tahoe, Reno, and SACK TCP.  Computer Communication Review,
          V. 26 N. 3, July 1996, pp. 5-21.

[FF99]    Sally Floyd, Kevin Fall.  Promoting the Use of End-to-End
          Congestion Control in the Internet, IEEE/ACM Transactions
          on Networking, August 1999.

[FH99]    Floyd, S. and T. Henderson, "The NewReno Modification to
          TCP's Fast Recovery Algorithm", RFC 2582, April 1999.

[FJ93]    Sally Floyd and Van Jacobson.  Random Early Detection
          Gateways for Congestion Avoidance, IEEE/ACM Transactions on
          Networking, V. 1 N. 4, August 1993.

[Flo91]   Sally Floyd.  Connections with Multiple Congested Gateways
          in Packet-Switched Networks, Part 1: One-way Traffic.  ACM
          Computer Communications Review, V. 21, N. 5, October 1991.

[Flo94]   Sally Floyd.  TCP and Explicit Congestion Notification, ACM
          Computer Communication Review, V. 24 N. 5, October 1994.

[Flo99]   Sally Floyd.  "Re: TCP and out-of-order delivery", email to
          end2end-interest mailing list, February, 1999.

[Hah94]   Jonathan Hahn.  MFTP: Recent Enhancements and Performance
          Measurements.  Technical Report RND-94-006, NASA Ames
          Research Center, June 1994.

[Hay97]   Chris Hayes.  Analyzing the Performance of New TCP
          Extensions Over Satellite Links.  Master's Thesis, Ohio
          University, August 1997.

[HK98]    Tom Henderson, Randy Katz.  On Improving the Fairness of
          TCP Congestion Avoidance.  Proceedings of IEEE Globecom `98
          Conference, 1998.

[HK99]    Tim Henderson, Randy Katz.  Transport Protocols for
          Internet-Compatible Satellite Networks, IEEE Journal on
          Selected Areas of Communications, February, 1999.

[Hoe95]   J. Hoe, Startup Dynamics of TCP's Congestion Control and
          Avoidance Schemes. Master's Thesis, MIT, 1995.

[Hoe96]   Janey Hoe.  Improving the Startup Behavior of a Congestion
          Control Scheme for TCP.  In ACM SIGCOMM, August 1996.

[IL92]    David Iannucci and John Lakashman.  MFTP: Virtual TCP
          Window Scaling Using Multiple Connections.  Technical
          Report RND-92-002, NASA Ames Research Center, January 1992.

[Jac88]   Van Jacobson.  Congestion Avoidance and Control.  In
          Proceedings of the SIGCOMM '88, ACM.  August, 1988.

[Jac90]   Jacobson, V., "Compressing TCP/IP Headers", RFC 1144,
          February 1990.

[JBB92]   Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
          High Performance", RFC 1323, May 1992.

7. References ✨

okay bestie, this is the citation list 📚 every source the author leaned on is right here, no cap 🫶

   [JK92]    Van Jacobson and Mike Karels.  Congestion Avoidance and
             Control.  Originally appearing in the proceedings of
             SIGCOMM '88 by Jacobson only, this revised version includes
             an additional appendix.  The revised version is available
             at ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.  1992.

   [Joh95]   Stacy Johnson.  Increasing TCP Throughput by Using an
             Extended Acknowledgment Interval.  Master's Thesis, Ohio
             University, June 1995.

   [KAGT98]  Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran.  HTTP
             Page Transfer Rates Over Geo-Stationary Satellite Links.
             March 1998. Proceedings of the Sixth International
             Conference on Telecommunication Systems.

   [Kes91]   Srinivasan Keshav.  A Control Theoretic Approach to Flow
             Control.  In ACM SIGCOMM, September 1991.

   [KM97]    S. Keshav, S. Morgan. SMART Retransmission: Performance
             with Overload and Random Losses. Proceeding of Infocom.
             1997.

   [KVR98]   Lampros Kalampoukas, Anujan Varma, and K. K.Ramakrishnan.
             Improving TCP Throughput Over Two-Way Asymmetric Links:
             Analysis and Solutions.  Measurement and Modeling of
             Computer Systems, 1998, Pages 78-89.

   [MM96a]   M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining
             TCP Congestion Control," Proceedings of SIGCOMM'96, August,
             1996, Stanford, CA.  Available from
             http://www.psc.edu/networking/papers/papers.html

   [MM96b]   M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding
             Parameters" Available from
             http://www.psc.edu/networking/papers/FACKnotes/current.

   [MMFR96]  Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
             Selective Acknowledgment Options", RFC 2018, October 1996.

   [MSMO97]  M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The Macroscopic
             Behavior of the TCP Congestion Avoidance
             Algorithm",Computer Communication Review, volume 27,
             number3, July 1997.  Available from
             http://www.psc.edu/networking/papers/papers.html

   [MV98]    Miten N. Mehta and Nitin H. Vaidya.  Delayed Duplicate-
             Acknowledgments: A Proposal to Improve Performance of TCP
             on Wireless Links.  Technical Report 98-006, Department of
             Computer Science, Texas A&M University, February 1998.

   [Nic97]   Kathleen Nichols.  Improving Network Simulation with
             Feedback.  Com21, Inc. Technical Report.  Available from
             http://www.com21.com/pages/papers/068.pdf.

   [PADHV99] Paxson, V., Allman, M., Dawson, S., Heavens, I. and B.
             Volz, "Known TCP Implementation Problems", RFC 2525, March
             1999.

   [Pax97]   Vern Paxson.  Automated Packet Trace Analysis of TCP
             Implementations.  In Proceedings of ACM SIGCOMM, September
             1997.

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

   [Pos81]   Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.

   [RF99]    Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
             Congestion Notification (ECN) to IP", RFC 2481, January
             1999.

   [SF98]    Nihal K. G. Samaraweera and Godred Fairhurst,
             "Reinforcement of TCP error Recovery for Wireless
             Communication", Computer Communication Review, volume 28,
             number 2, April 1998.

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

   [Ste97]   Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
             Retransmit, and Fast Recovery Algorithms", RFC 2001,
             January 1997.

   [Sut98]   B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury.
             Design Considerations for Supporting TCP with Per-flow
             Queueing.  Proceedings of IEEE Infocom `98 Conference,
             1998.

   [Tou97]   Touch, J., "TCP Control Block Interdependence", RFC 2140,
             April 1997.

   [VH97a]   Vikram Visweswaraiah and John Heidemann.  Improving Restart
             of Idle TCP Connections.  Technical Report 97-661,
             University of Southern California, 1997.

   [VH97b]   Vikram Visweswaraiah and John Heidemann.  Rate-based pacing
             Source Code Distribution, Web page:
             http://www.isi.edu/lsam/publications/rate_based_pacing/README.html
             November, 1997.

   [VH98]    Vikram Visweswaraiah and John Heidemann.  Improving Restart
             of Idle TCP Connections (revised).  Submitted for
             publication.

8. Authors' Addresses 🎀

these are the people who wrote it, so you know who to thank for the vibes 💅 their contact deets are all here

   Mark Allman
   NASA Glenn Research Center/BBN Technologies
   Lewis Field
   21000 Brookpark Rd.  MS 54-2
   Cleveland, OH  44135

   EMail: mallman@grc.nasa.gov
   http://roland.grc.nasa.gov/~mallman


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

   EMail: Spencer.Dawkins.sdawkins@nt.com


   Dan Glover
   NASA Glenn Research Center
   Lewis Field
   21000 Brookpark Rd.  MS 3-6
   Cleveland, OH  44135

   EMail: Daniel.R.Glover@grc.nasa.gov
   http://roland.grc.nasa.gov/~dglover


   Jim Griner
   NASA Glenn Research Center
   Lewis Field
   21000 Brookpark Rd.  MS 54-2
   Cleveland, OH  44135

   EMail: jgriner@grc.nasa.gov
   http://roland.grc.nasa.gov/~jgriner


   Diepchi Tran
   NASA Glenn Research Center
   Lewis Field
   21000 Brookpark Rd.  MS 54-2
   Cleveland, OH  44135

   EMail: dtran@grc.nasa.gov
   Tom Henderson
   University of California at Berkeley
   Phone: +1 (510) 642-8919

   EMail: tomh@cs.berkeley.edu
   URL: http://www.cs.berkeley.edu/~tomh/


   John Heidemann
   University of Southern California/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695

   EMail: johnh@isi.edu


   Joe Touch
   University of Southern California/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6601
   USA

   Phone: +1 310-448-9151
   Fax:   +1 310-823-6714
   URL:   http://www.isi.edu/touch
   EMail: touch@isi.edu


   Hans Kruse
   J. Warren McClure School of Communication Systems Management
   Ohio University
   9 S. College Street
   Athens, OH 45701

   Phone: 740-593-4891
   Fax: 740-593-4889
   EMail: hkruse1@ohiou.edu
   http://www.csm.ohiou.edu/kruse


   Shawn Ostermann
   School of Electrical Engineering and Computer Science
   Ohio University
   416 Morton Hall
   Athens, OH  45701

   Phone: (740) 593-1234
   EMail: ostermann@cs.ohiou.edu
   Keith Scott
   The MITRE Corporation
   M/S W650
   1820 Dolley Madison Blvd.
   McLean VA 22102-3481

   EMail: kscott@mitre.org


   Jeffrey Semke
   Pittsburgh Supercomputing Center
   4400 Fifth Ave.
   Pittsburgh, PA  15213

   EMail: semke@psc.edu
   http://www.psc.edu/~semke

9. Full Copyright Statement ⚖️

this part is the legal fine print, so it stays word-for-word, no edits 🙈

   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 🫶

and last but not least, the credit where it's due 🌸

   Funding for the RFC Editor function is currently provided by the
   Internet Society.