[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ZMailer for slow connection
> > Again, not much has been said about the details on this persons mail
> > server...
> Ok, i will elaborate a little about my mail server now.
Ah, Arnt did comment also, and many of his thoughts are valid.
> My ZMailer server is located in the US, it's the lowest preference MX (0)
> to 'somedomain.com' which is in a country with a heavily used 64K connection
> to the net for the *WHOLE* country. Now, even though their connection is
> crazy slow, they receive a lot of email, i have seen that yesterday some
> 100 MB of email were received and i had, at one moment, some 1.900
> messages queued, so i started denying all incoming mails to just let my
> server deliver the whole thing.
> The server is a SS10 100Mhz 128MB RAM whose load average is very low = 0.10
> When i send 256-byte packets to the 2 only servers on the other side that
> receive the mails, last night at 4 AM, i got round-trip (ms) avg = 3006,
> during the day, right now for example, i get round-trip (ms) avg = 6032
> packet loss is usually between 15% -> 50%.
At those loss ratios TCP becomes practically unusable..
Things I would do are:
Realize that the bandwidth of the pipe is circa 600 MB per day,
and if you can get that much thru, you are WIZARD.
Divide that pipe into two with channelizing equipment so that
you have two sub-channels running on it. For example 50%/50%
of which half you run IP routing for all uses the people want,
and half you run optimized UUCP-G protocol in sync channel.
(Up until about 1990, EUNET, and UUNET had 56kbps dedicated
link running UUCP-G just to feed usenet news, and email.)
With cisco routers there are choises of priority queueing, and
custom queueing with which it may be possible to guarantee certain
share of bandwidth to the smtp transport between intra and extra
country SMTP proxies even without resorting to esoteric hardware,
like channelizing equipments.
With SMTP and running PIPELINING systems at both ends you may
be able to get fairly close to that without resorting to "esoteric"
tricks like the UUCP-G. (SMTP is per nature half-duplex, and
the PIPELINING helps on that by allowing more asynchronous
operation without requiring synchronization rendezvous at every
The globally advertised DNS services should be on machines that
are in USA, perhaps even so that while you also advertise national
servers, those IP addresses are aliased (and host routed) to your
servers in USA. Similarly in that country the traffic destined
to the peer server in USA need to be aliased into inside server.
To be able to exchange DNS data in the country, and in your
frontends you need to have a third address for both machines
with which you exchange all of the "secondary" DNS definitions.
Urgh... It is not pretty... (but must be done with the DNS)
Perhaps easiest would be to have your router (cisco ?) to run
policy routing -- in the USA side for example all TCP packets
destined to smtp ports within the country are to be routed to
address N.N.N.N. To do successfull operation on this you will
need (what Linux calls) transparent proxy support. Similar
setup is needed for routing all smtp traffic from within the
country to proxy frontend. Then run dedicated prioritized
channel between the proxies.
Less complex approach could be having all internal hosts having
MXes listing primarily themselves, and secondarily your USA server.
Then you define filtering access lists at both ends prohibiting
SMTP from abroad to within the country, and vice versa with an
exception with these SMTP proxies.
For performance (this can be non-functionality issue, rather than
poor functionality -issue) reasons you should not block DNS lookups,
rather you should use the tree IP address approach I described
> I have proposed a whole solution to that country recently, to force the
> use of proxy servers, web redirectors to mirror sites abroad, routing
> filters and policies, and a bunch if mail solutions (i have written a
> 'smart' listserver wich optimizes mail usage too), but right now i am
> tackling just the web redirection issue and of course, the mail woes,
> they have not decided yet about the rest, and it scares me a lot.
> I was wondering if it would be worthy that i get into ZMailer sources
> and modify certaing things so i can adapt it to this kind of situation,
> but first of all i wanted to save time and efforts writing to the list
> and see if anyone can come up with a smart idea before i burn my brain.
Besides of possibly doing "transparent proxy support", there
really is no need for any esoteric new things. (But for TPS
you need UNIX kernel support too.)
In the outside country mail proxy you could use something
Within the country you will need opposite dataset:
> Thanks for your time,
> Enrique Vadillo-
> RCP - Internet Peru
> Fax: +51 1 241-1320
> Web Site: http://www.rcp.net.pe (PERU)
> Mirror Web Site: http://ekeko.rcp.net.pe (USA)
64kbps to the whole country ??? Huh!
On the other hand, the entire europe was once behind
about 64k bandwidth when looking from USA. But that
was back in early 1980es.
The initial bandwidth between NORDUnet, and USA was 56k
back in 1989. These days we have 79 Mbps, and even that
is saturating. In addition to this, there are about
200 Mbps capacity for commercial internet operators,
and for this I didn't calculate the mid/southern europe
at all. (But they have propably less combined than the
NORDUnet has alone..)
I don't mean to say that international transit is cheap,
but it is way less expensive from Nordic countries to
USA, than with the rest of the europe...
/Matti Aarnio <email@example.com>