[e2e] Latency Variation and Contention.
faber at ISI.EDU
Thu Aug 18 08:59:09 PDT 2005
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
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
All congestion causes RTT increases; not all increased RTTs
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
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.
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
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050818/4c027bfe/attachment.bin
More information about the end2end-interest