Subject: Redirection to Other IP Addresses

From: Bin Ni <[email-masked]>
Date: Tue, 23 Jul 2019 16:32:29 -0700

Hi All,

We trying to propose an addition to the HTTP protocol to support
redirecting client to other IP addresses.

The background is many website owners and CDN providers want the web or
proxy servers to be able to participate in load balancing. For example,
when the server is overloaded, redirect the request to some other servers;
or based on the geo information of client IP address, send the client to a
server that can provide better performance. Compare to the DNS-based load
balancing, this method is more real time and more accurate. It can also
take the URL, headers or other components in the HTTP request into
consideration.

What they can use today is the 30X redirection, which has at least the
following limitations:
1. breaks the cookie, if you 30x redirect to another hostname or IP address.
2. breaks https if you redirect to another IP address.

We need another way of telling the client/browser to only change the IP
address but keep everything else the same.

We put the proposal in a google doc at:
https://docs.google.com/document/d/1gtF6Nq3iPe44515BfsU18dAxfCYOvQaekiezK8FEHu0/edit?usp=sharing
You can post your questions and comment in the document or reply to this
email.
If this is not the correct way to submit a proposal, someone please point
me to the right direction.
Thanks!
-- 
Bin Ni
www.quantil.com

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Jul 2019 11:02:53 +0200

On 24.07.2019 01:32, Bin Ni wrote:
> when the server is overloaded, redirect the request to some other
> servers; or based on the geo information of client IP address, send the
> client to a server that can provide better performance. Compare to the
> DNS-based load balancing, this method is more real time and more
> accurate. It can also take the URL, headers or other components in the
> HTTP request into consideration.
>
> If this is not the correct way to submit a proposal, someone please
> point me to the right direction.
> Thanks!
> --
> Bin Ni
> www.quantil.com <http://www.quantil.com>

