Traffic Engineering (fwd)

Fri Sep 19 00:22:16 UTC 1997

> Avi Freedman <freedman at netaxs.com> writes:
> 
> > The cyclic stuff in News recently has hammered home that the search
> > for elegance pays off.  I "initially" solved the problem of having
> > multiple machines with the same IP by postulating IP-stack hackery
> > involving forwarding any packets that come in for sockets that
> > don't exist to a central database-forwarder machine that keeps track
> > of all open tcp sessions on all replicated machines, but it turns
> > out that there are some much easier non-stack-hackery-mandatory
> > solutions.
> 
> Your approach also is not a neat solution for two further
> reasons.  Firstly, it requires maintaining connection
> state for all connections on a central repository, and
> secondly, it requires that your network be stable at the
> point when a connection needs to migrate.

Sorry, I wasn't clear.  The solution described above is
NOT clean, neat, or elegant.  The solution we've come up
with in theory and will be testing shortly (before NANOG)
is clean, neat, and elegant, and relies on things that
things-without-hard-disks can do right now.

> You should be able to deal with the case that during the
> lifetime of a TCP session something causes traffic that
> was hitting site A suddenly arrive at similarly-numbered
> site B at a time when connectivity within your network is
> unstable.  (This likely can be done with tunnels,
> following the NAT approach, if synchronization is between
> things located at the edges of your network, rather than
> in a star pattern from something inside your network).

We can deal with that.

> You should also avoid scaling limits inherent in dumping
> lots of traffic at some central host rather than doing
> content-driven fail-over checkpointing for bulk data
> transfers from "static" content.  

We abandoned that approach as not "clean" enough a while
ago, when I decided to search for a cyclic-level "elegance"
to the solution.

> 	Sean.
> 
> P.S.: do you go about guaranteeing that you have unique
>       connection "names" across all your
>       simliarly-numbered hosts?  

Yes, that's (obviously) part of it...

Avi