As per Relevance of the word appropriate, we have this rfc below:
Network Working Group A.
Request for Comments: 1018 BBN
August 1987
Some Comments on
Status of this
This memo is a discussion of some of the ideas expressed in RFC-1016
on Source Quench. This memo introduces the distinction of the
of congestion in a gateway between the effects of "Funneling"
"Mismatch". It is offered in the same spirit as RFC-1016;
stimulate discussion. The opinions offered are personal,
corporate, opinions. Distribution of this memo is unlimited
It appears to me that there are at least two qualitatively
types of congestion which may occur at Internet gateways. One
of congestion is the result of the merger of several independent
streams from diverse sources at a common point in their
path. I'll refer to this as "Funneling". The architecture of
Internet (apparently) assumes that traffic flows are bursty
asynchronous; therefore congestion which occurs at the result
Funneling will typically be the result of "bad luck" as
independent bursts happen to arrive at a common point simultaneously
It is expected that Funneling congestion will be short-lived, just
individual bursts are. I don't claim that any such assumptions
documented or formalized; nevertheless I got a clear sense of
class of assumptions both from reading the protocol documentation
from personal recollections of long-past design meetings
A second form of Internet congestion may arise during a
(non-bursty) data transfer between hosts when the resulting
must pass through a node connecting two communications
with significantly different throughput rates. I'll refer to this
"Mismatching". By contrast with Funneling, Mismatching can be
by the innocent action of a single host, is highly
(definitely not just "bad luck"), and will be long-lived
RFC- 1016 discusses two interrelated strategies; one for when to
a SQ, and a second for what to do when an SQ is received. There
also a discussion of some experiments, which deal almost
with Mismatching congestion. (I understand that the simulation
generate multiple flows, but these simply further increase the
of Mismatch; the flow under study is long-lived by design.) It
to me that the strategy RFC- 1016 proposes for sending SQ's, based
queue length, may be appropriate for Funneling Congestion,
inappropriate for Mismatch congestion, as discussed below. The
McKenzie [Page 1]
RFC 1018 Some Comments on SQuID August 1987
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
of this congestion to attempt to smooth it without excessive
actions. This is the basis for the "hint" in the ICMP
that maybe an SQ should be sent only when a datagram is dropped.
is the basis for the idea in RFC- 1016 that a gateway should be
to cry "congestion" (SQK = 70% of queue space filed), even
persistent in attempting to eliminate it (SQLW = 50% of queue
filled). Since Funneling congestion is the result of the actions
multiple senders, the growth of internal queues is the
reasonable place to watch for its existence or measure its effects
Mismatch congestion, on the other hand, is the result of incorrect
inadequate information about available transmission bandwidth on
part of a single sender. The sending host has available to
information about destination host capacity (TCP window size and
rate) and about local link capacity (from the hardware/
interface to the directly-connected network), but no real
about the capacity of the Internet path. As noted in RFC-1016,
can obtain the best throughput if their datagrams are never dropped
and the probability of dropped datagrams is minimized when hosts
at the appropriate steady-state rate (no "bunching"). Therefore,
is a disservice to a host which is the source of Mismatch
to wait a "long" time before taking control action. It would
preferable to provide immediate feedback, via SQ's, to the host
soon as datagrams with too short an inter-arrival time begin
arrive. The sending host could then immediately (begin to)
its behavior for the indicated destination
There are, of course, many implementation issues which would need
be addressed in order to implement the type of SQ-sending
suggested here. Perhaps, though, they are not as severe as
might appear. Two specific issues and possible solutions, are
1. How should a gateway differentiate between Funneling
mismatch congestion? Perhaps whenever there are more than q
items on an output queue to a slower subnet which have
received from a faster subnet, then look to see if any h" of
have the same source. It so assume Mismatch and send an SQ
that source. The "q" test might be implemented by a small set
counters which are incremented when a packet is placed on
output queue and decremented when a packet is sent. The
for a common source might require more cycles but be
less often. The value of "q" would have to be small enough
give an early warning, but bigger than a small multiple of "h".
The value of "h" would have to be big enough to avoid
McKenzie [Page 2]
RFC 1018 Some Comments on SQuID August 1987
on common cases of source datagram fragmentation by
intermediate gateway
2. How can a gateway determine which subnets are "slower"
faster", as well as appropriate inter-arrival times? There may
lots of clever ways for a gateway to measure the dynamic
of its directly-connected subnets. However, I'm more in favor
starting with configuration parameters related to the known (
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
subnet is faster, or what inter-arrival time is appropriate
packets being routed to a slower subnet
Funneling congestion and Mismatch congestion are
different, and it would not be surprising if different SQ-
strategies were best for dealing with them. RFC- 1016 suggests
specific SQ-sending strategy which may be inappropriate for
with Mismatch congestion. This RFC suggests guidelines for
additional SQ-sending strategy for dealing with Mismatch.
implementing the SQuID algorithm of RFC-1016 should be expected
achieve better performance if they received SQ's sent according
either or both of these strategies. However, all these ideas
still only in half-baked form; real engineering is clearly needed
McKenzie [Page 3]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
