Re: Redirection to Other IP Addresses

[Bin Ni <[e-mail]>]

Hi Jack,

Actually, 300 was also my first reaction when Julian brought up "alt-svc".
Technically, the main benefit of using a new status code vs reusing an
existing status code is easier statistics.
People can tell what happened by only look at the status code in the access
log.
I think this is the main purpose of defining different status code in the
first place.

Bin


On Thu, Aug 1, 2019 at 12:07 AM Jack Firth <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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 <[e-mail]> 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 <[e-mail]>
>>>>>> 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 <[e-mail]> 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 <
>>>>>>> [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
>>>>>>> >>
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>>
>>
>> --
>>
>> Bin Ni
>> VP of Engineering
>> [image: Quantil]
>>
>> Connecting users with content...it's that simple.
>>
>> Office: [phone] <(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/>
>>
>>

-- 

Bin Ni
VP of Engineering
[image: Quantil]

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

Office: [phone] <(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/>