Re: Redirection to Other IP Addresses

Chris Lemmons <alficles@gmail.com> Wed, 31 July 2019 21:38 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 549861200C7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Jul 2019 14:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.201, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham 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 sNPFYSf0gDoC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Jul 2019 14:38:44 -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 070B412004D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 31 Jul 2019 14:38:43 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hswH0-0004gN-Dl for ietf-http-wg-dist@listhub.w3.org; Wed, 31 Jul 2019 21:36:38 +0000
Resent-Date: Wed, 31 Jul 2019 21:36:38 +0000
Resent-Message-Id: <E1hswH0-0004gN-Dl@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <alficles@gmail.com>) id 1hswGx-0004fW-NK for ietf-http-wg@listhub.w3.org; Wed, 31 Jul 2019 21:36:35 +0000
Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <alficles@gmail.com>) id 1hswGv-00009W-Td for ietf-http-wg@w3.org; Wed, 31 Jul 2019 21:36:35 +0000
Received: by mail-wm1-x331.google.com with SMTP id v19so61187219wmj.5 for <ietf-http-wg@w3.org>; Wed, 31 Jul 2019 14:36:13 -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=+WjOLOmSBA5SiFwIt9d1EYrI5nAcdozBlVuZ3adhrHY=; b=oTtY9fTvx8VIl4+nZ8mUywenrOwJ70yX1XMfnaBfs0WN0p5V6+NW0cNIzXXJCW9zHG 6tif3TD6RbwzHcLNiPFuRIOxZBhCA0Ve9soKx3hehUWv+IbWMCILi56a8GHBf+0B0Zxl gVIK+4bLw/Q3VsRH2KXmUn++Nrrpkto3xDVjS1U0Q9HKiinas5Z7/Wg3wwuXU+kKcBHv BF+URjrm4dyMc3K0/HMDo/zOZGbGcCYQR9eTxOQeT+D7LFQ0rZ6O7U8hMPsQnVPAggWW b7hF4x9KfWl9uRLwqH26vdYr+CusmpeqaSWMYzFJrFAIHAXuRdMEQxpZ0GMfOXSi7j2a qGIA==
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=+WjOLOmSBA5SiFwIt9d1EYrI5nAcdozBlVuZ3adhrHY=; b=F8/7EvnUEleiOGD0rj0BUU50wpyWskGfZMtK08jGPeZehnjdsJ+rAoZOps+tFJWwCf 403R70i16iOw/nsJWAHH1g5xrzL/0UiT8PZU/CpXhKJYb10MGaIOUXzz2a694MRI/YyE /PAe0T0JZyAC4tQq38v566qWSdw8X+p4UTQ3JQ+/Bzmz6fE0ZJANYQAzufr+X8/fGoXf 37b6dbBY5zUEWMuLPwDgooRiuUQJAY615AKAgp94+aIQO6ooaYBkezn8T+kNntctLoV3 MQWu0mPROo+wsam84t8gOEsMmPZdcutBv9zopUMOWaTRfL9zxJs3bfvniMIJV5oH2EBu VDcA==
X-Gm-Message-State: APjAAAVPBcOF/FERxiq/ic1BZ9DtUikjYjRMcrAVB+ZhjW5Le4sOFKYp dDCU8G9RcWxE354UoEB77/qztGikv17QfITSyG0ZzUS8
X-Google-Smtp-Source: APXvYqw69wclhveYafXWdV/SpHaRUSFlYRSdq5EYcekjNIuJ5/b9PA/5Rn/jfXntmRd5y1MTajLDKzHZSED/zXd/NCE=
X-Received: by 2002:a1c:7d08:: with SMTP id y8mr95347170wmc.50.1564608972148; Wed, 31 Jul 2019 14:36:12 -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>
In-Reply-To: <CAFifEMLQXUSHKOjKN9JR87ht1UUvf-1AEWKNmuKeOqKyzjT28Q@mail.gmail.com>
From: Chris Lemmons <alficles@gmail.com>
Date: Wed, 31 Jul 2019 15:36:00 -0600
Message-ID: <CAJEGKNtWvXyrFLU0KW-rqN1qd-PLOqobjx1o6kRcH27_O9Ri7Q@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: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2a00:1450:4864:20::331; envelope-from=alficles@gmail.com; helo=mail-wm1-x331.google.com
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=0.758, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hswGv-00009W-Td 7c72441a1861882281e894dfd5ef661f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/CAJEGKNtWvXyrFLU0KW-rqN1qd-PLOqobjx1o6kRcH27_O9Ri7Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36892
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 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
>>
>