RE: Redirection to Other IP Addresses

[Mike Bishop <[e-mail]>]

#2 is… odd.  So no one server is able to serve all the resources on a given hostname; instead, for each resource, there’s a 66% probability that the server you’re currently talking to tells you to go elsewhere instead.  I’m unaware of this being common for CDNs, and seems like exceptionally bad practice – they should be three different hostnames.  (Note that a single reverse proxy might have internal logic to hide the fact that the resources are actually provided by a variety of origin servers.)

For #1, this is exactly one of the Alt-Svc use cases – the client can continue to use the connection to Europe, but is advised to use a different IP address because performance will improve.  It’s an optimization, and advisory.

The desire for deterministic behavior is understandable, but the path to deterministic behavior is having hostnames that resolve to servers able to serve the content.  If the server can answer the request but is non-optimal, you’re now firmly in optimization territory.

From: Bin Ni <[e-mail]>
Sent: Monday, July 29, 2019 3:02 PM
To: Kyle Rose <[e-mail]>
Cc: Ben Schwartz <[e-mail]>; Oliver, Wesley, Vodacom South Africa (External) <[e-mail]>; Julian Reschke <[e-mail]>; Ryan Hamilton <[e-mail]>; [e-mail]
Subject: Re: Redirection to Other IP Addresses

Yes, what we want is a way to force a "deterministic behavior from the client", just like all the 30X redirections today.

Let me give a few more cases in which this can be helpful:
1. A client in North America is returned a server IP in Europe by the DNS. The server then wants to direct the client to another server in North America for better performance.
2. The content of a website is hashed to multiple servers based on URL. These multiple servers may not even be in the same datacenter. The DNS does not have this information and may return any IP to any query of the website's hostname.  Each server will calculate the hash for each request and redirect client to the correct server that has the content. This is quite common for CDN.

Usually this kind of redirection is applied to large objects, where the overhead of one more round trip is negligible.

Bin

On Mon, Jul 29, 2019 at 7:48 AM Kyle Rose <[e-mail]<mailto:[e-mail]>> wrote:
On Mon, Jul 29, 2019 at 9:46 AM Ben Schwartz <[e-mail]<mailto:[e-mail]>> wrote:
On Mon, Jul 29, 2019 at 3:40 AM Oliver, Wesley, Vodacom South Africa (External) <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I would like to suggest, that this not be a specific response code, like a
312 or 302. That it just be a response header, that gets checked by
Inteligent clients, would then always check for the new address and port on which to contact the server,

You're in luck: this is precisely the Alt-Svc header (RFC 7838).  You can use this today!

Not all clients currently implement full support for this header, but hopefully that will improve over time.

I think the issue OP is raising is that they want some deterministic behavior from the client, dictated by the server. Alt-Svc doesn't do this: it's advisory. As a result, it can be used as an optimization, but some kind of load balancer for the original service is still required for clients that do not react to Alt-Svc (should that population be large enough), or when the target Alt-Svc is down. As long as that's within OP's constraints, I agree Alt-Svc is precisely the right solution.


--

Bin Ni
VP of Engineering
[Image removed by sender. Quantil]

Connecting users with content...it's that simple.

Office: [phone]<tel:(888)%20847-9851>

[Image removed by sender. Tweeter]<https://twitter.com/Team_Quantil>  [Image removed by sender. Google Plus] <https://plus.google.com/+Quantil_team/>   [Image removed by sender. Linked In] <https://www.linkedin.com/company/quantil>

The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to QUANTIL, INC. at 1919 S Bascom Ave #600, Campbell, CA 95008<https://maps.google.com/?q=1919+S+Bascom+Ave+%23600,+Campbell,+CA+95008&entry=gmail&source=g>, or visit our website at www.quantil.com.<https://www.quantil.com/>