Subject: [Ecrit] LoST returning location used??

From: Shida Schubert <[email-masked]>
Date: Tue, 08 May 2007 23:51:53 -0700

I might have overlooked something completely but while I was
reviewing the framework document the following question came up.

 The framework document expects some sort of flagging on
the location to indicate which location was used to do location
based routing (LoST & non-LoST) when there are multiple
location information in the message.

 According to the LoST-05, the client can insert multiple
location information but which location was used for the actual
resolution is not returned to the client. One may guess or sometime
clearly find out which location was used, simply analyzing the
"ServiceBoundary" but according to the debate going on right
now it doesn't seem so simple after all.

 If the client can't tell which location was actually used for routing,
how would the client, let's say a proxy using the "used-for-routing"
parameter indicate which location was actually used for routing the
call.

 The framework also expects the entity on the signaling path
acting as a LoST client to use the same location information flagged
with "used-for-routing", would it restrict the LoST client to include
only the flagged location information for LoST query once it's
flagged using "used-for-routing"??

 Regards
  Shida

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 11 May 2007 10:55:22 -0400

I can't follow this email.

If the UA (foolishly in my opinion) puts more than one location in an
INVITE, and does not do the routing, then the proxy is going to pick one,
and which one it picks will, indeed, not be known to the UA.  

Actually, if there is an error, the "loop back" mechanism we are discussing
for -conveyance would return the location that was found to be in error, and
it might be marked "used for routing".

I fail to see a problem.  If the UA wishes to not be confused, it should not
put more than one location on the INVITE.

Now, the UA may put a location in the INVITE, and then the network may put
another on.  The UA may not know that one.  I don't see a problem with that
either, and the loopback is designed to make sure that the entity putting
the location on knows which one the error is referring to.

Brian

> -----Original Message-----
> From: Shida Schubert [mailto:[email-masked]]
> Sent: Wednesday, May 09, 2007 2:52 AM
> To: ECRIT
> Cc: Henning Schulzrinne; Brian Rosen; James M. Polk
> Subject: LoST returning location used??
> 
>

---

From: Shida Schubert <[email-masked]>
Date: Fri, 11 May 2007 09:17:03 -0700

Hi Brian;

 Let me try to paraphrase my concern.

 Let's assume that UA obtains 3 locations, 1 from GPS, 1 from DHCP
and 1 from L7-LCP.

 According to the current LoST spec, LoST client can set as many location
information as it wants as long as it is of different profile. If the 
location UA
obtains are all of different profiles it can include all 3 of them.

 What I thought the spec said was that  LoST doesn't return, which 
location it
used to resolve the URI that it includes in the response. I thought that 
one can
only guess from the data under the <ServiceBoundary>. But as I looked at 
the
LoST-05, I realized that <ServiceBoundary> provides profile and with that
UA can match the profile in the request and that of a <ServiceBoundary> and
figure out the location used for LoST resolution. So problem wasn't as 
bad as I
initially believed. But it is still somewhat concerning when 
<ServiceBoundaryReference>
is returned. AFAIK <ServiceBoundaryReference> doesn't include the profile
which imposes LoST client to look up the <ServiceBoundaryReference> to 
figure
out which location in LoST request was used to resolve the PSAP URI.

 Anyhow why I had the initial concern was due to UA not knowing which 
location
needs to be appended with  'message-routed-on-this-uri" parameter if 
profile is not
indicated. As I found out re-reviewing the LoST spec, it's not a problem 
when
ServiceBoundary is returned by-value but can be problematic when returned
by-reference.
 
 I hope I managed to clarify my concern.

 Regards
  Shida

---

From: Andrew Newton <[email-masked]>
Date: Fri, 11 May 2007 13:34:46 -0400

Shida,

We can add the profile identifier to the <serviceBoundaryReference>.   
That's a good catch.

However, your scenario can gateway into another use case.  There is  
nothing that says that GPS, DHCP, and L7-LCP cannot deliver location  
information of the same type of profile, in this case geodetic-2d.   
If the seeker knows they are all of the same profile type, it should  
query on each set of location information separately.  In the case  
where the seeker doesn't know the location profile, the profile id  
returned in <serviceBounary> or <serviceBoundaryReference> will not  
help it out too much.  Perhaps we ought to have a client-assigned id  
as well, so the client can tell which location was used in this case.

-andy

On May 11, 2007, at 12:17 PM, Shida Schubert wrote:

> information as it wants as long as it is of different profile. If  
> the location UA
> used to resolve the URI that it includes in the response. I thought  
> that one can
> only guess from the data under the <ServiceBoundary>. But as I  
> looked at the
> figure out the location used for LoST resolution. So problem wasn't  
> as bad as I
> which imposes LoST client to look up the <ServiceBoundaryReference>  
> to figure
> Anyhow why I had the initial concern was due to UA not knowing  
> which location
> needs to be appended with  'message-routed-on-this-uri" parameter  
> if profile is not
> indicated. As I found out re-reviewing the LoST spec, it's not a  
> problem when

---

From: Shida Schubert <[email-masked]>
Date: Mon, 14 May 2007 14:31:32 -0700

