Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Traffic Engineering

  • From: Curtis Villamizar
  • Date: Tue Dec 16 15:35:39 1997

Another flash from the past...

In message <9709201517.ZM5712@renard.watching.org>, "James R Grinter" writes:
> 
> freedman@netaxs.com (Avi Freedman) writes:
> > smd@clock.org (Sean Doran) writes:
> > > P.S.: Curtis Villamizar had another interesting approach
> > >       which involved pushing content far afield to
> > >       machines with the same transport-layer (IP)
> > >       addresses, relying upon closest-exit routing to
> > >       connect one to the topologically-closest replication
> > >       machine.  Unfortunately, while this could be really
> 
> This is a problem I've been musing over lately.  The best way that I
> can see is to return suitable DNS answers to people.  This avoids the
> route instability problems that Sean comments on, above:
> 
>  Client gets TCP session established.
> 
>  Routes change, their inbound route now reaches a different system
>  which clearly doesn't know about the connection and *boom* goes
>  the TCP session.
> 
>  Routes return to their previous situation but by this time it's too late.
> 
> (Even worse is when the client connects *during* the route instability.)


Maybe this is unique to Europe?  We put the prefix inside an
aggregate.  If routes to our /13 and /14 aggregates outside of our
network are sloshing around that much that different provider
interconnects are used mid TCP connection (often enough that it
matters) there is clearly a serious problem in the adjacent provider
and I can't see how they can stay in business (here in the US anyway).

If this does occur some time in the middle of the few second long
transfer (10s of seconds for a large slow transfer) then the client
gets a RST and has to click again.  If this is persistent, then
someone in the path has a very serious problem.

The only real problem you can run into is if someone is boneheaded
enough to misconfigure their routing to do per prefix load splitting
across WAN links or worse yet across providers.  Again, such people
don't deserve to stay in business (since *all* TCP traffic from their
network will suck), but they do exist.  The common newbie mistake is
to configure per prefix load split among two default routes.  Westnet
used to do this many years ago.  Some small network in Florida did
this more recently.

Curtis




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.