Re: Redirection to Other IP Addresses

[Bin Ni <[e-mail]>]

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

On Tue, Jul 30, 2019 at 12:38 AM Amos Jeffries <[e-mail]> wrote:

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