Richard Welty <email@example.com> wrote:
>i can't find the quote, so i'm not sure if i should attribute it to Floyd
>or to Jacobson, but the gist of it is "networks are easily driven into
>congestion, and hard to recover from it".
SMTP is a small fraction of Internet traffic, dwarfed by http and
ftp. Only a part of the SMTP traffic is multiple recipient mail. Only
a fraction of multirecipient mail goes to multiple recipients on an
MX. Only a fraction of that is delivered by qmail. Only fraction of
that will result in simultaneous connections to an MX.
I think it's a little alarmist to claim this is a serious concern.
>i'm somewhat of a routing weenie, and i find Sill's casual dismissal of
>critical issues in congestion control appalling. i'd been uncertain how to
>explain why qmail delivery methods bugged me, but the TCP congestion
>analogy is of staggering relevance.
"Death of the Net predicted. Film at eleven."
>the problem is that qmail assumes that bandwidth is cheap. on a bad day in
>MAE-East, a day when nobody's favorite porn site is loading particularly
>fast because of 20% packet loss in the overloaded tree of gigaswitches,
>bandwidth is most assuredly Not Cheap, or really, even available. in such
>an environment, intentionally generating extra packets because of a mail
>delivery theory is pretty #@$#!## irresponsible.
(a) it's not "theory" that causes qmail to do what it does, it's
(b) what percentage of MAE-East's traffic is multirecipient->single MX
SMTP? Divide that by http traffic. Compare to zero.
>so this discussion has effectively moved me from finding qmail conceptually
>annoying to now feeling pretty pissed off about it and the BS theory behind
>it -- because i now suddenly realize qmail's implications for the stuff i
>do for a living.
You're getting worked up over a nonissue.
>i suggest that mr. sill read something that covers congestion well
If I had any evidence that qmail was even a measurable blip on the
congestion graph, I might. Until then, I'll concentrate on real