Subject: Expiring of LATENCY

From: [email-masked]
Date: Fri, 6 Dec 2002 12:18:56 -0500

In 09-submitted I found:

   If a CS can both start sending the reply to a command and guarantee
   that all of the results can be sent from a command (short of
   something like network or power falure), prior to the "LATENCY"
   timeout value, then the "LETENCY" time has not expired.

I think this is a bit misleading/vague/useless as I doubt the CS has the 
ability to guarantee that it can return all the data prior to the timeout 
value occuring.  After all, if the CS can find the 500 entires on my 
calendar for this week in under 5 seconds (I have a fast backend store), 
the CS may not be able to tell if it can actually encode and send them all 
before 5 seconds have elapsed.

Should the CS timeout in the middle of sending data or before it begins 
because it knows it cant encode and send such a large blob of data in the 
alloted time??

Should the CS send what it can even though it knows it wont finish and 
then take the ACTION required?

Does it actually matter if the LATENCY time expired before the actual time 
_does_ pass??  That is, my CS determines it will take 7 seconds to encode 
and shove out the requested data but LATENCY=5 was used.  So should the CS 
consider that LATENCY expired and if so, so what??

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Fri, 06 Dec 2002 10:56:16 -0700

How about:

	If a CS can start sending the reply to a command
	prior to the "LATENCY" timeout value, then the "LATENCY"
	time has not expired.

[email-masked] wrote:
> ability to guarantee that it can return all the data prior to the 
> timeout value occuring.  After all, if the CS can find the 500 entires 
> on my calendar for this week in under 5 seconds (I have a fast backend 
> store), the CS may not be able to tell if it can actually encode and 
> send them all before 5 seconds have elapsed.
> 
> because it knows it cant encode and send such a large blob of data in 
> the alloted time??
> 
> Does it actually matter if the LATENCY time expired before the actual 
> time _does_ pass??  That is, my CS determines it will take 7 seconds to 
> encode and shove out the requested data but LATENCY=5 was used.  So 
> should the CS consider that LATENCY expired and if so, so what??
> 
> Bruce
> Bruce Kahn                                INet: [email-masked]

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Andrea Campi <[email-masked]>
Date: Fri, 6 Dec 2002 19:17:40 +0100

> before 5 seconds have elapsed.

I share your same doubts about the ambiguity. I'd say latency should
mean the latency, not the delay: that is, the time until the first
data is received, not the last.

This IMHO is what matters most: you want your CUA to be able to
put an upper to the amount of time it's willing to sit there doing
nothing. When it starts getting data, no matter if it's able to
act upon that or not, the CUA will be able to at least show the
current speed or something like that; and the CU will be able to
decide by herself if she wants to continue or cancel.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: [email-masked]
Date: Fri, 6 Dec 2002 15:52:36 -0500

>    prior to the "LATENCY" timeout value, then the "LATENCY"

That would be better if it were single sided but bounded latency can be 
either way.  As such how about:

    If a reply to a command can be sent (or begun to be sent)
    prior to the "LATENCY" timeout value, then the "LATENCY" 
    time has not expired.

This will cover both the CS and the CUA as the command sender as well as 
the case where some reply can be at least begun to be sent if not entirely 
completed.  Polish up the phrasing as you desire...

Related editorial nit, in paragraph above the corrected text above is:

    If the maximum latency time ...

you should remove the phrase 'maximum' as we dont have a minimum value do 
we??...  The latency time is the maximum time the command processor should 
delay but including 'maximum' in the text makes it sound like 
maxver/minver of sort.

Bruce

---

From: [email-masked]
Date: Fri, 6 Dec 2002 16:45:48 -0500

>    prior to the "LATENCY" timeout value, then the "LATENCY"

Dont forget the text near the top of 10.1.1 that says:

                                   If the command is unable to be
   completed in the specified amount of time (as specified by the
   "LATENCY" parameter value), then a "TIMEOUT" command MUST BE sent on
   the same channel to which there MUST BE a an "ABORT" or a "CONTINUE"
   command reply.

where it talks about command completion too...

Bruce