Re: Redirection to Other IP Addresses

Yes you could make a status code, but I don't follow why you need a new
status code instead of reusing a generic 300 response with body explaining
they need to follow Alt-Svc. A special status code requires clients to
implement new behavior, and if they're doing that already can't they just
implement Alt-Svc support instead? As for 4xx, it sounds like a client
error to me in the same way that 429 Too Many Requests is: the client asked
for something correctly, but did so in a way that places too great a burden
on the server.

On Thu, Aug 1, 2019 at 12:03 AM Bin Ni <nibin@quantil.com> wrote:

> Hi Jack,
>
> Potentially, we can extend RFC 7838, as I mentioned in my proposal
> <https://docs.google.com/document/d/1gtF6Nq3iPe44515BfsU18dAxfCYOvQaekiezK8FEHu0/edit#heading=h.e8fyx0s8f7wy>,
> to define the behavior of client and server when "alt-svc" is used in
> conjunction with a special status code. This is still a change/extension to
> the existing protocol. I feel 4xx is not good for this purpose, since this
> is not a client error. I think a 3XX is more appropriate.
>
> Thanks!
>
> Bin
>
> On Wed, Jul 31, 2019 at 10:52 PM Jack Firth <jackhfirth@gmail.com> wrote:
>
>> 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.
>>
>>
>> Could you return a 4xx error with the Alt-Svc header set, and a body
>> message that tells clients they must use the Alt-Svc if they don't want to
>> get a 4xx? Or even a generic 300? It seems reasonable to me for a CDN
>> server to refuse to serve requests it knows will be prohibitively
>> expensive, while providing clients with Alt-Svc as a way to find a
>> less-expensive alternative.
>>
>> On Wed, Jul 31, 2019 at 8:55 PM Bin Ni <nibin@quantil.com> wrote:
>>
>>> 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 <alficles@gmail.com>
>>> wrote:
>>>
>>>> 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 <nibin@quantil.com> 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.
>>>>> 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 <alficles@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> 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 <nibin@quantil.com> 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.
>>>>>> >
>>>>>> 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 <
>>>>>> squid3@treenet.co.nz> 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
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>
>>>>>
>
> --
>
> 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/>
>
>