Re: Redirection to Other IP Addresses

"Oliver, Wesley, Vodacom South Africa (External)" <> Mon, 29 July 2019 07:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EC50120033 for <>; Mon, 29 Jul 2019 00:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.651
X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_VISITOURSITE=2, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dP4QVtCoDpO8 for <>; Mon, 29 Jul 2019 00:39:32 -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 ABC5C120018 for <>; Mon, 29 Jul 2019 00:39:32 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hs0Df-0003RL-Mx for; Mon, 29 Jul 2019 07:37:19 +0000
Resent-Date: Mon, 29 Jul 2019 07:37:19 +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 1hs0Dc-0003Qa-Fx for; Mon, 29 Jul 2019 07:37:16 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hs0DY-0001yS-Nb for; Mon, 29 Jul 2019 07:37:15 +0000
Received: from (Not Verified[]) by with Trustwave SEG (v7, 3, 6, 7949) id <B5d3ea24e0002>; Mon, 29 Jul 2019 09:37:51 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jul 2019 09:36:40 +0200
Received: from ([fe80::802c:a284:2b10:ea9]) by ([fe80::802c:a284:2b10:ea9%20]) with mapi id 15.00.1473.005; Mon, 29 Jul 2019 09:36:41 +0200
From: "Oliver, Wesley, Vodacom South Africa (External)" <>
To: Bin Ni <>
CC: Julian Reschke <>, Ryan Hamilton <>, "" <>
Thread-Topic: Redirection to Other IP Addresses
Date: Mon, 29 Jul 2019 07:36:40 +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: multipart/alternative; boundary="_000_45C10C32DA874AE39082DAAFD5D9C412vcontractorcoza_"
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.061, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=0.01, W3C_NW=0.5
X-W3C-Scan-Sig: 1hs0DY-0001yS-Nb 1205b4cf0842d53c8d78054a908f6115
Subject: Re: Redirection to Other IP Addresses
Archived-At: <>
X-Mailing-List: <> archive/latest/36857
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


I would like to suggest, that this not be a specific response code, like a
312 or 302. That it just be a response header, that gets checked by
Inteligent clients, would then always check for the new address and port on which to contact the server,
port may be a problem, because of port blocking.

One wants to be able to return the existing response, 200, 304, 404, and then tell the client that the next request must go to a different ip address.
This would allow load balancing system described below, to inject load balance Repsonse header, instead of having big load balancer in front of everything.. The orchestrator just communicates the load balancing information to each of the server instances.

The reason that it should just be that there is no round trip delay and that we can integrate
The load balancing orchestrator, building the histogram that takes the cache response headers into account,
Future re-hit load time into account, to ensure that you only phase shift the load and not fully spread the load.

I will find a document I was writing after I BBC gave a presentation at dev ops day in Cape Town, South Africa,
Were the have variable content expire headers, according to the load, however, one thing they never too into account,
Is that they will just be phase shift the load to a future time. So when that impulse peak load hit them phase shift that into the future, were
The same clients will hit them in the same density again and peak impulse.

For security reason, I was thinking that similar mechanism would be required to force clients by the time of there next Repsonse to re-auth,
Or the ability to dynamically update signing of jwt and similar tokens schemes, provide additional field, to delay the next request by, phase shift the request. When security on a system is compromised, then the ability to force all clients tokens to be refreshed instantaneously, would cause
A lot of load. All this would need to happen without the client knowing there was security issues, and close the window of opertunatity as quickly as possible, as people are going to freak out, if you force them to all re-login. SO cycling the encryption  and signing of keys very quickly would be good, as then required to break them again. Hopefully they not uses any pre compute hashing and GPUs to be able to crack things too fast.

Kind Regards,

Wesley Oliver

On 28 Jul 2019, at 10:50, Bin Ni <<>> wrote:

Got it.
I just did some tests to see how Chrome deals with 300 or 301 with "alt-svc" header.
It seems the browser does not retry the request with the alternate server.
So it looks "Alt-Svc", at least in its current form, does not meet my requirements.
I just modified my proposal to indicate this fact.
I think another way is to extend the current "Alt-Svc": When combined with a special status code, say, 312,
the client should retry the current request with the suggested alternate server.

What do you think?



On Sun, Jul 28, 2019 at 1:18 AM Julian Reschke <<>> wrote:
On 28.07.2019 09:38, Bin Ni wrote:
> Hi Julian,
> So maybe the server can returns a 301 with no "location" header but a
> "alt-svc" header to
> force the client to go to that alternative service?

Again, alt-svc is just advisory.

> ...
Best regards, Julian


Bin Ni
VP of Engineering

Connecting users with's that simple.

Office: +1-888-847-9851<tel:(888)%20847-9851>

[Tweeter]<>  [Google Plus] <>   [Linked In] <>

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<,+Campbell,+CA+95008&entry=gmail&source=g>p;source=g>, or visit our website at<>

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"