Re: Redirection to Other IP Addresses

Chris Lemmons <alficles@gmail.com> Thu, 01 August 2019 01:51 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF58D120131 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Jul 2019 18:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.798
X-Spam-Level:
X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_VISITOURSITE=2, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEpHrQBU4qUE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Jul 2019 18:51:18 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE761200B9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 31 Jul 2019 18:51:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ht0Di-00086m-Pl for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Aug 2019 01:49:30 +0000
Resent-Date: Thu, 01 Aug 2019 01:49:30 +0000
Resent-Message-Id: <E1ht0Di-00086m-Pl@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <alficles@gmail.com>) id 1ht0Dg-000860-B2 for ietf-http-wg@listhub.w3.org; Thu, 01 Aug 2019 01:49:28 +0000
Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <alficles@gmail.com>) id 1ht0Dd-0001gE-RD for ietf-http-wg@w3.org; Thu, 01 Aug 2019 01:49:28 +0000
Received: by mail-wr1-x42a.google.com with SMTP id g17so71723672wrr.5 for <ietf-http-wg@w3.org>; Wed, 31 Jul 2019 18:49:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0CfqN/5CCmYfi0ugTVWfhfq4iDUMvhG1O/g72PnKA1M=; b=cpIZufa6pHzI8kQJ1T5EqRTleN1ln6ReuX2SRspAIGyJDLCke5VaqCJCKyhhFKgJGt QiPuUwMyPPZqpY5gMP8rNXzXhKNtOr2Vbh9obUxoQH5m/zBoUgMjQDt/uv0zNApd93GV mVcm/0CUxA59YwAJqlmZ/SzucEYrtQBmRWqXNfz6njTdlV79N4yykHweZyBfmhEUrPSQ dnaqf+YbGUjyo5g0zXzyH94ZFIcxgLSThZSdJlLsIoSNr8OTwxZWJsIeXlD7sjz7QADq e6L94qYVqL7EHnr5sDh2Buw4MWVHOzZ6fwWFBpUoHRY4cUUDgRgNX7UGzl22GmoUAh8T 9uVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0CfqN/5CCmYfi0ugTVWfhfq4iDUMvhG1O/g72PnKA1M=; b=XpdWD6rZ4C0qQj+tiiMhZCXTGaIie7baXWx9H0+zTRKbnVB2vwcIP9tyZwlXOj/m+s BngGzhJZSZHQ75tjxaEWC/90TMYgtEy4AW5lgBTZ2REnLX4XiD0pqZU64NrSAP9M5gcN FQjKYlaF5ZWhlB8TmMUU9matvqXxLpiBbi8g3P0LVebc6LGUyWXRQUo3WtO853+mDvXi L6Eh2E+QA/XbJeR1ubt6YHL+F8yXrauvmMM4AiLizRkklEUZOmvMdd8VQT3bIS/5kBZf V+xyEyaSHBhmEpgsxAfgvwQHaL+T1mZxqZNRthDIGiLZW1I9vrtaEscEEacLFa0MFbdE moDg==
X-Gm-Message-State: APjAAAXcxg1vZU1j4X+0oSE2icEux+slp1O8Vhekpuk1YvzQdj6WZRro mKIMkVGvJK3+LiNmGWGIrYx9ln6pjaZFLAGvYd5jwg==
X-Google-Smtp-Source: APXvYqyyZZhFe5CW9IpRcrAfGNqm1mDmNxJs9+naHdPzo40pgKRe8lU4Fttoa1vFmFTsDBPpax2oKJmdmC3hZyztXm4=
X-Received: by 2002:a5d:56cb:: with SMTP id m11mr14551132wrw.255.1564624142544; Wed, 31 Jul 2019 18:49:02 -0700 (PDT)
MIME-Version: 1.0
References: <CAFifEMLOHp5=OqUXZbg_WKNQmNsTW3Bg5P4btJdX06CF=Wi2AA@mail.gmail.com> <d9b03ef6-9c8c-1eb2-7f74-014f9703475d@gmx.de> <CAJ_4DfQifbJJ7owfrgUUOqXimL-KQkb4-1f_Qp6+CMjhYC1bbg@mail.gmail.com> <CAFifEMJPZd9CGghi_MJ1Hrcq7TJNnkV6yH-EKtrrfaQmStS4Ug@mail.gmail.com> <b09ab672-f512-52bc-6c28-7df55919a846@gmx.de> <CAFifEM+TXtsxTt-NcH+hQomEAYZmMTW_kPxXvQB69eM4KgGf7g@mail.gmail.com> <d4d25ceb-09b5-72ff-6c36-7fdfc2796b15@gmx.de> <CAFifEMKff11nmJZgE1RGWT8qH6SKsO2tqWCF9vQsvF5=BMeQgg@mail.gmail.com> <45C10C32-DA87-4AE3-9082-DAAFD5D9C412@vcontractor.co.za> <CAHbrMsAE1ZezM5U_b2s3juc4OC0LJDOpyHfek7Pu2AaQcXpf8A@mail.gmail.com> <CAJU8_nWP63pT08X4QkUmk6KT_U98LjiFvNaTNg5ZtVMG3AFiFg@mail.gmail.com> <CAFifEMLnSB5SYb_q0toTE3Xy1i56=14ki=__91Phc76HHL+ZhQ@mail.gmail.com> <f05b5157-f068-1e03-8422-36d0425a32a5@treenet.co.nz> <CAFifEMLQXUSHKOjKN9JR87ht1UUvf-1AEWKNmuKeOqKyzjT28Q@mail.gmail.com> <CAJEGKNtWvXyrFLU0KW-rqN1qd-PLOqobjx1o6kRcH27_O9Ri7Q@mail.gmail.com> <CAFifEMKhjU=EmMj6yyVN5D1aSfCVi9HAWgE-Ebzu8NscKQpv_w@mail.gmail.com>
In-Reply-To: <CAFifEMKhjU=EmMj6yyVN5D1aSfCVi9HAWgE-Ebzu8NscKQpv_w@mail.gmail.com>
From: Chris Lemmons <alficles@gmail.com>
Date: Wed, 31 Jul 2019 19:48:52 -0600
Message-ID: <CAJEGKNvoKijzJsTOSE0w08wst=zxoTa95Jx8xVfRWmCWJTJ=4g@mail.gmail.com>
To: Bin Ni <nibin@quantil.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000393354058f0472ce"
Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=alficles@gmail.com; helo=mail-wr1-x42a.google.com
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=0.752, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1ht0Dd-0001gE-RD fb31bb89234bcf2ea7af21df0d401cc1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/CAJEGKNvoKijzJsTOSE0w08wst=zxoTa95Jx8xVfRWmCWJTJ=4g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36899
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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