Did you consider Alt-Svc? (See
<https://greenbytes.de/tech/webdav/rfc7838.html>)

Best regards, Jullian

---

From: Ryan Hamilton <[email-masked]>
Date: Sat, 27 Jul 2019 14:32:01 -0700

Agreed. Alt-Svc seems like a perfect fit for this case.

---

From: Bin Ni <[email-masked]>
Date: Sat, 27 Jul 2019 16:33:26 -0700

Thanks Julian and Ryan for bringing alt-svc to my attention.
It seems to be too complicated for my purpose but might work.

One question I have is: what should be the server's behavior if it wants to
force the client to use the alternative service immediately?
For example, from the request URI the server knows that the client is
requesting a huge file or video.
It does not want serve it at all and want the client to issue the same
request again to another server.
Which status code should the server return? 300?

Thanks.

Bin

-- 

Bin Ni
VP of Engineering

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

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

 <https://twitter.com/Team_Quantil>  
<https://plus.google.com/+Quantil_team/>  
<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/>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Jul 2019 09:14:22 +0200

> It seems to be too complicated for my purpose but might work.

Complex for the client or for the server?

> One question I have is: what should be the server's behavior if it wants
> to force the client to use the alternative service immediately?

Alt-Svc is always advisory only.

> Which status code should the server return? 300?

301 or 308, I'd say.

Best regards, Julian

---

From: Bin Ni <[email-masked]>
Date: Sun, 28 Jul 2019 00:38:03 -0700

Hi Julian,

So maybe the server can returns a 301 with no "location" header but a
"alt-svc" header to
force the client to go to that alternative service?
How are today's browsers implemented to handle this?
Is there any recommended implementation in any standard?
Or it is completely up to the client?

Thanks!

Bin

-- 

Bin Ni
VP of Engineering

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Jul 2019 10:18:26 +0200

> force the client to go to that alternative service?

Again, alt-svc is just advisory.

> ...
Best regards, Julian

---

From: Bin Ni <[email-masked]>
Date: Sun, 28 Jul 2019 01:50:07 -0700

Got it.
I just did some tests to see how Chrome deals with 300 or 301 with
"alt-svc" header.
It seems the browser does not retry the request with the alternate server.
So it looks "Alt-Svc", at least in its current form, does not meet my
requirements.
I just modified my proposal to indicate this fact.
https://docs.google.com/document/d/1gtF6Nq3iPe44515BfsU18dAxfCYOvQaekiezK8FEHu0/edit?usp=sharing
I think another way is to extend the current "Alt-Svc": When combined with
a special status code, say, 312,
the client *should* retry the current request with the suggested alternate
server.

What do you think?

Thanks!

Bin

-- 

Bin Ni
VP of Engineering

---

From: "Oliver, Wesley, Vodacom South Africa (External)" <[email-masked]>
Date: Mon, 29 Jul 2019 07:36:40 +0000

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,
port may be a problem, because of port blocking.

One wants to be able to return the existing response, 200, 304, 404, and then tell the client that the next request must go to a different ip address.
This would allow load balancing system described below, to inject load balance Repsonse header, instead of having big load balancer in front of everything.. The orchestrator just communicates the load balancing information to each of the server instances.

The reason that it should just be that there is no round trip delay and that we can integrate
The load balancing orchestrator, building the histogram that takes the cache response headers into account,
Future re-hit load time into account, to ensure that you only phase shift the load and not fully spread the load.

I will find a document I was writing after I BBC gave a presentation at dev ops day in Cape Town, South Africa,
Were the have variable content expire headers, according to the load, however, one thing they never too into account,
Is that they will just be phase shift the load to a future time. So when that impulse peak load hit them phase shift that into the future, were
The same clients will hit them in the same density again and peak impulse.

https://docs.google.com/document/d/1gxqCXJH7jpB8apc4pO3C0wrTT9kulMfhlSFtHeG3KbM/edit?usp=sharing

For security reason, I was thinking that similar mechanism would be required to force clients by the time of there next Repsonse to re-auth,
Or the ability to dynamically update signing of jwt and similar tokens schemes, provide additional field, to delay the next request by, phase shift the request. When security on a system is compromised, then the ability to force all clients tokens to be refreshed instantaneously, would cause
A lot of load. All this would need to happen without the client knowing there was security issues, and close the window of opertunatity as quickly as possible, as people are going to freak out, if you force them to all re-login. SO cycling the encryption  and signing of keys very quickly would be good, as then required to break them again. Hopefully they not uses any pre compute hashing and GPUs to be able to crack things too fast.

Kind Regards,

Wesley Oliver

On 28 Jul 2019, at 10:50, Bin Ni <[email-masked]<mailto:[email-masked]>> wrote:

Got it.
I just did some tests to see how Chrome deals with 300 or 301 with "alt-svc" header.
It seems the browser does not retry the request with the alternate server.
So it looks "Alt-Svc", at least in its current form, does not meet my requirements.
I just modified my proposal to indicate this fact.
https://docs.google.com/document/d/1gtF6Nq3iPe44515BfsU18dAxfCYOvQaekiezK8FEHu0/edit?usp=sharing
I think another way is to extend the current "Alt-Svc": When combined with a special status code, say, 312,
the client should retry the current request with the suggested alternate server.

What do you think?

Thanks!

Bin

On Sun, Jul 28, 2019 at 1:18 AM Julian Reschke <[email-masked]<mailto:[email-masked]>> wrote:

Best regards, Julian

--

Bin Ni
VP of Engineering

[Quantil]

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

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

This e-mail is classified C2 - Vodacom Restricted - Information to be used inside Vodacom but it may be shared with authorised partners.

"This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this linkhttps://www.vodacom.co.za/vodacom/terms/email-acceptable-user-policy"

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 29 Jul 2019 09:43:29 -0400

On Mon, Jul 29, 2019 at 3:40 AM Oliver, Wesley, Vodacom South Africa

> 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.

> One wants to be able to return the existing response, 200, 304, 404, and
> then tell the client that the next request must go to a different ip
> address.
> This would allow load balancing system described below, to inject load
> balance Repsonse header, instead of having big load balancer in front of
> everything.. The orchestrator just communicates the load balancing
> information to each of the server instances.
>
> Were the have variable content expire headers, according to the load,
> however, one thing they never too into account,
> Is that they will just be phase shift the load to a future time. So when
> that impulse peak load hit them phase shift that into the future, were
> For security reason, I was thinking that similar mechanism would be
> required to force clients by the time of there next Repsonse to re-auth,
> Or the ability to dynamically update signing of jwt and similar tokens
> schemes, provide additional field, to delay the next request by, phase
> shift the request. When security on a system is compromised, then the
> ability to force all clients tokens to be refreshed instantaneously, would
> cause
> A lot of load. All this would need to happen without the client knowing
> there was security issues, and close the window of opertunatity as quickly
> as possible, as people are going to freak out, if you force them to all
> re-login. SO cycling the encryption  and signing of keys very quickly
> would be good, as then required to break them again. Hopefully they not
> uses any pre compute hashing and GPUs to be able to crack things too fast.
>
>
>
> Kind Regards,
>
> Wesley Oliver
>
>
> On 28 Jul 2019, at 10:50, Bin Ni <[email-masked]> wrote:
>
> Got it.
> the client *should* retry the current request with the suggested
> alternate server.
>
> What do you think?
>
> Thanks!
>
> Bin
>
>
>
> This e-mail is classified C2 - Vodacom Restricted - Information to be used
> inside Vodacom but it may be shared with authorised partners.
>
>
>
>
>
>
>
> "This e-mail is sent on the Terms and Conditions that can be accessed by
> Clicking on this link https://webmail.vodacom.co.za/tc/default.html
> <https://www.vodacom.co.za/vodacom/terms/email-acceptable-user-policy> "
>

---

From: Kyle Rose <[email-masked]>
Date: Mon, 29 Jul 2019 10:47:52 -0400

> 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.

---

From: Bin Ni <[email-masked]>
Date: Mon, 29 Jul 2019 12:02:29 -0700

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

-- 

Bin Ni
VP of Engineering

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Jul 2019 19:24:23 +0000

#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 <[email-masked]>
Sent: Monday, July 29, 2019 3:02 PM
To: Kyle Rose <[email-masked]>
Cc: Ben Schwartz <[email-masked]>; Oliver, Wesley, Vodacom South Africa (External) <[email-masked]>; Julian Reschke <[email-masked]>; Ryan Hamilton <[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Jul 29, 2019 at 9:46 AM Ben Schwartz <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Jul 29, 2019 at 3:40 AM Oliver, Wesley, Vodacom South Africa (External) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

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]

[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>

---

From: Wesley Oliver <[email-masked]>
Date: Mon, 29 Jul 2019 21:24:29 +0200

Hi,

What the guys tend to do as well is have specialized dns server entries
geographically, because everyone typically also gets there DNS server handed
to them from the dns server they are consuming. So at peering stations and
internal to ISP, potentially could have different ips, however,
requires a more co-ordinated approach and local buy-in, unless the consumed
DNS server can be configured and made to server different ips base on
knowledge of the geographical
location of the consuming dns server ip.

This is not a silver bullet of obvious reason aswell.

The other previous proposal I wanted to put forth with regards to redirect
was the following, maybe two could be combined.
Below the previous proposal if you didn't see it. It also looks to address
and provide alternative mechanism to avoid using cookies,
for session tracking.

Wesley Oliver <[email-masked]>
Thu, Jun 13, 9:26 AM
to [email-masked]
Hi,

I would just like to highlight the following, which I think we could look
at addressing properly and generically across the board.

With regard to the new proposal stand as of march for authentication
session identification,
my understanding is that is drive from the webbrowser client and the server
just accept id provided. It is no longer driven from the server.

I would pref an approach where by it is drive from both client and server,
which means still ensure
that more difficult for hacking, can't just run tought all possible
permutation of client identification tokens and Bruteforce ones way into
end system.

As one of my previous emails to the group was for an approach from driven
from server-side to client-side, which is not that easy to hack and looking
up of session token, versus encryption and description payload, potentially
could be faster, given url and things have max lengths.

Therefore I would like to propose that we look at implemented generic
response forward headers,
which can be used for the server side to client-driven session management
and also for the very old school redirect problems, using the Location
header for security. With microservice was one's single world to handle all
the PCI credit cards and banking information for accounting purposes. It
because increasingly necessary to do handovers into those worlds, to ensure
a high level of security compliance is hand by a single team and all
auditing is in one place for critical information. Which allows design a
generic journey into such infrustature for anyone.

Below is an example of the problems that live everywhere, which we could
generically address with the propose of this simple json self-description
example benefit this line:

Request->Server
Response<-Server
Payload of Repsonse...
Headers: ForwardRequestHeaders
{
RegRequestPathPattern:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification(Allow Passing/Deny) (should be
explicit enable only)
]
},
RegRequestPathPattern2:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification (Allow Passing/Deny)(should be
explicit enable only)
]
}
}

