<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 28.12.2012 15:28, schrieb
<a class="moz-txt-link-abbreviated" href="mailto:dpreed@reed.com">dpreed@reed.com</a>:<br>
</div>
<blockquote cite="mid:1356704890.01121623@apps.rackspace.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<p>Bufferbloat arises because of the lower layers' lack of
congestion signals (dropped packets) while the lower layers
attempt (using large amounts of buffering) to avoid loss (lost
packets).</p>
</blockquote>
<br>
O.k., however this is not a contradiction to what I said!<br>
<br>
If, e.g. for increasing noise, the delivery time for packets over
wireless interfaces increases, buffers may not be freed and the
"path capacity" (quotes intended) drops. <br>
<br>
So, this can be one reason for buffer bloat, do you agree here?<br>
<br>
<blockquote cite="mid:1356704890.01121623@apps.rackspace.com"
type="cite">
<p>Â </p>
<p>In other words, by focusing on keeping packets alive at any
cost, the Internet loses all of its basic congestion detection.</p>
</blockquote>
<br>
Absolutely agreed!<br>
<br>
<br>
<blockquote cite="mid:1356704890.01121623@apps.rackspace.com"
type="cite">
<p>Â </p>
<p>For the Internet, it *really does not help* to use buffering to
hide natural channel problems - either delay or transmission
errors.</p>
</blockquote>
<br>
Agreed. <br>
<br>
However, it may help to use buffering to compensate varying service
rates. The emphasis lies on "varying". In addition: For doing so, it
is *absolutely crucial* to care fore stability. <br>
<blockquote cite="mid:1356704890.01121623@apps.rackspace.com"
type="cite">
<p>Â </p>
<p>That's because the consistent rule in the Internet is to build
the end-to-end required functionality *at the endpoints* and not
in the network. That applies to wireless as well as wired.</p>
</blockquote>
<br>
David, you might have guessed this: I would like to put this rule in
question. I think we should care for congestion control not only at
the endpoints but at certain places (which are to be defined) in the
network as well.<br>
<br>
<br>
<blockquote cite="mid:1356704890.01121623@apps.rackspace.com"
type="cite">
<p>Â </p>
<p>The solution to congestion in the network is *not to allow the
network to stay congested* - which means aggressively dumping
queued packets whenever the queue builds up at any link to more
than 1 packet.</p>
</blockquote>
<br>
Doing so might waste a lot of performance. However, in some cases,
this may be necessary. Perhaps, we have to agree upon "it depends".<br>
<br>
<blockquote cite="mid:1356704890.01121623@apps.rackspace.com"
type="cite">
<p>Â </p>
<p>Paradoxical it may seem. But it's the same rule as with
"garbage collection" in large Java systems: whatever you do,
don't wait until the memory is completely full to garbage
collect! That is the worst case operating point of the system
in terms of jitter and gives you worse throughput as well.Â
Garbage collection when the memory is about 1/2 garbage and 1/2
good stuff is much, much better for throughput, and garbage
collecting even earlier works better for worst-case latency and
jitter.  This is how one sets the "control loop" for garbage
collection wisely.</p>
</blockquote>
<br>
David, what is the control loop of congestion control controlling?
(I sometimes think, we should have not only a second look at the
congavoid paper but it is worthwile to give it even a ninth and a
tenth look. I think, there is a huge confusion about what we are
controlling at all!)<br>
<br>
<blockquote cite="mid:1356704890.01121623@apps.rackspace.com"
type="cite">
<p>Â </p>
<p>The same thing for network buffers - *never* let an internal
queue build up to more than 1 packet on a sustained basis.</p>
</blockquote>
<br>
Not on a sustained basis. However: On a controlled basis AND WITH
CAREFUL KNOWLEDGE OF WHAT WE ARE DOING!<br>
<br>
Please don't mind my emphasis. I think, we agree upon the pitfalls.
However, I don't want to totally stay away from them, but when we
run into a pitfall, we must take great care to not only get into it
but to find a way out as well.
</body>
</html>