RFC 1018

RFC 1018: Some Comments on SQuID 🎀 Network Working Group, author A. McKenzie (BBN Labs), dated August 1987 Category: a discussion memo, offered as personal opinions 🫶 Obsoletes: none listed. Updates: none listed. 💅

Status of this Memo ✨

okay so bestie, this memo is a discussion of some of the ideas in RFC-1016 about Source Quench 🦋. It introduces the difference between the effects of "Funneling" and "Mismatch" as the causes of congestion in a gateway 💖. It's offered in the same spirit as RFC-1016, just to get everyone talking 🗣️. The opinions here are personal, not corporate, opinions 🙈. Distribution of this memo is unlimited 🌈.

Discussion 💅

okay so I'm lowkey convinced there are at least two qualitatively different kinds of congestion that can show up at Internet gateways 🔥. The first kind comes from the merging of several independent data streams, from diverse sources, at one common point in their communication path. I'm calling this "Funneling" 🌸. The Internet's architecture (apparently) assumes that traffic flows are bursty and asynchronous 🧚. So Funneling congestion is usually just "bad luck," because several independent bursts happen to land at a common point at the same moment 😭. It's expected to be short-lived, just like individual bursts are ✨. I don't claim any of these assumptions are documented or formalized 🙈. Still, I got a clear sense of this class of assumptions from reading the protocol documentation and from my personal recollections of long-past design meetings 💜.

The second kind of Internet congestion can happen during a prolonged (non-bursty) data transfer between hosts, when the resulting traffic has to pass through a node that connects two communications subsystems with significantly different throughput rates 🍓. I'm calling this "Mismatching" 🎀. Unlike Funneling, Mismatching can be caused by the innocent action of a single host 👑. It's highly repeatable (definitely not just "bad luck") and it will be long-lived 💀.

RFC- 1016 discusses two interrelated strategies. One is for deciding when to send an SQ, and the other is for deciding what to do when an SQ is received 🦋. It also discusses some experiments, which deal almost exclusively with Mismatching congestion. (I understand that the simulation can generate multiple flows, but these simply further increase the degree of Mismatch, because the flow under study is long-lived by design 🧚.) It seems to me that the strategy RFC- 1016 proposes for sending SQ's, which is based on queue length, may be appropriate for Funneling Congestion but inappropriate for Mismatch congestion, as discussed below 🫶. The host behavior proposed in RFC- 1016 may be appropriate for both cases ✨.

Since we assume Funneling congestion comes from short-lived phenomena, it makes sense for the gateways where this congestion happens to try to smooth it out without excessive control actions 🌈. This is the basis for the "hint" in the ICMP specification that maybe an SQ should be sent only when a datagram is dropped 💖. It's also the basis for the idea in RFC- 1016 that a gateway should be slow to cry "congestion" (SQK = 70% of queue space filed), even if it's persistent in trying to eliminate it (SQLW = 50% of queue space filled) 😭. Since Funneling congestion is the result of the actions of multiple senders, the growth of internal queues is the only reasonable place to watch for it or measure its effects 🔥.

Mismatch congestion, on the other hand, is the result of incorrect or inadequate information about available transmission bandwidth on the part of a single sender 💅. The sending host has information about destination host capacity (TCP window size and ACK rate) and about local link capacity (from the hardware/software interface to the directly-connected network) 🦋. But it has no real information about the capacity of the Internet path 🙈. As noted in RFC-1016, hosts can get the best throughput if their datagrams are never dropped, and the probability of dropped datagrams is minimized when hosts send at the appropriate steady-state rate (no "bunching") 🍓. So it's a real disservice to a host that's the source of Mismatch congestion to wait a "long" time before taking control action 💀. It would be better to give immediate feedback, via SQ's, to the host as soon as datagrams with too short an inter-arrival time start arriving 👑. That way the sending host can immediately (begin to) adjust its behavior for the indicated destination 🧚.

There are, of course, many implementation issues that would need to be addressed before the type of SQ-sending behavior suggested here could be implemented 🎀. Maybe they aren't as severe as they look, though ✨. Two specific issues and possible solutions are:

1. How should a gateway differentiate between Funneling and mismatch congestion? Perhaps whenever there are more than q" items on an output queue to a slower subnet that were received from a faster subnet, the gateway should look to see if any h" of them have the same source. If so, assume Mismatch and send an SQ to that source. The "q" test might be implemented by a small set of counters that are incremented when a packet is placed on an output queue and decremented when a packet is sent. The search for a common source might require more cycles but be performed less often. The value of "q" would have to be small enough to give an early warning, but bigger than a small multiple of "h". The value of "h" would have to be big enough to avoid triggering on common cases of source datagram fragmentation by an intermediate gateway 🌸.
2. How can a gateway determine which subnets are "slower" and "faster," as well as appropriate inter-arrival times? There may be lots of clever ways for a gateway to measure the dynamic bandwidth of its directly-connected subnets 🧠. However, I'm more into starting with configuration parameters related to the known (at installation time) general characteristics of subnet types (e.g. Ethernet is 10Mbps, ARPANET is 50 Kbps, SATNET is 100 Kbps, etc) 💖. This sort of approximation is quite adequate for determining which subnet is faster, or what inter-arrival time is appropriate for packets being routed to a slower subnet 🫶.

Summary 🫶

Funneling congestion and Mismatch congestion are qualitatively different, and it wouldn't be surprising if different SQ-sending strategies were best for dealing with each 🔥. RFC- 1016 suggests a specific SQ-sending strategy that may be inappropriate for dealing with Mismatch congestion 🙈. This RFC suggests guidelines for an additional SQ-sending strategy for dealing with Mismatch 🦋. Hosts implementing the SQuID algorithm of RFC-1016 should be expected to achieve better performance if they receive SQ's sent according to either or both of these strategies 🌈. However, all these ideas are still only in half-baked form, and real engineering is clearly needed 💀✨.