[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is the IP layer the right place to support location information
In my mind, the location information is something that isn't broadcast
continually but is something that can be queried when needed. Where does it
exist in the IP/TCP stack? I would make the suggestion that it is at the
ICMP layer. This would allow it to be queried rather cheaply by some host
whether it was a router, a DNS lookup routine, or whatever.
I don't think I would suggest broadcast floods! Boy that would be one load
on the network. This should be a query on demand. If you think about a
router, or any other device could easily hold a Location Cache similar to or
in conjunction with the arp cache.
FWIW,
Chuck Wegrzyn
----- Original Message -----
From: Ron Lake <rlake@galdosinc.com>
To: EXT Albert Godfrind <agodfrin@fr.oracle.com>;
<ext-ip-location@research.nokia.com>
Sent: Wednesday, January 12, 2000 11:15 AM
Subject: Re: Is the IP layer the right place to support location information
> Hi,
>
> There is no question that broad availability of spatial information on the
> Internet (including both mobile and stationary devices) is important.
This
> includes location of course, but also information about extent and a host
of other
> spatial relationships. We have proposed encoding standard for such
information
> based on XML called GML. You can find a description of GML at
> https://feature.opengis.org/rfc11/GMLRFCV1_0.html. Note that a single
global
> specification of even a simple idea like location is not possible since it
is
> truly application specific. A notion of location suited to one application
is not
> suited to another. None of this information in my view belongs anywhere
but in
> the application layer. Of course there will be cases where application
information
> might be used to control the network - but that does not mean that the
information
> itself should be encoded in lower network layers.
>
> Ron Lake
>
> rlake@galdosinc.com
>
> EXT Albert Godfrind wrote:
>
> > "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
>