Re: Redirection to Other IP Addresses

Bin Ni <nibin@quantil.com> Tue, 30 July 2019 23:52 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 768FD12010C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Jul 2019 16:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantil-com.20150623.gappssmtp.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 XkaHquBdjrez for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Jul 2019 16:52:38 -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 96C721200B9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 30 Jul 2019 16:52:38 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hsbsc-0001vQ-5v for ietf-http-wg-dist@listhub.w3.org; Tue, 30 Jul 2019 23:50:06 +0000
Resent-Date: Tue, 30 Jul 2019 23:50:06 +0000
Resent-Message-Id: <E1hsbsc-0001vQ-5v@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 <nibin@quantil.com>) id 1hsbsZ-00015y-O1 for ietf-http-wg@listhub.w3.org; Tue, 30 Jul 2019 23:50:03 +0000
Received: from mail-vs1-xe34.google.com ([2607:f8b0:4864:20::e34]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <nibin@quantil.com>) id 1hsbsW-0003mO-Um for ietf-http-wg@w3.org; Tue, 30 Jul 2019 23:50:03 +0000
Received: by mail-vs1-xe34.google.com with SMTP id h28so44889505vsl.12 for <ietf-http-wg@w3.org>; Tue, 30 Jul 2019 16:49:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantil-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WLO/Oc7VN7sNJtBbS9wI48sNr34wp7CGhTyxdNGDrDc=; b=a10gUGukD3l1++lCeKU6a6nMWNbELufI8dg0hArOvpO7wnTpY2K43h51aD5R9TSpL7 B3/wuPeKAVYOChh3bXBNxIiaTjz4IMTV0LHwlrbQXTbOm3gIFqKGHb57TyaoQd5Z815+ 3pp6rFoqFe3ypUY6zPdN8kFk3RO799vl8AuefajB398eVPxt/ch4ZZf2REWnh0zkEW41 5zoIhBXtz31xv8CWEvScCPcHBPsN0NwYIfJK4AtvrUj97hytPLm6M/9TcKjZJXNJneeG gflKRp7SfqyLRIM7XVWLat5kyCzjn+lP106tV6oa4li7obxVYKddpDjsxRRw0Qwm7f2V cgfQ==
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=WLO/Oc7VN7sNJtBbS9wI48sNr34wp7CGhTyxdNGDrDc=; b=XU6YArzTnji4tqECK/PX/fwnpd+/qVTwoPTLHRCg2j5M5+C0QhyqHu92vTyhauMjnr zlQJTT1KfdJMYHUzSq8Nj4Y07sNScb9lKS1zlHnm/q/JcwDwG1uVTwbasWYoBUodFXBM derQeqyJiJWNBAcWD/CPnQp8vq5xmLsk6m0N9FYY0wLnWd8uMwXhePe+Azo1xFbbHTI3 X8rPjLAyZimo3Pn6rofh21401a3wDErrZmKYO/lZ+sAxhE5Evu94clgYeY8iQavuLJhg M45lLqtUU1I9stVLYd6HavqeY2jlylXAkw5aSTuqDqEs3CXjczEd5zbnH1QssUjWKhEX SLtw==
X-Gm-Message-State: APjAAAU5vFagPLnu6rpEdFfo8Fg4k/tAa2ersXHymionb6w3lmD6kRXE p9ITf/09Ds0fHKDOR82n8IOySgKckePDrbYqexbTHBJmuoXPtw==
X-Google-Smtp-Source: APXvYqx5rcMg7od5yl1BjKG74OCCfuLK4Xj6McNfgiVVVsb8bIGYuy5v9SgPft6EQiDVrzPIL5bWvKRHA0kqxYC0RL8=
X-Received: by 2002:a67:e296:: with SMTP id g22mr54968703vsf.174.1564530579432; Tue, 30 Jul 2019 16:49:39 -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>
In-Reply-To: <f05b5157-f068-1e03-8422-36d0425a32a5@treenet.co.nz>
From: Bin Ni <nibin@quantil.com>
Date: Tue, 30 Jul 2019 16:49:28 -0700
Message-ID: <CAFifEMLQXUSHKOjKN9JR87ht1UUvf-1AEWKNmuKeOqKyzjT28Q@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="0000000000006d8d96058eeea97f"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e34; envelope-from=nibin@quantil.com; helo=mail-vs1-xe34.google.com
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=0.625, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 1hsbsW-0003mO-Um e2738aff8cd4822f62bc8a02cb0fdf64
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/CAFifEMLQXUSHKOjKN9JR87ht1UUvf-1AEWKNmuKeOqKyzjT28Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36880
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>

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