I assume this would also mean that all of the "more specific" locations
would need to be alt names in the ssl certificate.
If you were blind load balancing (ie, just multiple A records), then this
would clearly be a win, but I'm not sure how many people with multiple DCs
are doing that. Even then, knowing which proxy point is closer to the
user's backend may be easy to know, but knowing which proxy point is the
better network mid-point from the user to the backend is harder. Granted,
that's more likely a problem once you go beyond two DCs, where the user may
be closest to a DC which doesn't have their data. And I guess you can
always go with "give them a proxy closest to their data and let the network
figure out the best path to get there".
There's also the question of how do you handle having the user's data in
multiple DCs and the user traveling, though presumably you'd just evaluate
every time and it improves the next connection. With mobile devices, a
user could have many very different network paths through-out the day.
Is it common for people with multiple DCs to have blind DNS load balancing?
We would be unlikely to implement this because our load balancing is not
blind and our network topology is designed to get people onto our network
as their closest point. Also, load balancing for us is not strictly geo
based, otherwise we'd need a lot more capacity to handle daily peaks from
different parts of the world.
Brandon
On Tue, Jan 14, 2014 at 1:32 PM, Timo Sirainen <tss@iki.fi> wrote:
> I started wondering today if it would be a good idea to bring back the
> login referrals, only a little bit changed from their original behavior. I
> guess originally they didn't really get used because few clients supported
> them and proxying works for everyone. But nowadays many larger
> installations have IMAP proxies and backends in multiple data centers and
> even though everything works, doing unnecessary proxying between data
> centers increases latency and often also costs money. Using DNS to give the
> correct data center IP based on the source IP might work for some users,
> but that's somewhat difficult to set up and likely won't work very well for
> the increasing number of mobile users. So what if we got the most popular
> clients to implement support for login referrals and use them?
>
> Problem 1: LOGIN tagged OK [REFERRAL] reply conflicts between
> Lemonade-required OK [CAPABILITY] reply.
>
> So either one of them needs to be moved to an untagged OK reply. RFC 2221
> only talks about tagged OK reply, while RFC 5550 makes it possible to use
> untagged OK reply. But I'm a bit worried about changing this now, there may
> well be clients that handle only the tagged OK [CAPABILITY] while there are
> almost no clients that handle [REFERRAL] anywhere. So my preferred server
> reply would be:
>
> * OK [REFERRAL imap://user;AUTH=*;us1.imap.example.com/] Use this server
> for decreased latency
> a OK [CAPABILITY ...] Logged in.
>
> Problem 2: RFC 2221 specified OK [REFERRAL] to mean that user's mailboxes
> aren't on this server, but some shared mailboxes are.
>
> Instead now the OK [REFERRAL] should simply be a suggestion to the client
> to connect to the specified server to get better latency, but it would work
> just as well to just ignore it and keep using the current server. In fact
> the client likely shouldn't reconnect at all, but just create all future
> connections using the referral's server. If the referral server ever fails,
> the client should connect back to the original server.
>
> Does anyone else think this would be worth maybe writing a new updated
> RFC2221bis and trying to convince client developers to implement it?
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140114/87fc4d6b/attachment.html>