<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<font face="Helvetica, Arial, sans-serif">To me it comes down to a
simple thing:Â Â <br>
<br>
end-to-end packet latency matters to the higher layers,<br>
<br>
controlling the combined incoming rate of packets must be done at the
endpoints, since they are the only place to back off,<br>
<br>
Internal bottlenecks cause large queueing delays to build up, and
absent packet drops, those queues will drain only as fast as the
outgoing links that service them can carry packets,<br>
<br>
The *application* control loops to manage application layer backoff
share the same paths and the same queueing delays as do all the rest of
the packets, (this could be ameliorated by making a separate flow
control channel, but there are a wide range of applications that would
prefer to back off intelligently - e.g. use lower rate codecs or decide
to go drink coffee and come back when the net is more lightly loaded -
so the control channel cannot be based on some fixed theory that hides
control from apps).<br>
<br>
In any case, in today's TCP, we should be seeking Kleinrock's optimum
steady state - a pipelining state such that no router *ever* has more
than one packet in each outgoing queue (on the average).  On links
that are not bottlenecks, the average is << 1 packet in the
outgoing queue, on links that are bottlenecks, the combined flows
traversing that link are such that the average queue length is 1 packet.<br>
<br>
This is the "minimal latency" state that sustains the maximum overall
achievable throughput of a steady state network. Analogous to a
single-queue being "double buffered", where a new packet arrives just
as the old packet completes.<br>
<br>
Because of the delays in the control loops at the endpoints that cannot
measure without long delay, entry and exit of new flows, and other
non-steady-state things, we actually are able to tolerate queue
averages a few packets (2-3) long on the average, in service of keeping
throughput up in the worst case without resonances and other problems
that relate to control instabilities.<br>
<br>
It's not the size of the buffers that matters - they handle transients
better. What matters is not dropping packets feeding into a bottleneck
aggressively enough to keep the outgoing queue drained, so it doesn't
build up sustained backups of obsolete packets.<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font><br>
On 09/18/2009 09:59 AM, Detlef Bosau wrote:
<blockquote cite="mid:4AB3923F.9040902@web.de" type="cite">Hi to all,
<br>
<br>
this debate continues to appear here now and then in the list ;-) and
to my understanding, the positions are quite extreme here.
<br>
<br>
On the one hand, there are some standards, who do "heroic effort"
(credits to DPR ;-)) and allow to configure even a SDU corruption ratio
10â»9.
<br>
<br>
On the other hand, there is e.g. DPR, who does hardly any effort and
says, there should be typically not more than three transmission
attempts.
<br>
<br>
I would like to understand these positions a bit better than now and
perhaps, there are some strong facts, which support the one or the
other view.
<br>
<br>
Detlef
<br>
<br>
</blockquote>
</body>
</html>