[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is the IP layer the right place to support location information
The issue about routing, as I mentioned in a follow-up email is that the
routing wouldn't be done solely on position, though it might. The idea is
that the routing should include location of source and location of symbolic
destination. I know that everyone will talk about topology and using U.S.
sites vs. those in Europe. I think this are infrastructure problems that
will adjust themselves (as they have in the U.S. with the surplus of
bandwidth).
Ultimately I see the DNS resolver working with the symbolic name, the
location of the request source as well as other information, as a way of
finding which actual host to target.
Chuck Wegrzyn
----- Original Message -----
From: Sharman,Richard <richard.sharman@roke.co.uk>
To: 'C. Wegrzyn' <wegrzyn@garbagedump.com>; Albert Godfrind
<agodfrin@fr.oracle.com>
Cc: Sharman,Richard <richard.sharman@roke.co.uk>;
<ext-ip-location@research.nokia.com>
Sent: Wednesday, January 12, 2000 11:40 AM
Subject: RE: Is the IP layer the right place to support location information
> Albert,Chuck, et al
> Actually there is a bus stop system here in the UK at our nearest
> city(Southampton) which does exactly what you ask: gives the times of the
> next bus regardless of whether you have a mobile, laptop, or whatever.
When
> it's not working it wouldn't be any good logging on to some web site,
since
> that wouldn't know either.
>
> On the subject of routing in the web using positional information I tend
to
> agree with the point of view that you don't want the nearest physical
site,
> or the shortest route, per se, because that doesn't take any account of
> traffic congestion, connection speeds, etc. What you probably want is
> quickest delivery, but then again not necessarily on a packet by packet
> level, because that isn't likely to guarentee quality of service, if
you're
> interested in that.
>
> So that returns us to the question of what the use of physical location
> information really is. It could be for internal Internet communication
> reasons like packet routing and quality of service, but only if combined
> with some more intelligent use of other information. Alternatively, it
> could be for external (user) reasons, such as information location at the
> application level (and I would include the emergency 999 services in that
as
> well). Provided we focus on the class of application, it should be clearer
> what to architect to achieve it.
>
> Richard
>
>
> > -----Original Message-----
> > From: C. Wegrzyn [SMTP:wegrzyn@garbagedump.com]
> > Sent: 12 January 2000 15:41
> > To: Albert Godfrind
> > Cc: EXT Sharman,Richard; ext-ip-location@research.nokia.com
> > Subject: Re: Is the IP layer the right place to support location
> > information
> >
> > Albert,
> >
> > Thanks for your reply. In going back to your bus example, we might not
> > see
> > eye-to-eye on this one. In my thinking if you are walking down a street
> > and
> > want to know what time the bus will appear, it seems that this could be
> > built by a little device in the "bus stop" (or train stop) that
announces
> > the times. I see little value in having my handheld sending a
notification
> > back to some "data center" saying "Here I am, what time does the next
bus
> > appear." In fact in my mind the bus stop is a true "local area" with
> > little
> > benefit beyond it (except when I'm at my office and want to know what
time
> > the bus will arrive at State & Wabash in downtown Chicago and I'm in
> > Boston).
> >
> > As for the whole idea of mirror sites, this was done because there was
no
> > other way to do it (I built out the first "mirror sites" when I started
> > distributing GNU software in the early 80s). I always thought that if a
> > requesting site could identify where it was, the network could decide
the
> > closest route (and maybe the best) to get some data. Right now routing
in
> > the Internet is pretty much a hit-or-miss type of operation. There is no
> > knowledge of location involved (RSVP is meant to do some of this, but
via
> > static routes). Going back to my example of Victoria Secret, what
happens
> > today is that rather than spreading the load over the whole network, it
> > gets
> > funneled down to a specific site. (BTW, look at a company like Akaimi -
> > I'm
> > not sure of the spelling. They are around to overcome this specific lack
> > of
> > positional routing and load balancing).
> >
> > I think there is a real need for all devices, not just mobile ones to
> > identify their location. Once this information is available, then all
> > kinds
> > of interesting things happen both to services being offered to devices
> > (handhelds, PCs, laptops) and the infrastructure.
> >
> > Just my thought,
> > Chuck Wegrzyn
> >
> > ----- Original Message -----
> > From: Albert Godfrind <agodfrin@fr.oracle.com>
> > To: C. Wegrzyn <wegrzyn@garbagedump.com>
> > Cc: EXT Sharman,Richard <richard.sharman@roke.co.uk>;
> > <ext-ip-location@research.nokia.com>
> > Sent: Wednesday, January 12, 2000 10:16 AM
> > Subject: Re: Is the IP layer the right place to support location
> > information
> >
> >
> > "C. Wegrzyn" wrote:
> > >
> > > I tend to disagree with the assessment provided here. In fact there
are
> > very
> > > real needs for position location even with non-mobile devices. I doubt
> > the
> > > example about bus schedules is all that useful - this same thing can
be
> > done
> > > very simply without resorting to anything else: the user can go to a
> > website
> > > and select the location (since it might very well be somewhere else
> > other
> > > than the location of the mobile device doing the request).
> >
> > I see what you mean, Chuck. However, there are several difference
> > between a "mobile" and a "static" device. "going to a website" - the
> > obvious answer for a static device - does not work for a mobile device.
> > The mobile device is used on the street, while walking or just standing
> > at a street corner, sitting in a moving vehicule (hopefully not while
> > driving it ;-), and the questions asked tend to be of immediate use, and
> > concern very local services. Hence the bus example: I want to know the
> > time and destination of the next bus that passes the stop I am standing
> > at - not the time table of buses in the city I will be visiting tomorrow
> > (for which the "website" approach is OK). In addition, mobile devices
> > have limited capabilities in terms or user interface (small screen,
> > small keypad or touchpad) and are used in uncomfortable conditions, so
> > require an underlying infrastructure that is able to filter, select and
> > organize available services to minimize the interaction.
> >
> > But then again, those considerations are not too relevant for the
> > subject at hand, I realize.
> >
> > > The example I think as most useful has to do with hosting content.
> > Right now
> > > if I go to www.microsoft.com, I tend to traverse the entire network
> > until
> > I
> > > end up in Redmond. Now image a situation like Disney or MSNBC or maybe
> > even
> > > the Victoria Secret show - the entire network clogs up with traffic to
a
> > set
> > > of clustered machines. If we have positioning information in the
system,
> > in
> > > other words I am at a machine in Boston, I can construct a DNS
> > environment
> > > that could factor in the location and identify a machine that can
stream
> > the
> > > content to me, one that is closer. Of course this means that MS or
> > Victoria
> > > Secret might have to have multiple machines around the world, and
stream
> > > content (or maintain them in real-time), but the end result is that
the
> > > network load is more evenly distributed.
> >
> > Here again, I have to take exception. The efficiency of the network -
> > the bandwith effectively available between two end-points (the Microsoft
> > site and your own machine) has nothing or very little to do with
> > geographical location and all to do with the topology of the network,
> > specifically the path taken by the packets to travel between the
> > end-points.
> >
> > A case in point: I am based in France. Like everyone, I download stuff
> > from public internet sites. Many sites let you choose a mirror to
> > download from. In almost all occasions, it is faster for me to pick US
> > sites rather that a mirror site that could be thought of as local -
> > geographically closer. This is because the topology of our internal
> > corporate network combined with that of the internet is such that for
> > the most US sites are closer in terms of packet travel time, than
> > geographically closer systems ...
> >
> >
> > > Take it for what it is worth...
> > > Chuck Wegrzyn
> > >
> > > ----- Original Message -----
> > > From: EXT Albert Godfrind <agodfrin@fr.oracle.com>
> > > To: EXT Sharman,Richard <richard.sharman@roke.co.uk>
> > > Cc: <ext-ip-location@research.nokia.com>
> > > Sent: Wednesday, January 12, 2000 3:25 AM
> > > Subject: Re: Is the IP layer the right place to support location
> > information
> > >
> > > Sharman,Richard wrote:
> > >
> > > > Also, I agree that the requirement itself hasn't been totally
> > > articulated.
> > > > The evidence of the archive on this discussion group is ambiguous.
On
> > the
> > > > one hand it would be nice to have a few specific examples of
services
> > with
> > > a
> > > > compelling commercial justification, from which some generic
> > capability
> > > > requirement could be extracted. Of course, if the business case is
too
> > > > compelling it could lead to some short term, proprietary solutions
> > which
> > > > might not be best in the long run. Again, this needs amplification.
> > >
> > > I don't know that there is a definite need for locating devices
> > > generally, but there sure is a business opportunity for providing
> > > location-dependent services to mobile devices. Note however the
specific
> > > environment:
> > >
> > > - this opportunity concerns MOBILE devices, i.e. today generally GSM
> > > phones, preferably WAP-enabled, and soon more complex devices
(palmtops,
> > > etc). That topic is already being covered by the WAP and W3C
consortia.
> > > Note that a joint workshop in february is going to cover those issues
> > > (see http://www.w3.org/Mobile/posdep-workshop).
> > >
> > > - this opportunity concerns the delivery of information or the access
to
> > > services that are dependent on the current position of the mobile
> > > device. For instance, the scheduled time for a bus to pass next at the
> > > nearest bus stop, or the nearest hotel with rooms available in my
price
> > > range, etc.
> > >
> > > Adding a location capture/transport capability into the IP protocol
> > > stack would enable those services on a more general basis. However,
the
> > > vast majority of IP devices today are static - i.e. they do not move:
> > > they sit on a desk somewhere. [Of course, the laptops are "mobile" in
a
> > > way - but not really so when you compare them with a GSM phone. Plus
> > > laptops only connect to the network today when they are stable - i.e.
in
> > > some office or home or hotel room or other well-known fairly static
> > > location.]
> > >
> > > I doubt that the opportunity for providing location-dependent services
> > > or information to static devices exists. After all, you know where you
> > > are. If you need to order something from some web service (say a
book),
> > > you just supply the delivery address yourself manually. Or the
supplier
> > > already knowe your delivery address because he holds it on file ...
Why
> > > would it depend on your physical location ? As for location for
> > > emergency services, I personally would not want to depend on my laptop
> > > or workstation to direct help to me ...
> > >
> > > This is different for mobile devices, where you are out on the street
> > > somewhere, possibly don't know where you are, and are moving (walking,
> > > in a car, on a train, etc).
> > >
> > > The situation may well change in the future if we move in the
direction
> > > of IP being THE ubiquitous transport for EVERYTHING (i.e. each and
every
> > > device has an IP address). Location information at the IP level then
> > > becomes more meaningful - but again under the assumption that devices
> > > are mobile. Even if my fridge has an IP address, I still know where it
> > > is. On the other hand, if my TV remote control does have an IP address
> > > and includes a device that is able to advertise its location, then
that
> > > would help in finding the damn thing under the sofa ;-)
> > >
> > > /albert
> > > --
> > > Albert Godfrind Oracle Data Server Division
> > > Oracle Corporation Multimedia and GeoSpatial Technologies
> > > C.I.C.A Email: agodfrin@fr.oracle.com
> > > 2229 Route des Crêtes Phone: +33/4/92.94.21.37
> > > 06560 Sophia-Antipolis Mobile: +33/6/09.97.27.23
> > > France FAX: +33/4/92.94.21.45
> > > http://www.oracle.com
> >
> > --
> > Albert Godfrind Oracle Data Server Division
> > Oracle Corporation Multimedia and GeoSpatial Technologies
> > C.I.C.A Email: agodfrin@fr.oracle.com
> > 2229 Route des Crêtes Phone: +33/4/92.94.21.37
> > 06560 Sophia-Antipolis Mobile: +33/6/09.97.27.23
> > France FAX: +33/4/92.94.21.45
> > http://www.oracle.com
>