Subject: [Ecrit] servicelistboundary - discussion in the meeting today

From: Karl Heinz Wolf <[email-masked]>
Date: Wed, 29 Jul 2009 14:01:05 +0200

There was some discussion during the meeting today on my draft
http://tools.ietf.org/html/draft-wolf-ecrit-lost-servicelistboundary-01

My main concern is how to ensure that a client never misses a change
in available services and consequently learns all location dependent
dialstrings for the current location in order to be able to detect an
emergency call based on the dialstring.
Currently the listServiceByLocation response does not give any
information on the area the service list is valid for. So a client
might miss a change in the available services, so it won't have the
dialstring configured and is not able to detect an emergency call.
The problem arises in countries not having a single emergency
dialstring, like 911, but having different dialstrings for different
services and dialstrings as well as services depend on location. When
travelling around, the availability of services may change, as well as
the dialstrings. So there needs to be some kind of rule on when to
update the service list. Since the service boundary tells when to do a
findService again, I thought it would be consistent to introduce
another boundary to tell the client when to update the service list
(as proposed in the draft).

Since I was just listening remotely to the discussion, I'd like to ask
if I understood Ted's idea correctly: instead of a boundary indicating
the area, the service list is valid for, the LoST Server should also
return services that are NOT available at the current location.
This would mean: when a client does a findService for
urn:service:sos.ambulance for its current location, it would also get
back a mapping for urn:service:sos.physician for a different location?
So when moving to this other area, the client already knows which
services and dialstrings are available there.
I'm afraid this approach would just solve the problem in case the LoST
Server would dump more or less it's complete database to the client.
If the LoST Server would just send a couple of mappings, and others
not, the client could still be lost.
Besides, traffic and complexity for the client would increase. The
servicelistboundary wouldn't increase complexity too much for a client
already evaluating the service boundary, since all the necessary
functionality should be already in place. On the server side, the
complexity should also be manageable (the servicelistboundary could be
pre-calculated for the area the server has data for).

Please let me know if I missed something in the discussion.

karl heinz

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 29 Jul 2009 07:10:34 -0500

My conclusion from the discussion was that Ted had some concerns relating to the combinatorial complexity implied by what is proposed.  I also got the impression that the document could still be accepted, but that issue would need to be resolved.

It appears that Ted's alternative solution doesn't work very well, as you say.

Maybe I can propose that the chairs ask for a) consensus on the problem, b) adoption of the draft.  We probably should have done that in the meeting.

Maybe Ted will disagree, but I'm sure that we'll be hearing any objections if that's the case.

--Martin
 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Karl Heinz Wolf
> Sent: Wednesday, 29 July 2009 2:01 PM
> To: ECRIT
> Subject: [Ecrit] servicelistboundary - discussion in the meeting today
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Jul 2009 14:18:10 +0200

I agree with Karl Heinz's analysis.  Contrasting the two options:

service-list-boundary:
-- Server has to compute all of the serviceListBoundaries that it can 
serve.  The computational complexity of this operation is O(2^#services) 
(one polygon per combination of services on/off), which isn't huge as 
long as #services is reasonably small (and should be significantly lower 
than that in many cases).
-- Client has to make <findService> queries only for services that are 
actually available to it
-- Client is aware of when it needs to update its service list.

Ted's proposal:
-- Client has to make <findService> queries for all services that are 
served by the LoST server, regardless of whether the service is 
available or not.
-- Client is unaware of when it needs to update its service list (since 
<findService> queries for unavailable services will fail)
-- Server has to handle more transactions per client, many of which will 
fail.

IMO, service-list-boundary seems like the more straightforward solution.

--Richard

---

From: Karl Heinz Wolf <[email-masked]>
Date: Wed, 29 Jul 2009 14:19:06 +0200

> My conclusion from the discussion was that Ted had some concerns relating to the combinatorial complexity implied by what is proposed.  I also got the impression that the document could still be ac…

regarding the complexity of the resulting boundary information, I
tried to explain that in section 3.4.1 of the draft.

   The calculation of the largest possible area for which the service
   list stays the same might be a complex task.  An alternative would be
   to return smaller areas that are easier to compute.  In such a case
   some unneeded queries to the LoST server are the consequence, but
   still the main purpose of the serviceListBoundary is achieved: Never
   miss a change of available services.  So a reasonable trade-off
   between the effort to generate the boundary information and the saved
   queries to the LoST server has to be considered.

