Subject: [Reposted to list] Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP

From: Kari Hurtta <[email-masked]>
Date: Sat, 05 Mar 2016 08:32:24 +0000

Willy Tarreau <[email-masked]>: (Sat Mar  5 09:26:53 2016)
<...>
>> So it is not that you have only two options.
> 
> Absolutely, your points should also be noted in the doc, it's
> too bad you didn't post to the list :-)
> 
> Regards,
> Willy

OK. I repost that on list. 

Message should be included (some mail clients may show
it as attachment).

/ Kari Hurtta
 ( not on list )

================================================================

From: Kari Hurtta <[email-masked]>
Subject: Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP
Date: 5 March 2016 at 07:26:27 GMT+1
To: Willy Tarreau <[email-masked]>
Cc: Joe Touch <[email-masked]>, Kari Hurtta <[email-masked]>

( not posted to list )

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0330.html

> What 17-year old wheels ? The only one I know about consists in patching
> kernels to force shorter timewaits in order not to block outgoing
> connections when the rate approaches 1000/s. Until we have 32 bits for
> the source port, these are the only two options. At some point one must
> not wonder why more and more the transport is migrating to userland :-/

Not actually, if talk is about reverse-proxy which sits front
of web server pool.

These two are not ONLY options.

One possiblity: (which certain devices uses)

* Do not "nat" connection from reverse proxy to webserver to 
 proxy's local address. Instead use same source address on that 
 connection than what was on http -request which reverse
 proxy reserved from client.

 In that may there equal number (or bigger number) of available 
 (source address, source port, target address, target port)
 tupples than what was on client which sent request to
 reverse proxy (*).

 Web servers neeed to be default route (for connections
 received to that interface which sits on network between
 reverse proxy and webserver) to poit to reverse proxy.

 Reverse proxy need to able open TCP connection whit
 any source address (not just local address).

 Actually from this there is variations:

 # reuse connection from proxy to web server for several
   http request. On that situation web server does not
   see original source address address of client (but
   instead of some unrelated client -- this have some
   affects to access control)

 # "Nat" source address, but use pool of source addresses
   instead. If you use say 500 different source address,
   then you quite many available (source address, 
   source port, target address, target port), so you can
   handle to 500 * 1000 connections per second from
   reverse proxy to webserver.

You can guess what reverse proxy product uses these
kind solutions.  Perhaps there is also others.

So it is not that you have only two options.

/ Kari Hurtta

(*) You have begger number of source address, source port, target
address, target port)  availabe, when translate target address
to web server's address and you have several web server's
on pool.

( If you not translate target address, but instead route connections
 to correct web server. Then you have same number of tuples
 available.

 In that case web server actually need  listen that address on loopback 
 interface -- otherwise several web server haev same address on
 same network. )

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 7 Mar 2016 07:55:27 +0100

[ I thought you also forwarded my response to the list but it seems
  not, so here it comes again, please keep the list CCed in future
  conversations, that's useful for everyone ]

On Sat, Mar 05, 2016 at 08:26:53AM +0100, Willy Tarreau wrote:
> Hello Kari,
> 
> On Sat, Mar 05, 2016 at 08:26:27AM +0200, Kari Hurtta wrote:
> > 
> > ( not posted to list )
> > 
> Yes but this is limited to very few deployment scenarios, where
> the reverse proxy can be installed in cut-through between all
> the clients and the servers. This type of deployment is very
> rare nowadays because applications look more like a set of
> components which all interact together and which have to pass
> through the LB as well to reach another server on the same LAN,
> possibly coming back to the same machine.
> 
> This is not usable in cloud environments (flat networks), with
> CDNs (remote proxies) nor in all environments where the proxies
> are more application servers than infrastructure components and
> which do not run with root priviledges.
> 
> Yep definitely. Also there's another issue which comes with
> doing this, it's that you have to have as short a TIME_WAIT
> timeout as your shorter client's, otherwise some clients will
> not get the reverse-proxy to forward their connection to the
> server as it will act as sort of a "time-wait amplifier",
> keeping these states longer than the client.
> 
> This is a no-go in most environments, especially when it comes
> to logging or DoS/brute-force protection. Also many proxy to
> server connection cannot safely be shared between incoming
> clients because normally you should only send an idempotent
> request over pre-existing connections if it's the first one
> of this connection, since the proxy is not allowed to replay
> non-idempotent ones and the client will not replay the first
> one on failure. And some protocols do not allow connections
> to be shared. For example, SSL advertises the SNI or presents
> the client's cert during the handshake. That connection sort
> of becomes "private" at this point.
>    
> That's what is done in environments which need more than 64k
> connections per server, but you'll agree that it's an aberration
> to consume a lot of internet addresses that remain unused most
> of the time just to work around a timing issue!
> 
> Oh yes I know quite well what type of proxy supports this, as I
> have implemented this type of transparent proxying into haproxy.
> However I note that while it was an absolute requirement about
> 5 years ago for various deployment situations, nowadays we don't
> see any more demand for this nor situations where it can still
> be deployed since networks are less hierarchical and flatter
> with some DMZ. The *only* remaining case is SMTP/IMAP, and even
> some SMTP servers have implemented haproxy's proxy protocol to
> get rid of the shortcomings of transparent proxying.
>