[e2e] Question about propagation and queuing delays
detlef.bosau at web.de
Tue Aug 23 06:25:47 PDT 2005
Ian McDonald wrote:
> As a lucky guy doing a PhD on congestion control I couldn't resist the bait :-)
> I may be missing something but we need congestion control as long as we have networks. In the USA
I´m totally with you.
> and in Europe you may all have unlimited bandwidth available at virtually no cost to you but in the
> rest of the "real world" it doesn't quite work like that. So as long as you are bandwidth
> constrained you will need congestion control. I think others are out of touch of reality....
> </flame bait off>
Excuse me, where is the flame bait? What you say is abolutley correct
and I totally agree with you!
I will only give one example (I always tend to write too much...). When
I worked as a network adminstrator in northern Germany we had to attach
some points of sales to a company network which were situated in the
It is interesting to observe people who always talk about ISDN, DSL,
backbondes with large bandwdith, and now you are informed: "We do not
yet know whether 9k6 can be achieved, we have to check the old POTS
line, it may be too noisy."
Depending on where you are, you may perfectly encounter different
realities! Even here in Germany you may encounter stone aged POTS lines
in some rural areas.
When I read what you say, I would like to invite you into my ISP´s
support newsgroup, I think much of the readers can learn a lot from you!
Just to give one example from there: We recently had a discussion about
"Fastpath". In DSL lines, you need error recovery on the last mile. Now,
to save overhead you do codespreading/interleaing. Some "well informed
guys" want the ISP to turn interleaving off in order to spare some "ping
time". First of all, it´s simply ridiculous, theat individual customers
without any technical knowledge will prescribe the provider the
appropriate line coding for one individual wire pair. Second: Not only
these customers may be affected by increasing error rates: These guys
flood large portions of the network with defictive frames, more
precisely with defective ATM cells with corrupted payload, which is
eventually being detected at the customers AAL 5 peer. (At least AFAIK.)
This is thoughtless waste of bandwidth, but it is nearly impossible to
convince those guys that this is malicious in quite a number of cases!
What is even more disastrous: In fact, in DSL TCP appears to be based
upon AAL5/UBR. Unspecified bitrate. Hence, all congestion control is
done at the TCP endpoints. I´m totally with you that this requires well
behaved participants in a network. IIRC, LANE works with ABR and that
will alleviate the problem.
> Seriously traffic can be constrained for many different reasons apart from backbones:
> - link at other end (e.g. web server) is on a "slow" link
> - mobile networks
> - link between ISP and upstream ISP (a particular problem in NZ at the moment)
> - slow speed link at consumer premises
Could you _please_ join this newsgroup :-)
> Most backbones are over provisioned in the developed world but less so in more remote corners and
> even less so in developing countries. I have seen presentations showing >50% packet loss in parts of
> Asia and Africa on this list in the last few months - surely you need congestion control for that!
Excuse me, but I don´t mind congestion control! Of course we need it!
Perhaps my command of the englisch language is rather poor. But I
sincerely hope that no one had misunderstood me that way that I denied
the necessity of congestion control!
The problem _I_ expect is, that congestion control and even proper
retransmission control can run into severe problems, when TCP timers
And when I talked about the Internet as it is perceived in Europe and
the US, I concluded that in _this_ area TCP works fine.
Whether this holds true all about the world and in all kinds of networks
is highly questionable.
So, I really don´t see a flame bait here. Perhaps you understood me in a
but from what you wrote I couldn´t agree with you even better!
Mail: detlef.bosau at web.de
Mobile: +49 172 681 9937
More information about the end2end-interest