Some comments on SQuID (RFC1018)
Original Publication Date: 1987-Aug-01
Included in the Prior Art Database: 2000-Sep-12
Internet Society Requests For Comment (RFCs)
This memo is a discussion of some of the ideas expressed in RFC-1016 on Source Quench. This memo introduces the distinction of the cause of congestion in a gateway between the effects of "Funneling" and "Mismatch". It is offered in the same spirit as RFC-1016; to stimulate discussion. The opinions offered are personal, not corporate, opinions. Distribution of this memo is unlimited.
Network Working Group A. McKenzie
Request for Comments: 1018 BBN Labs
Some Comments on SQuID
Status of this Memo
This memo is a discussion of some of the ideas expressed in RFC-1016
on Source Quench. This memo introduces the distinction of the cause
of congestion in a gateway between the effects of "Funneling" and
"Mismatch". It is offered in the same spirit as RFC-1016; to
stimulate discussion. The opinions offered are personal, not
corporate, opinions. Distribution of this memo is unlimited.
It appears to me that there are at least two qualitatively different
types of congestion which may occur at Internet gateways. One form
of congestion is the result of the merger of several independent data
streams from diverse sources at a common point in their communication
path. I'll refer to this as "Funneling". The architecture of the
Internet (apparently) assumes that traffic flows are bursty and
asynchronous; therefore congestion which occurs at the result of
Funneling will typically be the result of "bad luck" as several
independent bursts happen to arrive at a common point simultaneously.
It is expected that Funneling congestion will be short-lived, just as
individual bursts are. I don't claim that any such assumptions are
documented or formalized; nevertheless I got a clear sense of this
class of assumptions both from reading the protocol documentation and
from personal recollections of long-past design meetings.
A second form of Internet congestion may arise during a prolonged
(non-bursty) data transfer between hosts when the resulting traffic
must pass through a node connecting two communications subsystems
with significantly different throughput rates. I'll refer to this as
"Mismatching". By contrast with Funneling, Mismatching can be caused
by the innocent action of a single host, is highly repeatable
(definitely not just "bad luck"), and will be long-lived.
RFC- 1016 discusses two interrelated strategies; one for when to send
a SQ, and a second for what to do when an SQ is received. There is
also a discussion of 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; the flow under study is long-lived by design.) It seems
to me that the strategy RFC- 1016 proposes for sending SQ's, 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 that Funneling congestion is the result of short-
lived phenomena, it is appropriate for gateways which are the sites
of this congestion to...