Andy,

 For the use-cases you provided, I thought client would be able to match
each LoST query/response even when 3 requests are sent simultaneously
(Doesn't HTTP provide a way to identify the request to response?) so I 
didn't
think client will have an issue of not being able to match the location 
used
in request and that of response. Although some may question which location/
mapping is to be used when all 3 requests return response with PSAP URIs
almost simultaneously(Probably depends on the local policy, location 
preference
etc.).

 I may be missing something but seeker not understanding the location 
profile
doesn't seem to be an issue in itself. As long as client(seeker) can 
match the location
used in request to location used in response. But again looking at RFC 4119,
RFC3825 and seeing the fact that they seem to not carry the profile 
information,
the question comes to my mind as to how seeker sets the profile to the 
<location>
in LoST request. If that's what you are implying, I share your concern. 
As I did a quick
scan on the 2 RFCs mentioned above, I did not see the profile to be 
provided,
which seems mandatory to set in the LoST in case LoST server is handling 
multiple
locations in single LoST query.

 Regards
  Shida

Andrew Newton wrote:
> information of the same type of profile, in this case geodetic-2d.  If 
> the seeker knows they are all of the same profile type, it should 
>> only guess from the data under the <ServiceBoundary>. But as I looked 
>> at the

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 14 May 2007 17:29:20 -0500

Hi, Shida,

From: "Shida Schubert" <[email-masked]>

> (Doesn't HTTP provide a way to identify the request to response?) so I

Two choices in HTTP/1.1, persistent TCP connections (SHOULD) and 
"per-object" TCP connections (original mechanism).

For persistent TCP connections - responses must be returned in the order 
that requests are received. Pipelining is allowed, but if you send three 
requests off, you get the response to the first request, then the second, 
then the third.

For "per-object" TCP connections - ("Connection: close") - the server gets a 
request, sends the response, and closes the TCP connection. This gives you 
ghastly performance for small transfers (because you do SYN/SYN-ACK/ACK 
before each object, and FIN/FIN-ACK in each direction after each object.

There's also no way for the client to control which strategy a server uses.

Details in RFC 2616, Section 8.1 ("connections"), especially 8.1.

Spencer

> doesn't seem to be an issue in itself. As long as client(seeker) can match 
> the location
> in LoST request. If that's what you are implying, I share your concern. As 
> I did a quick

---

From: Shida Schubert <[email-masked]>
Date: Mon, 14 May 2007 21:20:40 -0700

Hi Spencer;

 Thanks for the little tutorial..

 Seeing what you have noted below, it looks like LoST client
will always be able to match the request to response, and thus if
3 requests all containing location with same profile (e.g "geodetic-2d")
are sent and only one of the request is returned with the response with
a resolution(PSAP URI etc.), the LoST client will be able to match
which request received a response, and thus able to mark the proper
location information with "message-routed-on-this-uri" parameter.

 What's unclear to me and concerning to me is
  1. Profile doesn't seem to be provided in the LCP that client uses
      to obtain information (Like I said before, I might have overlooked
      something..), if so how would the UA declare which information is
      based on profile X in LoST request?

  2. What to do if  requests sent are returned with different
      Boundary and PSAP URIs? I think we may want to set some guidelines
      for this in phone-bcp as I understand everything that is related to
      location-conveyance + emergency is going into phone-bcp.

 Regards
  Shida

Spencer Dawkins wrote:
> For persistent TCP connections - responses must be returned in the 
> order that requests are received. Pipelining is allowed, but if you 
> send three requests off, you get the response to the first request, 
> then the second, then the third.
>
> For "per-object" TCP connections - ("Connection: close") - the server 
> gets a request, sends the response, and closes the TCP connection. 
> This gives you ghastly performance for small transfers (because you do 
> SYN/SYN-ACK/ACK before each object, and FIN/FIN-ACK in each direction 
> after each object.
>
>> think client will have an issue of not being able to match the 
>> location used
>> the question comes to my mind as to how seeker sets the profile to 
>> the <location>
>> in LoST request. If that's what you are implying, I share your 
>> concern. As I did a quick
>> which seems mandatory to set in the LoST in case LoST server is 
>> handling multiple

---

From: Andrew Newton <[email-masked]>
Date: Tue, 15 May 2007 09:49:03 -0400

Shida, Spencer,

My comments are in-line...

> location information with "message-routed-on-this-uri" parameter.

That is correct.  Requests sent in different HTTP requests can be  
easily matched to their corresponding HTTP responses.  However, the  
LoST schema allows each XML instance to contain multiple sets of  
location information.  And if the client does not understand location  
profiles, it may not understand which location information is being  
used.  That is why I suggested a client-assigned request-scope unique  
identifier for each set of location information found in a particular  
LoST XML instance.

>      based on profile X in LoST request?

You are correct.  I suggested one method to handle this.  But we seem  
to have competing ideas: either seekers know about the type of  
location information they are using, or they don't.  But it seems we  
have a situation now where we want it both ways.

>      location-conveyance + emergency is going into phone-bcp.

Yes, that's the issue with using multiple HTTP requests for multiple  
location information sets that essentially point to the same place.

-andy