[e2e] Latency Variation and Contention.

[Ted Faber]

On Wed, Aug 17, 2005 at 07:37:06AM -0700, Joe Touch wrote:
> Detlef Bosau wrote:
> > Here in Germany, we have a saying: "Das Fundament ist die Grundlage
> > jeglicher Basis." I don?t know whether there exists an english
> > equivalent, but this makes the very difference whether a space shuttle
> > pilot coming home is busy with landing or busy with prayer.
> 
> Ours is "correlation != cause & effect". Gets at the same point, at the
> end of the day.

You're basically right, but lets be a little more precise.

In any network that queues packets, in the absence of any other effects,
the onset of congestion will result in an increase in the RTT of a given
connection sampled over an RTT.  This is a causal relationship:
congestion causes RTT increases. 

There are at least 3 problems with using that observation to detect
congestion: 

	1. Lots of other things (OS artifacts, route changes, wireless
	   delays, ARQ) cause RTT variation.  Just as with using packet
	   loss as a congestion indication, a mistaken inference can
	   cause a source to slow when unnecessary or speed up when
	   unwarranted.

	   All congestion causes RTT increases; not all increased RTTs
	   indicate congestion.

	2. Sometimes the change caused by congestion is too small to be
	   reliably detected, even without the noise sources above.
	   This can be because there are a lot of sources in a net near
	   capacity or a lot of fixed delay on the path (queueing delay
	   Earth to Mars might be hard to detect).  Small queues also
	   make this difficult, and if the recent SIGCOMM work on sizing
	   routers is to be believed, small buffer sizes may become more
	   common.

	3. The queueing discipline in use can make detection of
	   congestion related RTT increases, even without confounding
	   noise in that signal and when the change is detectable, a
	   matter of statistics.  The amount of change in RTT that a
	   source sees will be affected by how other packets are
	   interleaved.  A source can detect a small change in RTT in a
	   byte-fair WFQ system much more quickly and reliably than in a
	   FIFO system with varying packet sizes.  Having to sample and
	   analyze increases the work the sender does and slows the
	   reaction time of sources.

Certainly many systems have been proposed that ise RTT as a congestion
indication, from Vegas through FAST to a bunch I've certainly lost track
of.  To use it as the only indication, successfully, in a rich network
environment, requires addressing at least the problems above.  There are
also cases where the network environment is less rich and you can rule
one or more of these out.

Congestion causes RTT increases.  Finding those RTT increases that are
due to congestion can be tricky.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050818/4c027bfe/attachment.bin