RFC 1110

A Problem with the TCP Big Window Option 💖

okay so before we dive in, here's the title block tea ☕

• RFC number and title: RFC 1110, A Problem with the TCP Big Window Option
• Network Working Group 🌸
• Author: Alex McKenzie, BBN STC (Bolt Beranek and Newman Inc.) 🧚
• Date: August 1989 📅
• Category or status: not listed in the title block. The memo itself says it comments on the TCP Big Window option from RFC 1106 🦋
• Obsoletes and updates: neither is listed in the title block 💅

Status of This Memo ✨

this memo comments on the TCP Big Window option described in RFC 1106. distribution of this memo is unlimited 🫶

Abstract 🔥

the TCP Big Window option from RFC 1106 is not going to work right in an Internet environment that has both a high bandwidth * delay product and the possibility of packets getting disordered and duplicated 😭 in those networks, the window size can't be bumped up unless the sequence number space gets a matching bump too. so a different big-window approach is needed for the Internet 💅

Discussion 🦋

okay so TCP was designed for a packet store-and-forward environment where packet loss, packet disordering, and packet duplication are all on the table 💀 packet loss can happen when a congested network element throws a packet away. packet disordering can happen when the packets of one TCP connection get sent partly over a low bandwidth terrestrial path and partly over a high bandwidth satellite path 🛰️ and packet duplication can happen when two directly-connected network elements use a reliable link protocol and the link goes down after the receiver correctly gets a packet but before the transmitter gets an acknowledgement for it. now both the transmitter and the receiver are trying to deliver that same packet to its final destination 🙈

TCP's whole job is to rebuild, at the destination, an exact copy of the data stream from the source, in the same order and with no gaps or duplicates ✨ the way it does this is by giving each byte of data at the source a "unique" sequence number, then sorting the bytes at the destination by that number. the sorting fixes any disordering. an acknowledgement, timeout, and retransmission scheme fixes data loss. and the uniqueness of the sequence number fixes data duplication 👑

here's the twist though: the sequence number isn't actually unique 😭 it lives in a 32-bit field, so it "wraps around" after 2**32 bytes of data have been sent. to keep sequence numbers effectively unique anyway, two more mechanisms do the heavy lifting: the TCP transmission window, and the bounds on packet lifetime inside the Internet, including the IP Time-to-Live (TTL) 🎀 the transmission window sets the maximum number of bytes the source can send in one source-destination roundtrip time. the TCP transmission window is specified with 16 bits, which is 1/65536 of the sequence number space, so a sequence number won't get reused (used to number another byte) for 65,536 roundtrip times. as long as gateway action on the IP TTL and the holding times inside the individual networks that connect the gateways don't let a packet live longer than 65,536 roundtrip times, each sequence number is effectively unique 🧚 the TCP designers believed the networks and gateways forming the internet would meet this constraint, and honestly? it has been the case 🌈

now the proposed TCP Big Window option from RFC 1106 expands the window specification to 30 bits, and leaves the sequence number space alone 😬 so a sequence number can get reused after just 4 roundtrip times. it gets worse: the Nak option lets the source retransmit a packet (which means it could be duplicated) after only one roundtrip time. so if a packet gets "lost" in the Internet for only about 5 roundtrip times, it may be delivered once its sequence number is back inside the window, just in a later cycle of the window. when that happens, TCP won't necessarily rebuild an exact copy of the source's data stream at the destination. it might replace some data with earlier data 💀

the problem comes from the "lost" packet being stored somewhere in the net, and then getting delivered out of order later. 🚨

RFC 1106 seems to describe using the proposed options in an isolated satellite network 🛰️ we can hypothesize that this network is memoryless, meaning it can't deliver packets out of order. it either delivers a packet in order or loses it. if that's the case, then the proposed options have no problem 💖 but the Internet can deliver packets out of order, and that will likely keep being true even once gigabit links become part of the Internet 🚀 so the approach in RFC 1106 can't be adopted for general Internet use. not for the whole Internet, sorry bestie 😭

Author's Address 🎀

Alex McKenzie
Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02238

Phone: (617) 873-2962

EMail: MCKENZIE@BBN.COM