Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE)

From: [email-masked]
Date: Tue, 4 Feb 2003 16:30:41 -0500

Larry wrote on 01/30/2003 03:56:37 PM:

First Id like to say thanks for your POP3/IMAP/LDAP reply last week.  It 
took a day to sink in but I finally got it and partly answered my own 
question in a different thread.

> It simplifies implementations. (You do want people to implement this,
> right?) What happens if you submit a bounded command (3 seconds,
> say), wait 3 seconds, and the server doesn't come back? What if it
> doesn't come back in 30 seconds?

This is something the draft needs to cover (plus its not related to 
unbounded commands).  Thanks for raising it.

> What if you submit an unbounded command, wait 1 second, submit a
> CANCEL, and the server still hasn't replied in 30 seconds?

This assumes that we have some CANCEL command.  Currently we do not nor 
has one been actually be proposed for inclusion yet.

ANY command could fail to get a response so whatever solution we devise 
for your 1st question needs to cover them all.

> What if the network is down or tremendously slow?

Or the CS is under very heavy load... Or the command triggered some kind 
of housecleaning or fixup action on a particular TARGET...

I don't think we've considered the case of a CS actually being clustered 
and thus load balanced, etc. but that too plays into this in the ever 
growing Enterprise and hosted environments.

> [...]
>    Still, why invent more stuff if unbounded commands do not make sense 
given 
>    our current model?...  Or if we are going to keep unbounded commands 
then 
>    we really should expreslly codify the way that a CUA terminates them 
so we 
>    have consistant behaviour among all implementations.
> 
> How am I, as a client, suppose to know how long something is going to
> take the server? Maybe the server is really loaded. Maybe it affects a
> lot of data on the server.

The intent of the latency value is for the CUA to express to the CS "This 
is how long Im willing to wait to get back my results.  Check back with me 
then if you are not done and see if I want to CONTINUE or not."  If the CS 
is heavily loaded then of course its possible that it does not respond 
exactly at the specified time with a CONTINUE command. 

Also the CUA must factor in that the clock for latency does NOT start when 
the command is put on the wire to the CS (at least in my mind) so using a 
local timer to say "Hey, that stupid CS didnt complete the command in 5 
seconds and I dont see a CONTINUE command that I would therefore expect; 
something must be wrong!" is not a good design.  Its also why I objected 
to the current draft text that mandates "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..." since this kind of requirement is impossible to 
accurately do.

> The last thing I want, as a server, is for clients to try an operation
> for 5 seconds, then try it for 10, then 20, etc., until it's done.

Thats exactly what LATENCY is for; so the CUA can "give the server a 
little more time to complete the command".

