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

Willy Tarreau <w@1wt.eu>: (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 <hurtta-ietf@elmme-mailer.org>
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 <w@1wt.eu>
Cc: Joe Touch <touch@isi.edu>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>


( 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. )