does this make sense?

> Maybe I can propose that the chairs ask for a) consensus on the problem, b) adoption of the draft.  We probably should have done that in the meeting.

I think a) was already asked on the mailinglist:

http://www.ietf.org/mail-archive/web/ecrit/current/msg06246.html

karl heinz

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 29 Jul 2009 07:25:14 -0500

Of course, if the server is unable to do the full computation, it does not need to report the complete area necessary.  

It's O(n) rather than O(2^n) isn't it?  For each service that the target can use currently, and given the extents of the service (found by forming the union of all service areas - an op that can be performed beforehand), the extents of the service list boundary are found by finding the intersection of all the areas.  During this stage, the boundary for a particular service can be shrunk if that makes it easier.

> From: Karl Heinz Wolf [mailto:[email-masked]]
> Sent: Wednesday, 29 July 2009 2:19 PM
> To: Thomson, Martin
> Cc: ECRIT
> Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting
> today
> 
> > My conclusion from the discussion was that Ted had some concerns
> relating to the combinatorial complexity implied by what is proposed.
>  I also got the impression that the document could still be accepted,
> but that issue would need to be resolved.
> >
> 
> > Maybe I can propose that the chairs ask for a) consensus on the
> problem, b) adoption of the draft.  We probably should have done that
> in the meeting.
> >
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 29 Jul 2009 14:27:31 +0200

>emergency call based on the dialstring.

I think this is where the draft is a bit unclear.  Let's start from
what RFC 5222 says:

  A LoST client can ask a LoST server for the list of services it knows
   about for a particular area.  The <listServicesByLocation> query
   contains one or more <location> elements, each from a different
   location profile (Section 12), and may contain the <service> element.
   As for <findService>, the server selects the first location element
   that has a profile the server understands and it can operate either
   recursively or iteratively; <via> elements track the progress of the
   request.  The query indicates the services that the server can
   enumerate from within the forest structure of which it is a part.
   Because LoST does not presume a single, overarching organization of
   all potential service types, there may be services available within a
   geographic area that could be described by other LoST servers
   connected to other forest structures.  As an example, the emergency
   services forest for a region may be distinct from the forests that
   locate commercial services within the same region.

   If the query contains the <service> element, the LoST server returns
   only immediate child services of the queried service that are
   available for the provided location.  If the <service> element is
   absent, the LoST service returns all top-level services available for
   the provided location that it knows about.

The current mechanism only works within a single forest structure.
This draft is not clear, at least to me, in being scoped to a single
forest structure, and the discussion in the room wandered around
that topic (partly by referring to the services for which the responding
servers are authoritative). 

>dialstring configured and is not able to detect an emergency call.

But there are many more available services than emergency services.
These will also change.  Are we clear that this only captures changes
to those within a service hierarchy?

>(as proposed in the draft).

In the past, we discussed this in terms of time, rather than movement;
this was because the list could also change because of additions (again,
not so much for emergency servies, but potentially for other services)

>back a mapping for urn:service:sos.physician for a different location?

No; it sounds like something got lost here.  I was first proposing that
this should be limited in applicability, essentially to a single forest or
service type.  Then I was suggesting that a server able to traverse that
forest respond with a list of relevant services but without location
boundary information for those not available in the area relevant
to the query.  That is, you do a query using findServicebyLocation for
urn:service:geg and get back urn:service:geg.orthozog with a boundary,
and urn:service:geg.mumblefratz. with no boundary.  That avoids
dumping the database (and the current server having to collect the
information about where geg.mumblefratz is available); it simply
lets the client know that there are other services out there which
are explicitly not available at the target site of the first query.

If the client wants to use geg.mumblefratz, it needs to re-query.
It can requery at some specified time scale, or it can requery on
only when it wants to use geg.mumblefratz.

I was somewhat surprised, honestly, to see Henning arguing
for this, since he has argued against this idea in the past.  This
makes me suspect I am missing some subtle difference,
and I would not be surprised to find that this is so.  I would
like, however, if we did not concentrate on the emergency
services use case to the exclusion of other use cases; that
tends to skew the design in ways that will limit LoST's usefulness
in other realms.
			regards,
				Ted Hardie

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 29 Jul 2009 07:29:31 -0500

I should really read my email before I send it.  That first sentence makes no sense to me.  Ignore it.

