Re: Redirection to Other IP Addresses

"Oliver, Wesley, Vodacom South Africa (External)" <Wesley.Oliver@vcontractor.co.za> Tue, 30 July 2019 08:05 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 515571200EF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Jul 2019 01:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 9KZEF0-85rcz for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Jul 2019 01:05:09 -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 171A012011A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 30 Jul 2019 01:05:09 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hsN5t-0004z4-Fz for ietf-http-wg-dist@listhub.w3.org; Tue, 30 Jul 2019 08:02:49 +0000
Resent-Date: Tue, 30 Jul 2019 08:02:49 +0000
Resent-Message-Id: <E1hsN5t-0004z4-Fz@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 <Wesley.Oliver@vcontractor.co.za>) id 1hsN5p-0004yH-TX for ietf-http-wg@listhub.w3.org; Tue, 30 Jul 2019 08:02:45 +0000
Received: from vbmtbmm003.vodacombusiness.co.za ([41.0.3.6]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <Wesley.Oliver@vcontractor.co.za>) id 1hsN5n-00018H-BL for ietf-http-wg@w3.org; Tue, 30 Jul 2019 08:02:45 +0000
Received: from ZAEXMBXPP02.vodacom.net (Not Verified[10.132.88.150]) by vbmtbmm003.vodacombusiness.co.za with Trustwave SEG (v7, 3, 6, 7949) id <B5d3ff9890002>; Tue, 30 Jul 2019 10:02:17 +0200
Received: from ZAEXMBXFO02.vodacom.net (10.132.32.199) by ZAEXMBXPP02.vodacom.net (10.132.32.203) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Jul 2019 10:02:15 +0200
Received: from ZAEXMBXTC02.vodacom.net (10.132.32.202) by ZAEXMBXFO02.vodacom.net (10.132.32.199) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Jul 2019 10:02:15 +0200
Received: from ZAEXMBXTC02.vodacom.net ([fe80::802c:a284:2b10:ea9]) by ZAEXMBXTC02.vodacom.net ([fe80::802c:a284:2b10:ea9%20]) with mapi id 15.00.1473.005; Tue, 30 Jul 2019 10:02:15 +0200
From: "Oliver, Wesley, Vodacom South Africa (External)" <Wesley.Oliver@vcontractor.co.za>
To: Amos Jeffries <squid3@treenet.co.nz>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Thread-Topic: Redirection to Other IP Addresses
Thread-Index: AQHVQ4+F05kZVEbiIUelZ1rANpSBJabceSqAgAJjo4CAACHtAIAAgMgAgAAGnoCAAAtIAIAACNuAgAF9zwCAAGZ9gIAAEf0AgABHI4CAANH+AIAAB94A
Date: Tue, 30 Jul 2019 08:02:14 +0000
Message-ID: <3123A3AB-7649-45BE-ACCA-DC1B633AECED@vcontractor.co.za>
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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FC0D0422937ABF42A7910A1410AF36A4@vodacom.co.za>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Received-SPF: permerror client-ip=41.0.3.6; envelope-from=Wesley.Oliver@vcontractor.co.za; helo=vbmtbmm003.vodacombusiness.co.za
X-W3C-Hub-Spam-Status: No, score=-2.0
X-W3C-Hub-Spam-Report: AWL=0.099, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, W3C_NW=0.5
X-W3C-Scan-Sig: titan.w3.org 1hsN5n-00018H-BL db3cf702f7647462b055b44002836354
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/3123A3AB-7649-45BE-ACCA-DC1B633AECED@vcontractor.co.za>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36875
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>

The alternative to small files, is that they could rather be bundled and rather pushed to the client from a single request,
With a header hint hash of all the individual small requests. Which would reduce the overhead on the wire, but not the overhead in the backend systems, which have to load balance. For static files hash of the file response with life cycle of the file headers included, would work
Well too.

Same as the old issue copying small file problems, OS need like a parallel buffer data write and buffered meta data write the the File allocation table, So speed up writing of small files in batches, as small files kill copy speed. So batch two parts to be be maintained, hopefully would improve performance of the overall copy speed.

> On 30 Jul 2019, at 09:34, 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
>

This e-mail is classified C2 - Vodacom Restricted - Information to be used inside Vodacom but it may be shared with authorised partners.
"This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this linkhttps://www.vodacom.co.za/vodacom/terms/email-acceptable-user-policy"