[e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6
detlef.bosau at web.de
Sun Dec 30 06:45:28 PST 2012
Am 28.12.2012 18:12, schrieb dpreed at reed.com:
> 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.
> 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.
> 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).
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.
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
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.
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
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.
As I stated last night: VJCC (and derivatives) tackle three tasks:
- ressource sharing.
Each of these is extremely complex by itself - and we tackle it by ONE
means: The one and only end 2 end congestion window.
(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.)
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.
So the first question is: What is the reason? And the next question is:
How can we help it?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest