[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
	action verb.)

	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
	like this:

	.pe	smtpx![inside.gw.ip.number]
	.	smtp!

	Within the country you will need opposite dataset:

	.pe	smtp!
	.	smtpx![outside.gw.ip.number]

> 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 <mea@nic.funet.fi>