Re: Using NAT for best-exit routing

[owen () DeLong SJ CA US (Owen DeLong)]

> 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. :-)
Depends on your definition of scalable.  Please show me a NAT box that
can keep up with 1.5Gbps sustained with peaks in excess of 1.9.

> 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.
An interesting idea, but the address management alone becomes a nightmare.
Then, when you add the sheer number of customers some of the content
providers have, it becomes even more complex.  It would be really cool
if such a system could be made to work without turning address management
into an unmitigated nightmare for the content provider, but I don't see
that as being too likely.

> 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. ;-)
Yeah, performance would be a BIG factor in a large content network.

> 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).
Could be interesting, but I don't think it scales.

Owen