Maybe the text could describe, in general terms the algorithm used to generate these things - and thereby head off any such concerns.

Oh, and I always thought that we had consensus to work on the problem.  Add the milestone and adopt the draft.

--Martin

> Of Thomson, Martin
> Sent: Wednesday, 29 July 2009 2:25 PM
> To: Karl Heinz Wolf
> Cc: ECRIT
> Of course, if the server is unable to do the full computation, it does
> not need to report the complete area necessary.
> 
> It's O(n) rather than O(2^n) isn't it?  For each service that the
> target can use currently, and given the extents of the service (found
> by forming the union of all service areas - an op that can be performed
> beforehand), the extents of the service list boundary are found by
> finding the intersection of all the areas.  During this stage, the
> boundary for a particular service can be shrunk if that makes it
> easier.
> 
> 
> > > It appears that Ted's alternative solution doesn't work very well,
> as
> > you say.
> > >
> > >> travelling around, the availability of services may change, as
> well
> > as
> > >> update the service list. Since the service boundary tells when to
> do
> > a
> > >> complexity should also be manageable (the servicelistboundary
> could
> > be
> > > -------------------------------------------------------------------
> --
> > ---------------------------
> > > -------------------------------------------------------------------
> --
> > ---------------------------
> > > [mf2]
> > >
>

---

From: Karl Heinz Wolf <[email-masked]>
Date: Wed, 29 Jul 2009 15:20:54 +0200

Ted,

thank you for your clarification.

You might be correct, I probably focused too much on emergency
services. But there it hurts the most: if you're unaware of the
service, you don't have the dialstring and you definitely cannot
detect the emergency call to this service.

> servers are authoritative).
right, the draft does not explicitly say this at the moment.
Thank you for pointing this out, it helps me understanding the
discussion better.
> to those within a service hierarchy?

but you don't need to know the dialstring for pizza in advance: if you
press the pizza button on your device, it can simply do the service
discovery.

> not so much for emergency servies, but potentially for other services)

I wasn't talking about changes in time - sorry if didn't express that
clearly. Besides, the changes in time would be addressed by the
expires attribute.

> only when it wants to use geg.mumblefratz.

hm, as I understand it, the client has still the same problem: when
does the service become available? The only information the client
gets is that this service is available "somewhere". I'm not sure this
is helpful?
Moreover, considering the emergency service case, you have to know the
dialstring right before the call. I know I'm concentrating on
emergency services...

> tends to skew the design in ways that will limit LoST's usefulness

I'm afraid we need some kind of rule on when to update the service
list when travelling. And this is crucial for figuring out the
dialstings as long as there is not a single emergency dialstring all
over the world.
I'm not sure if the servicelistboundary makes much sense for other
services, since as you pointed out, they may just get discovered on
demand without any problems.
However, also the service boundary is optional in LoST, also the
servicelistboundary could just be optional and only be returned in
case the server knows it or it's about emergency services.

karl heinz

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Jul 2009 09:33:21 -0400

Perhaps the service URN has some sub urns, like
urn:service:servicelistboundary.sos

> Sent: Wednesday, July 29, 2009 9:21 AM
> To: Ted Hardie
> Cc: ECRIT

---

From: Karl Heinz Wolf <[email-masked]>
Date: Wed, 29 Jul 2009 15:44:43 +0200

> urn:service:servicelistboundary.sos

Brian, are you talking of sub-services, like proposed in
http://tools.ietf.org/html/draft-robins-ecrit-sub-services-00 ?

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Jul 2009 09:54:41 -0400

Well, I was thinking of either explicitly defining a subservice, much as we
have defined sos and sos.police OR perhaps defining the urn so that any
token(s) after servicelistboundary be treated as a filter for which services
were composed into the servicelistboundary, with the default being all of
the services the LoST server handles.

Brian

> Of Brian Rosen
> Sent: Wednesday, July 29, 2009 9:33 AM
> To: 'Karl Heinz Wolf'; 'Ted Hardie'
> Cc: 'ECRIT'
> > >>http://tools.ietf.org/html/draft-wolf-ecrit-lost-
> servicelistboundary-
> > 01
> > >>
> > >   all potential service types, there may be services available
> within
> > a

---

From: Robins George <[email-masked]>
Date: Thu, 30 Jul 2009 08:57:34 +0200

> have defined sos and sos.police
This looks more reasonable to me though there may have reasons to define 
the URN.