-------

The insatitial page/api auth redirect, that looks up the subscriptionId and
generates AuthToken,
Then according to the following containing controls will have to perform
the redirect mechanism in the following way.

I would recommend, to avoid being tripped up any browser, react something
not support or being bugged that
We should just support looking for the param in all places, url, query
string, headers, body, form-body submission.
This way we can use the best redirection mechanism possible, that the
client channel supports.

Remember that the url has a limited length, so placing jet tokens, which
can contain a lot more information in the url, can eventually hit the maxim
url length limit.

1. Hand over from different channels to PCI world:

*a. Breakout (Web Browser) (App)*
- Opens Url to instatial page.
- Performs the redirect using url with path, query params. (contents public
visible) url has limited length.
- (Url/Visible) Header:Location URL, can’t specify forward headers, all
must be in the url
- (Url/Visible) HTML meta refresh tag, all in the url
- (Url/Visible) javascript window.location, all must be in the url.
- (Form-Body/Hidden) render a html webpage and then client side generate a
form that is automatically submitted.
- Else render an html webpage and generate a form that is automatically
submitted

- Proxy the request, by acting as pass sought middle man ( but this is not
secure, as opens the door, middle proxy reading the encrypted contents and
fact proxy needs show correct certificate details and spread security now
across many layers, complicating management and much higher risk, not
contained within a single squad, multiple squad have then share security
responsibility.
Therefore, this is not a method that we like to do.

**If the landing page was to redirect again, then the URL/Visible, could be
concealed, because after landing page converted to session state cookie.

*b. WebView( App)*
- Performs the redirect with any one of the methods in a above breakout
(browser)
- (Url+Headers/Hidden)Request from instatitital page/api auth redirect,
which returns the auth information in the Repsonse,
which we then add the information as headers to the web view url open
request, which react supports, to open the page.
** Benefits there are no flashing pages in the redirect  using instatital
pages as for breakout in a above, looks seamless.

*C. ClientBrowser (Online)*
- One of the methods above in a.
- Even if in a frame, the same problems persist.
- The only other approach is to use background request and javascript to
re-write the contents of a html page element place holder, this is a web
app client service side typically type workflow/mechanism approach. ( more
complex)

So I would recommend that if you written a generic landing page that be
able to pulled the specified params from both url path+query string, form
body and headers.

I basically have suggested this for authentication purposes, however, might
as well expanded to to be more generic.
In which can Header:location, can specific request headers under a Repsonse
header called.

ResponseForwardRequestHeaders
{
RegRequestPathPattern:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification
]
},
RegRequestPathPattern2:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification
]
}
}