Do you think that we need to have some kind of minimum latency values that 
CS's will accept so that they can tell CUAs "I dont care if you want 
results within 5 seconds, Im only going to guarantee a minimum response 
time of 30 seconds"?  Or perhaps you are thinking that bounded latency is 
too much to do and that it should be optional entirely (ie: All CAP 
commands follow the existing POP3/IMAP/LDAP/etc model of 'Its done when 
its done and if you dont want to wait then leave.")??

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: Tue, 04 Feb 2003 15:25:05 -0700

> has one been actually be proposed for inclusion yet.

    CMD: ABORT

    Purpose: The "ABORT" command is sent to request that the named or
    only in process command be aborted.  Latency MUST not be supplied
    with the "ABORT" command.

Use ABORT as it has no restriction that it can only be sent after
a timeout.

> 
> Do you think that we need to have some kind of minimum latency values 
> that CS's will accept so that they can tell CUAs "I dont care if you 
> want results within 5 seconds, Im only going to guarantee a minimum 
> response time of 30 seconds"?

Minimum latency - no. 20 years ago 56K direct internet was screaming fast.
In 10 years 5 seconds may be too long. The CS can always send an
error back when it can not handle the command.

> Or perhaps you are thinking that bounded 
> latency is too much to do and that it should be optional entirely (ie: 
> All CAP commands follow the existing POP3/IMAP/LDAP/etc model of 'Its 
> done when its done and if you dont want to wait then leave.")??

Adding latency is optional.

-- 

  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: [email-masked]
Date: Wed, 5 Feb 2003 10:54:50 -0500

> Use ABORT as it has no restriction that it can only be sent after

Hmmm.  From Section 10.1.1 Bounded Latency:

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. If the CUA initiated the original command, then 
the CS would issue the "TIMEOUT" command and the CUA would then have to 
issue an "ABORT" or "CONTINUE" command. [Snip]

Upon receiving an "ABORT" command, the command must then be terminated. 

The first bit implys (correctly or not) that the ABORT command is sent in 
response to the TIMEOUT command. 

Also since the ABORT command only applys to the channel it is sent on, and 
the CS is already busy with an unbounded command, I dont see that the 
ABORT will effect the unbounded command that the CS is processing.  I dont 
find any requirement that the CS process pipelined commands out of order 
or concurrently.  That is, if the SEARCH is unbounded and then the sends 
an ABORT on the same channel, I see no text/requirement that the ABORT 
command get acted on until the SEARCH is done.  Catch-22, the ABORT 
command wont be seen (since no TIMEOUT command was sent by the CS and then 
waited for) until after the unbounded command is done thus negating the 
need for ABORT..

I see that in Section 10.1.2 it says:

Purpose: The "ABORT" command is sent to request that the named or only in 
process command be aborted. 

so Im wondering if "only in process command" is meant to refer to the 
current command on that channel or to a command that has no ID (or 
both?)?... 

Also, it talks of "the named...command" so checking ABNF shows:

abortparam   = *(
                      ; the following are optional,
                      ; but MUST NOT occur more than once

                        id-param
                      / localize-param

                      ; the following is optional,
                      ; and MAY occur more than once

                      / other-params
                      )

However, the definition of id-param is:

id-param         = ";" "ID" "=" unique-id
                 ; The text value supplied is a unique value
                 ; shared between the CUA and CS to uniquely
                 ; identify the instance of command in the
                 ; the current CUA session. The value has
                 ; no meaning to other CUAs or other sessions.

Its intended use is to sync up replys to commands (mainly in the event of 
multiple commands at the same time but not even for single command cases 
too).  In the ABORT case it is NOT identifying the ABORT command but 
rather the other command that the sender is trying to abort.

Some prose to this effect should be added to the ABORT command so that its 
clear that CMD;ID="FizBin1":ABORT is trying to indicate "Terminate the 
command named FizBin1 on this channel" rather than identifying the ABORT 
command so that a response can be matched up to it.  This though is 
overloading id-param and prevents the sender from being able to match up 
the proper XXX-reply to the command.. 

After all, its possible that the unbounded command FizBin1 completes 
before the ABORT command is received.  So then the ABORT sender has to 
decipher the responses:

BEGIN:VCALENDAR
TARGET:relcalid
CMD;ID=FizBin1:REPLY
VERSION:2.0
PRODID:-//someone's prodid
BEGIN:VREPLY
BEGIN:VEVENT
REQUEST-STATUS:4.1;Im sorry Dave\, I cant do that...
END:VEVENT
END:VREPLY
END:VCALENDAR

from

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//someone's prodid
TARGET:relcalid
CMD;ID=FizBin1:REPLY
BEGIN:VREPLY
REQUEST-STATUS:2.0.3;I did as you requested.
X-IBM-WIDGET:Command was processed by CS1 within 10 seconds.
END:VREPLY
END:VCALENDAR

as belonging to the ABORT command or the command that was asked to be 
aborted or to the command itself.  Can you match them up quickly and 
correctly?

> error back when it can not handle the command.

Larrys case is not an issue with the CS not being able to handle the 
command; its a desire to avoid having clients just keep pecking at it with 
tiny CONTINUE values resulting in the CS spending more time doing more 
TIMEOUT/ABORT/CONTINUE handling than actual CREATE/SEARCH/etc command 
handling. 

As the CS has to scale up to handle thousands of users concurrently (ie: 
Enterprise sites) then having CUAs all do CAP commands with tiny expected 
response times becomes a burden to the CS.  There is only so far that 
relying on very very beefy MP boxes to efficiently handle lots of threads 
can take us. 

I was merely asking Larry if he thought that the needed to be some way for 
the CS have some say in the process instead of letting the CUA be the sole 
source of control when deciding acceptable latency values.  I could see 
this as a useful GET-CAPABILITY response. 

For example, under light loads the CS would send back "I should be able to 
process commands with a latency value of 2 seconds just fine." but under 
peak loads it would send back"I should be able to process commands with a 
latency value of 40 seconds just fine."  That way the requesting CUA can 
at least indicate to the CU that operations may take longer or even 
better, adjust their "Continue for 10 seconds", "Continue for 30 seconds", 
"Continue for 60 seconds" algorithms that Larry mentioned to accomoate the 
CS's load.

All this is not unreasonable to consider, especially if we plan to 
implement this on larger scale systems...  I am merely asking Larry if he 
thinks its something CAP needs.

> Adding latency is optional.

Yes it is and if the CS is busy processing the unbounded command then its 
not going to be able to process the ABORT command (see above).  Thats why 
the peer protocols cited have no ABORT analogs, they simply drop the link 
and reestablish it.

FMI: Can ABORT be used to cancel commands that have no id-param?   For 
example, if the CREATE command in Section 10.1.4 has no LATENCY or ID 
property parameters:

BEGIN:VCALENDAR
PRODID:-//someone's prodid
VERSION:2.0
CMD:CREATE
TARGET:cal.example.com
BEGIN:VAGENDA
CALID:relcalz1
NAME;LANGUAGE=en_US:Bill's Soccer Team
OWNER:bill
CALMASTER:mailto:[email-masked]
TZID:US/Pacific
END:VAGENDA
BEGIN:VAGENDA
CALID:relcalz2
NAME;LANGUAGE=EN-us:Mary's personal calendar
OWNER:mary
CALMASTER:mailto:[email-masked]
TZID:US/Pacific
END:VAGENDA
END:VCALENDAR

Just how would my CUA ABORT it?  CMD:ABORT on the same channel?  Without 
requireing some form of command concurrent processing or pipelining in the 
CS, this isnt doable.  The only simple solution is the one used in peer 
protocols (Disconnect/reconnect/reauthenticate)...

Bruce
PS: In answer to my examples: The former response is the CS's response to 
the unbounded command and then latter response is the response to the 
ABORT command; both were taken from draft 10 12Jan2003 examples with just 
minor tweaks...
==========================================================================
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...