<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">O.k., I just asked fro additional space
for my mailbox because of the expected responses.<br>
<br>
Isn't AQM nothing else than some kind of "sophistically discard"
packets?<br>
<br>
Any discarded packet is a potential retransmission.<br>
<br>
So, don't we run into the risk of suffering from a retransmission
collapse?<br>
<br>
The more I think about it, the more I think that all this AQM
stuff does not really <i>solve </i>a problem but <i>causes</i>
a problem.<br>
<br>
In some private message, the sender remarked: "A congestion
control scheme that causes congestion - funny."<br>
<br>
Wouldn't it be the better alternative to avoid congestion than to
fix it?<br>
<br>
Detlef <br>
<br>
Am 17.03.2013 04:25, schrieb Daniel Havey:<br>
</div>
<blockquote
cite="mid:1363490725.39918.YahooMailClassic@web163005.mail.bf1.yahoo.com"
type="cite">
<pre wrap="">Hi Fred,
</pre>
<blockquote type="cite">
<pre wrap="">We now have at least two AQM algorithms on the table that
auto-tune.
As such, while the general statement of 2309 is a good one -
that we need to implement AQM procedures - the specific one
it recommends turned out to not be operationally useful.
As to the specific statement that Lloyd seeks, and notes
that the TCP community argues for one specific answer, I'll
note that operationally-deployed TCP has more than one
answer.
</pre>
</blockquote>
<pre wrap="">Well, perhaps all of the TCP community does not argue for one specific answer.
Let's think about Joe's thesis.
They are complementary:
FEC (including erasure codes) always completes in finite time,
but has a nonzero probability it will fail (i.e., that the
data won't get through at all)
ARQ always gets data through with 100% probability when
it completes, but has a nonzero chance of taking an
arbitrary long time to do so
This tells us that if we have horrible RTT then TCP retransmission will be a drag. However, if we have a nice RTT then TCP retransmission is what we want.
One solution does not fit all.
...Daniel
</pre>
<blockquote type="cite">
<pre wrap="">There is Microsoft's Congestion Control algorithm,
NewReno in FreeBSD, and CUBIC in Linux. There are other
algorithms such as CAIA CDG that also fill the bottleneck in
a path but manage to do so without challenging the cliff,
which at least in my opinion is a superior model.
Similarly, it is difficult to argue that everyone has to
implement the same AQM algorithm. What is reasonable without
doubt is that whatever algorithm is implemented, the
requirement is that it manage queue depths to a
statistically shallow queue.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
skype: detlef.bosau
ICQ: 566129673
<a class="moz-txt-link-abbreviated" href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a> <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
</pre>
</body>
</html>