<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 18:12, schrieb
<a class="moz-txt-link-abbreviated" href="mailto:dpreed@reed.com">dpreed@reed.com</a>:<br>
</div>
<blockquote cite="mid:1356714754.081314280@apps.rackspace.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<p>As far as questioning the rule by controlling congestion within
the network, how would you propose to do that without also
signalling to the sources that they must back off?  Somewhere a
queue will fill.</p>
<p>Â </p>
<p>In general, we have not achieved nearly universal congestion
signalling in the routers and switches. This is what Jim
Gettys, Vint Cerf, and Van Jacobson are trying (against
resistance) to do - to stave off bufferbloat's effects.</p>
<p>Â </p>
<p>Bufferbloat has such a huge effect (easily measured, as I did
in the ATT cellular network a few years ago in nearly every city
in the US that I visited, when I discovered up to 4 seconds of
latency with *zero* packet loss end-to-end, which means complete
service unavailability for all data services, especially web
pages). <br>
</p>
</blockquote>
<br>
With particular respect to that observation: As you remember, I
asked for the reasons of latencies dozens of times, at least on this
mailing list. And I well remember, that some years ago Dominik
Kaspar presented some extreme latencies and there was a big
astonishment and a long discussion how this could be.<br>
<br>
So: What's the reason for 4 seconds of latency? One reason COULD be:
A mobile interface simply gets no service for 4 seconds due to
opportunistic scheduling, and a simple stop n' wait TCP has a 4
seconds coffee break.<br>
<br>
Not to be misunderstood: I well see your question. However, when we
talk about latencies, the first and most important task is to
properly identify the reason for this latency. I deal with wireless
latencies and the question for the reason for about 13 years now.
And instead of concrete answers for the reason, the by far most
often answer I got was pure finger pointing and hand waving. This
includes statements like: "GPRS is badly implemented" or "anything
will be better using LTE" or "no buffer no bloat" or similar
nonsense.<br>
<br>
Perhaps, I'm bit childish in this respect, but I strongly believe
what I wrote some hours ago, that we have to break the problem into
pieces we can handle.<br>
<br>
With all due respect to the existing work in this area, it might be
not the wisest decision to tackle a huge and incredible complex
problem (and I don't know, whether system theorists are reading here
in the news group, however I think the often hopeless naive manner
how we CS guys tackle control theoretic problems makes them cry and
giggle at the same time) with an extremely restricted number of
means and tools.<br>
<br>
As I stated last night: VJCC (and derivatives) tackle three tasks:<br>
- stability,<br>
- performance,<br>
- ressource sharing.<br>
<br>
Each of these is extremely complex by itself - and we tackle it by
ONE means: The one and only end 2 end congestion window.<br>
<br>
(And when I'm provoking people here: As we see, that our tool is
perhaps too simple for the problem, we introduce e.g. active queue
management and those things, so that our system becomes even more
complex. So, when we cannot solve simple problems, let's start with
complex ones, this might be easier.)<br>
<br>
When we talk about an end 2 end latency of 4 seconds without packet
loss, this phenomenon may result from about a dozen reasons or so.<br>
So the first question is: What is the reason? And the next question
is: How can we help it?<br>
<br>
<br>
<br>
<br>
</body>
</html>