Using NAT for best-exit routing

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. :slight_smile:

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. :wink:

Yeah, performance would be a BIG factor in a large content network.

   ,-------- provider "G" -------.
  / \
  > >
  > >
   \ /
    `------- 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.