Re: Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6

Am 28.12.2012 18:12, schrieb [email protected]:
>
> 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 
coffee break.

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 
can handle.

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:
- stability,
- performance,
- 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?