88 lines
4.4 KiB
Plaintext
88 lines
4.4 KiB
Plaintext
MBOX-Line: From blong at google.com Tue Jan 14 14:05:21 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] Login referrals resurrection?
|
|
In-Reply-To: <FF6E4621-3C20-4C20-AE79-9E62CC9322CC@iki.fi>
|
|
References: <FF6E4621-3C20-4C20-AE79-9E62CC9322CC@iki.fi>
|
|
Message-ID: <CABa8R6s366RnvJ632Fzh0JDUE9rjaYbmWxA6CAo-R8LVi040KA@mail.gmail.com>
|
|
|
|
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>
|