Kind Regards,

Wesley Oliver

Kind Regards,

Wesley Oliver

-- 
----
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: [email-masked]

---

From: Bin Ni <[email-masked]>
Date: Mon, 29 Jul 2019 22:57:22 -0700

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 <[email-masked]> 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 <[email-masked]>
> *Sent:* Monday, July 29, 2019 3:02 PM
> *To:* Kyle Rose <[email-masked]>
> *Cc:* Ben Schwartz <[email-masked]>; Oliver, Wesley, Vodacom South
> Africa (External) <[email-masked]>; Julian Reschke <
> [email-masked]>; Ryan Hamilton <[email-masked]>;
> [email-masked]
> *Subject:* Re: Redirection to Other IP Addresses
>
>
>
> <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>
>

-- 

Bin Ni
VP of Engineering

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 30 Jul 2019 19:34:04 +1200

On 30/07/19 7:02 am, Bin Ni wrote:
> 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.
> 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.

It is common for good reason: efficiency.

There is a secondary level of efficiency that comes from the redirects
being actual HTTP 30x redirects. Having large objects at different URL
entirely provides for a different CDN or caching layer closer to the
client to provide the large object contents. DNS can be (often is)
involved in that layer to provide the closest server IP.

As proposed so far your mechanism would flatten this two-tier structure.
Forcing the frontend layer (now only layer) to be involved in deciding
the specific hardware location of individual objects / resources.
 Making the frontend machinery store more information and do more work
per-request is not going to make the system faster, quite the opposite.

By separating the work into the three layers: frontend LB, cache, and
origin. Each CDN layer gets some orders of magnitude increase in
performance / capacity:
 - origin able to handle/generate some few thousand responses per second,
 - cache able to re-distribute those as static objects at line speed for
an order or two magnitude more than origins,
 - frontend LB able to handle millions of the small ~1KB
request/response pairs for redirection spreading that high load across
the lower layers.

AYJ

---

From: "Oliver, Wesley, Vodacom South Africa (External)" <[email-masked]>
Date: Tue, 30 Jul 2019 08:02:14 +0000

The alternative to small files, is that they could rather be bundled and rather pushed to the client from a single request,
With a header hint hash of all the individual small requests. Which would reduce the overhead on the wire, but not the overhead in the backend systems, which have to load balance. For static files hash of the file response with life cycle of the file headers included, would work
Well too.

