Browse Prior Art Database

Some comments on SQuID (RFC1018)

IP.com Disclosure Number: IPCOM000001822D
Original Publication Date: 1987-Aug-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 3 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A.M. McKenzie: AUTHOR

Related Documents

10.17487/RFC1018: DOI

Abstract

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

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 [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 sites of this congestion to attempt to smooth it 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 ...

Processing...
Loading...