Using NAT for best-exit routing

Fri Aug 28 18:10:27 UTC 1998

We've been doing a version of this for about a year now on a special
case basis.  It works well enough, but can lead to some painful behaviours
as one attempts to scale.  Paralleling NAT routers can help quite
a bit.

--Lloyd

Lloyd Taylor  --  taylorl at digex.net
Vice President, Technical Operations
DIGEX Web Site Management Group
An Intermedia Company

On Thu, 27 Aug 1998, Brian Dickson wrote:

> The following is a suggestion for a scalable solution to the best-exit
> problem (hot-potato requests to a web farm, best-exit data return).
> (This was prompted by thinking about the original problem which induced
> the most-popular topic of late.)
> As far as I know it's original, so if you use it, let me know how it
> works, and maybe give me some credit. :-)
> 
> The idea is basically this: the web farm provider uses a NAT device
> (or configures NAT on a router) for every peering point with a given peer
> who wants best-exit. Separate address pools (in private address space)
> are used for each such NAT (and distinct such pool sets amongst multiple
> such peer networks). Ingress traffic to the web farm provider has it's
> *source* address NAT'd, and internal routing points return traffic to
> the *same* NAT through which the request traffic came.
> Thus, return (data) traffic is best-exit.
> 
> This scales as the number of flows, not as the number of addresses announced,
> so the MEDs scaling issue goes away. Performance may be an important factor,
> so it is advised that anyone trying this test it in a lab first. ;-)
> 
> Pictorially
>    ,-------- provider "G" -------.
>   /                               \
>   |                                |
>  NAT1                            NAT2
>   |                                |
>    \                              /
>     `------- web farm "E" -------'
> 
> Traffic flows:
> West coast, G -> NAT 1 (closest)-> web farm -> NAT1 -> west coast, G (best exit)
> East coast, G -> NAT 2 (closest)-> web farm -> NAT2 -> east coast, G (best exit)
> 
> (Also works for NATs 3,4,5,...)
> 
> If the NAT can handle #flows seen, at wire speed, all is well. Limits would be
> the total number of simultaneous flows, and max speed of NAT.
> 
> Side benefits are that the unique address pools allow for much easier
> per-peer and per-region collection of stats, eg netflow (at some place
> other than NATs).
> 
> Comments?
> -- 
> Brian Dickson,                                    Email: briand at teleglobe.net
> Teleglobe USA, Inc.,                              Tel  : +1 703 821 4818
> Suite 400, 8251 Greensboro Drive,                 Fax  : +1 703 821 4885
> McLean, Virginia, USA, 22102                      http://www.teleglobe.com
> 