[Date Index]
[Thread Index]

[Date Prev] bullet [Date Next] bullet [Thread Prev] bullet [Thread Next]
bullet
Re: Routing Question-- Maybe a hack
bullet bullet bullet bullet

Yea, I agree but I would say that practically, the http queries are so short lived that the edge case probably doesn't matter that much. The only thing that might happen in the case is that during a routing chane and doing the querie, the flow fails and when the client "clicks" again, it should work.

Jack

At 10:24 AM 12/13/95 -0500, John W. Stewart III wrote:
>
>i brought up dns as a way of describing a service that would
>most definitely work well using jack's proposal. the is as
>opposed to http which might not work so well...
>
>the point is that this host route approach may work ok for
>connectionless, single-packet-request, single-packet-response
>services like dns queries. however, the approach might not
>work so well for connection-oriented multi-packet services
>like http. if routing changes in some way, then one of the
>http servers could enter into a tcp connection "in the middle
>of a conversation" and the client would be messed up...
>
>/jws
>
> > Sorry to be dense about this. We don't have to do anything
> > to DNS (e.g., BIND)? DNS does the right thing because routes are pointing
> > you to the right place? I can live with the right answer for hosts
> > directly on the railroad ... we can worry about the other sites
> > later.
> >
> > Carl
> >
> > According to John W. Stewart III:
> > >
> > >
> > > the addressing issues are key here
> > >
> > > this idea is a slight modification to an idea we've had for
> > > sharing the load of dns queries. in that case, however, the
> > > address of the name servers is within an aggregate that we
> > > announce .. so the whole internet comes to us, and then we
> > > use the host route within our backbone to optimize routing.
> > > if you've got servers off of your backbone, then it gets
> > > harder .. and you probably don't want to inject /32s into
> > > the global routing mesh
> > >
> > > a difference between dns and http is that dns is a single-
> > > query, connectionless service while http is longer-lived and
> > > connection-oriented. the life of an http connection *is*
> > > relatively short, but since it's more than one packet, in an
> > > event where a server goes down, clients will not see a
> > > graceful transition
> > >
> > > /jws
> > >
> > > > Wow! Let me see if I get this. What happens when a Japanese user
> > > > types http://www.park.org/ is:
> > > >
> > > > 1) www.park.org resolves to 5.6.7.8
> > > > 2) the packet goes to the railroad
> > > > 3) the "best" route to 5.6.7.8 in this case
> > > > is right back into the Japanese infrastructure
> > > >
> > > > If a user in Australia does the same thing, they get pointed to the
> > > > edge of the railroad (Mae-East in this case) and the "best route"
> > > > to 5.6.7.8 in this case is town.hall.org.
> > > >
> > > > I think this works for hosts directly on the railroad. What if
> > > > we have a central park server already in Australia, but not on
> > > > the railroad? How does that work?
> > > >
> > > > Carl
> > > >
> > > > According to Jack Waters:
> > > > >
> > > > > Carl
> > > > >
> > > > > I thought about this a bit last night and wanted to throw out a possi
>ble
> > > > > solution. The real goal I think you have is to make web client use th
>e
> > > > > closest web server.
> > > > >
> > > > > Here's my proposal:
> > > > >
> > > > > On each worlds fair server, let's say two for now (call it
> > > > > www.worldsfair.org for now):
> > > > >
> > > > > Create two interfaces for
> > > > >
> > > > > 1) Machine1
> > > > > le0 --> 1.2.3.4 (the real address of the machine)
> > > > > vif0 --> 5.6.7.8 (the pseudo address of www.worldsfair.org)
> > > > > 2) Machine2
> > > > > le0 --> 9.0.1.2 (the real address of the machine)
> > > > > vif0 --> 5.6.7.8 (the pseudo address of www.worldsfair.org)
> > > > >
> > > > > In the DNS www.worldsfair.org would only map to 5.6.7.8
> > > > >
> > > > > Then in the railroad infrastructure, import the host route 5.6.7.8 in
>to th
> > > e
> > > > > IGP (presumably OSPF or ISIS) pointing to both machine1[2].
> > > > >
> > > > > With this, when a client resolves www.worldsfair.org, it will go to 5
>.6.7.
> > > 8
> > > > > which will be routed, once inside the railroad, to the *closest* 5.6.
>7.8 a
> > > nd
> > > > > get to the closest (IGP-wise) web server.
> > > > >
>> > > The trick will be to make the host route dynamic enough to remove its
> > > > > announcement for one of the machines[1 || 2] when that machine (or mo
>re
> > > > > specifically httpd) is not available. This should be pretty easy to d
>o if
> > > > > you use gated on machine1[2]. A quick hack to remove the route from g
>ated
> > > > > could be implemented to "watch" httpd and remove the announcement. Of
> > > > > course, gated will automatically remove the announcement if the machi
>ne
> > > > > becomes diconnected or dies.
> > > > >
> > > > > This, I think, should accomplish what you are trying to do. Let me kn
>ow wh
> > > at
> > > > > you think.
> > > > >
> > > > > Thanks
> > > > > Jack
> > > > >
> > > > >
> > > > >
> > > > > Note the second interface is a
> > > > >
> > > > > At 11:13 AM 12/12/95 -0500, Carl Malamud [IMS] wrote:
> > > > > >> if you're talking about multiple servers in different
> > > > > >> locations with clients routing to them based on proximity
> > > > > >> that's very different. perhaps possible.
> > > > > >
> > > > > >You bet, that is what we want to do. Different answers for
> > > > > >different locations. I'll call Kim Claffy and see what she
> > > > > >has to contribute.
> > > > > >
> > > > > >How hard is it to manually define some border AS's (e.g., the
> > > > > >ones at the "edge" of Japan) and then ask the question: is this
> > > > > >IP address "beyond" the border AS's? From a host, what would
> > > > > >I do to ask that question?
> > > > > >
> > > > > >Carl
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

Follow-Ups: bullet
[Date Prev] bullet [Date Next] bullet [Thread Prev] bullet [Thread Next]
bullet