RFC 1018 (rfc1018) - Page 1 of 3

Some comments on SQuID

Network Working Group                                        A. McKenzie
Request for Comments: 1018                                      BBN Labs
                                                             August 1987
                         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.

Discussion

   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



McKenzie