Re: Redirection to Other IP Addresses

Hi Mike,

Thanks for your comments!

Based on my understanding, "alt-svc" is designed to handle clients using
one persistent TCP connection to issue many HTTP requests, especially
HTTP/2.
The reason that "alt-svc" is not good for my #1 is that we are talking
about serving very large files, which may take minutes or even hours to
download.
The European server knows that some other server in North America will be
way faster so it wants force (instead of suggest) the client to reconnect
to the other one.
Maybe a "real smart" client would abort the current connection when it sees
the "alt-svc" header and reconnect to the new server when the file is large?
At least it seems ugly to me.

About the #2 case, yes, some hostname just have lots of objects that is too
much for one proxy cache server to hold them all.
Or the cache servers don't want its storage be hogged up by the objects of
one or a small number of hostnames.
They decide to collectively form a distributed storage/cache. Being
redirected 66% of the time or even 99% of the time is not an issue at all.
Again, we are talking about large files.

Bin




On Mon, Jul 29, 2019 at 12:24 PM Mike Bishop <mbishop@evequefou.be> wrote:

> #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 <nibin@quantil.com>
> *Sent:* Monday, July 29, 2019 3:02 PM
> *To:* Kyle Rose <krose@krose.org>
> *Cc:* Ben Schwartz <bemasc@google.com>; Oliver, Wesley, Vodacom South
> Africa (External) <Wesley.Oliver@vcontractor.co.za>; Julian Reschke <
> julian.reschke@gmx.de>; Ryan Hamilton <rch@google.com>;
> ietf-http-wg@w3.org
> *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 <krose@krose.org> wrote:
>
> On Mon, Jul 29, 2019 at 9:46 AM Ben Schwartz <bemasc@google.com> wrote:
>
> On Mon, Jul 29, 2019 at 3:40 AM Oliver, Wesley, Vodacom South Africa
> (External) <Wesley.Oliver@vcontractor.co.za> 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: Image removed by sender. Quantil]
>
> Connecting users with content...it's that simple.
>
> Office: +1-888-847-9851 <(888)%20847-9851>
>
>
> [image: Image removed by sender. Tweeter]
> <https://twitter.com/Team_Quantil>  [image: Image removed by sender.
> Google Plus] <https://plus.google.com/+Quantil_team/>  [image: 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/>
>
>
>


-- 

Bin Ni
VP of Engineering
[image: Quantil]

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

Office: +1-888-847-9851 <(888)%20847-9851>

[image: Tweeter] <https://twitter.com/Team_Quantil>  [image: Google Plus]
<https://plus.google.com/+Quantil_team/>  [image: 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/>