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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 31 Aug 2006 17:39:02 -0400

Ah, but not necessarily if you can forward a request to another server,
which in turns forwards to another, ...

Do you really get a few millisecond response to a geo query with a full
set of polygons?  I thought it was a bit more (but not a whole lot
more).

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, August 31, 2006 5:30 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: [Ecrit] FW: LoST synchronous query and referals
> 
> 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
> 
> 
> Rosen, Brian wrote:
> > 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

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