Subject: [Ecrit] FW: LoST synchronous query and referals

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 31 Aug 2006 14:21:50 -0400

And I made the same mistake twice before Andy corrected me.

-----Original Message-----
From: Rosen, Brian 
Sent: Thursday, August 31, 2006 2:13 PM
To: GEOPRIV
Subject: LoST synchronous query and referals

I think we all imagine the LoST server to be a synchronous
query/response: from a single port open to the server, you send a query
and wait for the response before sending another query.

Give a little thought to system architecture, where we are expecting all
devices to query LoST periodically (with periodicity in perhaps tens of
hours to days), or when they move out of the region/boundary supplied.
That makes the query load on the server fairly high, but not really too
bad.  Certainly, a synchronous response is still appropriate, with
possibly the server permitting many simultaneous ports open.  We do
expect to see many non-authoritative copies of the authoritative data to
spread load.

Now, suppose there was a bulk querier.  Could be a LIS periodically
revalidating locations for example, but suppose it was the E-CSCF in a
3GPP environment.  I chose that because response time there matters, and
it may very well have more than one outstanding call at a time.

Now, recall that there may be a referral mechanism: you ask a question,
and the local server may not have the answer, but may refer to another
server for resolution.  We don't have details on that.

If the query is actually forwarded by the original server, and the
response comes back through that server, then we do have a problem? A
query could take a long time to complete.  Is that a problem worth
worrying about?  How do we address it?  I'm not asking for an
asynchronous query.  I think that is the wrong direction.  It may be
that the referral is NOT a forward, but a redirect.  That would make the
server not have to wait to respond.

I think a high volume querier could have multiple persistent TCP
connections maintained (if the protocol is TCP based) and choose an
available one as the way to handle the routine cases.  If the server
multithreads, that combination may even work for a long duration query.

Brian

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 31 Aug 2006 17:29:58 -0400

The difference between the response time for a loaded (but not 
collapsing) and unloaded server is likely to be no more than 1:10, at 
most. This is based on some extrapolation from SIP server measurements 
we have done; in most systems, response time follows the classical 
hockey stick trajectory, with an extremely rapid rise to infinity when 
the load starts to exceed 80 or 90% of capacity. (The knee of the curve 
  and the slopes depend on the variability of the arrival and service 
process; details are in any book on queueing theory.)

In other words, the chance that waiting a long time will help is small. 
The server is either operating in the 80%-or-below load and you'll get 
an answer almost immediately or it is just as likely in the collapsing 
phase where any amount of waiting isn't going to help much. For these 
systems, it is much better to limit the queue size to a small number 
(say, 10), as that prevents congestion collapse. Increasing the queue 
size will not significantly improve the throughput.

Example: For the classical M/M/1 system, a load of 0.9 produces a queue 
length of 10, so making the queue larger will only yield, at most, 10% 
more throughput. 20 gives you 95%, 100 pushes it to 99% load, so lots of 
waiting for minuscule performance gains. (A real system is likely to 
have smaller variability.) The TCP listen queue does this already; I 
think it's typically set to 5.

Typical service times without load should be on the order of a few 
milliseconds if you want to support more than 100 request/seconds. Thus, 
   a queue of 10 might yield you a waiting time of maybe 50 ms.

In other words, not a major issue if the system design is at all competent.

Henning