Re: Redirection to Other IP Addresses

"Oliver, Wesley, Vodacom South Africa (External)" <> Tue, 30 July 2019 08:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 515571200EF for <>; Tue, 30 Jul 2019 01:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9KZEF0-85rcz for <>; Tue, 30 Jul 2019 01:05:09 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 171A012011A for <>; Tue, 30 Jul 2019 01:05:09 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hsN5t-0004z4-Fz for; Tue, 30 Jul 2019 08:02:49 +0000
Resent-Date: Tue, 30 Jul 2019 08:02:49 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4c]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hsN5p-0004yH-TX for; Tue, 30 Jul 2019 08:02:45 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hsN5n-00018H-BL for; Tue, 30 Jul 2019 08:02:45 +0000
Received: from (Not Verified[]) by with Trustwave SEG (v7, 3, 6, 7949) id <B5d3ff9890002>; Tue, 30 Jul 2019 10:02:17 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Jul 2019 10:02:15 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Jul 2019 10:02:15 +0200
Received: from ([fe80::802c:a284:2b10:ea9]) by ([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)" <>
To: Amos Jeffries <>
CC: "" <>
Thread-Topic: Redirection to Other IP Addresses
Date: Tue, 30 Jul 2019 08:02:14 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Received-SPF: permerror client-ip=;;
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: 1hsN5n-00018H-BL db3cf702f7647462b055b44002836354
Subject: Re: Redirection to Other IP Addresses
Archived-At: <>
X-Mailing-List: <> archive/latest/36875
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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 <> 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.

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