> OR perhaps defining the urn so that any
>>> From: [email-masked] [mailto:[email-masked]] On
>>>        
>> Behalf
>>      
>>> Of Karl Heinz Wolf
>>> On Wed, Jul 29, 2009 at 2:27 PM, Ted Hardie<[email-masked]>
>>>        
>> wrote:
>>      
>>>>> My main concern is how to ensure that a client never misses a
>>>>>            
>> change
>>      
>>>>> in available services and consequently learns all location
>>>>>            
>> dependent
>>      
>>>>> dialstrings for the current location in order to be able to detect
>>>>>            
>> an
>>      
>>>>   A LoST client can ask a LoST server for the list of services it
>>>>          
>>> knows
>>>        
>>>>    about for a particular area.  The<listServicesByLocation>  query
>>>>    contains one or more<location>  elements, each from a different
>>>>    location profile (Section 12), and may contain the<service>
>>>>          
>>> element.
>>>        
>>>>    As for<findService>, the server selects the first location
>>>>          
>> element
>>      
>>>>    that has a profile the server understands and it can operate
>>>>          
>> either
>>      
>>>>    recursively or iteratively;<via>  elements track the progress of
>>>>          
>>> the
>>>        
>>>>    Because LoST does not presume a single, overarching organization
>>>>          
>> of
>>      
>>>>    connected to other forest structures.  As an example, the
>>>>          
>> emergency
>>      
>>>>    services forest for a region may be distinct from the forests
>>>>          
>> that
>>      
>>>>    If the query contains the<service>  element, the LoST server
>>>>          
>>> returns
>>>        
>>>>    available for the provided location.  If the<service>  element is
>>>>    absent, the LoST service returns all top-level services available
>>>>          
>>> for
>>>        
>>>> This draft is not clear, at least to me, in being scoped to a
>>>>          
>> single
>>      
>>>> that topic (partly by referring to the services for which the
>>>>          
>>> responding
>>>        
>>>> These will also change.  Are we clear that this only captures
>>>>          
>> changes
>>      
>>> but you don't need to know the dialstring for pizza in advance: if
>>>        
>> you
>>      
>>>>> dialstring, like 911, but having different dialstrings for
>>>>>            
>> different
>>      
>>>>> services and dialstrings as well as services depend on location.
>>>>>            
>> When
>>      
>>>>> travelling around, the availability of services may change, as well
>>>>>            
>>> as
>>>        
>>>> In the past, we discussed this in terms of time, rather than
>>>>          
>>> movement;
>>>        
>>>> this was because the list could also change because of additions
>>>>          
>>> (again,
>>>        
>>>> not so much for emergency servies, but potentially for other
>>>>          
>>> services)
>>>        
>>>>          
>>>>> Since I was just listening remotely to the discussion, I'd like to
>>>>>            
>>> ask
>>>        
>>>>> if I understood Ted's idea correctly: instead of a boundary
>>>>>            
>>> indicating
>>>        
>>>>> the area, the service list is valid for, the LoST Server should
>>>>>            
>> also
>>      
>>>>> urn:service:sos.ambulance for its current location, it would also
>>>>>            
>> get
>>      
>>>>> back a mapping for urn:service:sos.physician for a different
>>>>>            
>>> location?
>>>        
>>>> No; it sounds like something got lost here.  I was first proposing
>>>>          
>>> that
>>>        
>>>> this should be limited in applicability, essentially to a single
>>>>          
>>> forest or
>>>        
>>>> service type.  Then I was suggesting that a server able to traverse
>>>>          
>>> that
>>>        
>>>> forest respond with a list of relevant services but without
>>>>          
>> location
>>      
>>>> to the query.  That is, you do a query using findServicebyLocation
>>>>          
>>> for
>>>        
>>>> urn:service:geg and get back urn:service:geg.orthozog with a
>>>>          
>>> boundary,
>>>        
>>> Moreover, considering the emergency service case, you have to know
>>>        
>> the
>>      
>>>>> I'm afraid this approach would just solve the problem in case the
>>>>>            
>>> LoST
>>>        
>>>>> Server would dump more or less it's complete database to the
>>>>>            
>> client.
>>      
>>>>> servicelistboundary wouldn't increase complexity too much for a
>>>>>            
>>> client
>>>        
>>>>> complexity should also be manageable (the servicelistboundary could
>>>>>            
>>> be
>>>