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: 2000-Sep-12
Document File: 3 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A.M. McKenzie: AUTHOR

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 ASCII document.
This is the abbreviated version, containing approximately 37% 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 Funnel...