Same as the old issue copying small file problems, OS need like a parallel buffer data write and buffered meta data write the the File allocation table, So speed up writing of small files in batches, as small files kill copy speed. So batch two parts to be be maintained, hopefully would improve performance of the overall copy speed.

> On 30 Jul 2019, at 09:34, Amos Jeffries <[email-masked]> wrote:
>

---

From: Bin Ni <[email-masked]>
Date: Tue, 30 Jul 2019 16:49:28 -0700

Hi Amos and All,

Regarding the 30X redirect across different cache servers, it is already
used by many big CDN companies that I know of.
It is proven to make the system faster without much burden on the front-end
layer which you are concerned.
But 30X has the limitations I mentioned. This is why I'm proposing this new
type of redirection to address the limitations.
https://docs.google.com/document/d/1gtF6Nq3iPe44515BfsU18dAxfCYOvQaekiezK8FEHu0/edit?usp=sharing
So it is not a question that this proposal will be useful or not.
I know it will at least be very useful to those CDNs.

Thanks for your comments.
Please let me know if you have any questions.

Bin

---

From: Chris Lemmons <[email-masked]>
Date: Wed, 31 Jul 2019 15:36:00 -0600

So I have to wonder about the end usefulness from an implementation
perspective. Part of why alt-svc works is that it's optional, so
servers can use them as optimization but everything else still works.

If you have a new protocol that means basically "alt-svc, but
mandatory", it means the CDN, load balancer, or similar service simply
wouldn't work for any client that didn't understand the new value.
There are a _lot_ of http clients out there. This would be a fairly
high barrier to adoption, which would create a chicken-and-egg problem
that would be tough to solve.

On Tue, Jul 30, 2019 at 5:53 PM Bin Ni <[email-masked]> wrote:
>
> Hi Amos and All,
>
> Regarding the 30X redirect across different cache servers, it is already used by many big CDN companies that I know of.
> It is proven to make the system faster without much burden on the front-end layer which you are concerned.
> But 30X has the limitations I mentioned. This is why I'm proposing this new type of redirection to address the limitations.

---

From: Bin Ni <[email-masked]>
Date: Wed, 31 Jul 2019 18:39:21 -0700

Hi Chris,

Great question!
The solution is that the server will only return the new status code 312 if
it is sure the client can support it.
The information can be from the User-Agent header, or some other request
header.
Or communicated through some other channel, for example, on a paper
contract.

Thanks!

Bin

On Wed, Jul 31, 2019 at 2:36 PM Chris Lemmons <[email-masked]> wrote:

> > But 30X has the limitations I mentioned. This is why I'm proposing this
> new type of redirection to address the limitations.
> >

-- 

Bin Ni
VP of Engineering

---

From: Chris Lemmons <[email-masked]>
Date: Wed, 31 Jul 2019 19:48:52 -0600

So, the typical mechanism for that would be an accept header of some sort.
But if clients are opting into the redirect, then the redirect is
effectively optional. Any client that would set the accept header can
instead just support alt-svc today and choose to redirect.

On Wed, Jul 31, 2019 at 7:39 PM Bin Ni <[email-masked]> wrote:

> Hi Chris,
>
> Great question!
> The solution is that the server will only return the new status code 312
> if it is sure the client can support it.
>> > Regarding the 30X redirect across different cache servers, it is
>> already used by many big CDN companies that I know of.

---

From: Bin Ni <[email-masked]>
Date: Wed, 31 Jul 2019 20:51:28 -0700

Hi Chris,

There are a few caveats in your reasoning:
1.  It does not have to be some "accept header". It can be the "User-Agent"
header as I mentioned, for example, chrome version > 100. Or on contract.
For example, some CDN customers have full control of the client software.
They just tell the CDN provider that "you can enable the 312 redirection on
all of our domains".
2. Even when it does rely on some "accept header", there is still a
critical difference from "alt-svc":
    In this proposal, the current request will not be served. The client
will get a 312 and forced to reconnect to the new IP, similar to the 30X
redirection.
    Versus with "alt-svc", the server will serve the content for the
current request, client will finish receiving the response and MAYBE
connect to the new IP for the next request.

Hope this is more clear. Please don't hesitate with more questions!
Thanks!

Bin

On Wed, Jul 31, 2019 at 6:49 PM Chris Lemmons <[email-masked]> wrote:

>>> > But 30X has the limitations I mentioned. This is why I'm proposing
>>> this new type of redirection to address the limitations.
>>> >