Subject: 3.3 Bounded Latency

From: Doug Royer <[email-masked]>
Date: Sat, 12 Jan 2002 15:28:05 -0700

In order to be able to abort a command in progress and not
have to wait for the CS to finish or timeout, I have modified
the example to use ANS/NUL or RPY messages from the CS in order
to allow the command to continue or be aborted at any time.
This was a feature in the 05 version of CAP.

Additionally, in the 06 version, the CAP command seemed to
change channels in the example. Here the CAP command is tied
to the original channel until the operation is aborted, times-out,
or finishes.

In "3.3 Bounded Latency"

Replace the example with:

   Example:

   In this example [email-masked] attempts to read a calendar but
   the latency time he supplies is not sufficient for the server to
   complete the command. The message number is '4' on channel '1' in
   this example.

   C: MSG 1 4 . 2043 284
   C: Content-Type: application/cap+xml
   C:
   C: <search latency="3" action="ask"/>
   C: <![CDATA[
   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VQUERY
   C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT
   C:   WHERE DTEND >= '19990714T080000Z' AND
   C:   DTSTART <= '19990715T080000Z'
   C: END:VQUERY
   C: END:VCALENDAR
   C: END

   After 3 seconds the server sends an ANS message to the CUA
   informing it of the timeout. Note: the msgno and channel are
   the same as the original MSG and the '1' at the end is the
   ANS sequence number. Had the CUA NOT told the CS to wait for the CUA
   to decide if the CS should continue when it added the action="ask" 
   attribute, then the CS would have sent a RPY and not a ANS message
   indicating the end of exchange for msgno '4' on channel '1'.
   OR if there had already been several ask/continue exchanges (via
ANS),
   and the final request did not indicate an ask the CUA, then the
   final msgno '4' message would be terminated with a NUL reply.
   In other words, the only way to ensure that msgno '4' on channel
   '1' is not reused is to not terminate the MSG/RPY or MSG/RPY/NUL
   sequences until the CUA has decided to terminate the request, or
   the CS has finished with channel '1' msgno '4'.

   The CUA MUST be prepared for an ANS/NUL or a RPY on any bounded
   latency MSG request.

   S: ANS 1 4 . 102 46 1
   S: Content-Type: application/cap+xml
   S:
   S: <timeout/>
   S: END

   If Bill wants to continue and give the server more time he would
   issue a "continue" message:

   Here the CUA tells the CS in msgno '5' to continue msgno '4' on
   the same channel by the msgno="4" attribute, additionally the CUA
   wishes the CS to continue with a 3 second bounded latency and again
   ask the CUA if a timeout is reached.

   C: MSG 1 5 . 166 79
   C: Content-Type: application/cap+xml
   C:
   C: <continue msgno="4" latency="3" action="ask"/>
   C: END

   The CS acknowledges the continue command. In this case there
   is no CAP data. BEEP simply acknowledges that MSG '5' was received
   on chanel '1'.

   S: RPY 1 5 . 167 0
   S: END

   If Bill wished to abort the command he would issue an "abort" MSG
   for MSG '4' on channel '1'. There is no need for the CUA to wait
   for a ANS msgno '4' or RPY msgno '4' message for the CUA to send
   this command.

   C: MSG 1 6 . 166 62
   C: Content-Type: application/cap+xml
   C:
   C: <abort msgno="4"/>
   C: END

   And the CS would acknowledge the "abort" command and terminate
   the msgno '4' processing. If the CS had already sent the NUL or
   RPY MSG, the CS would ignore the "abort" command that was sent
   by the CUA. Note that CUA's  MUST BE carful not to reuse the
   same msgno's on a given channel until the CUA and the CS are both
   satisfied that the entire exchange and commands are complete when
   using bounded latency.

   S: RPY 1 6 . 324 0
   S: END

   Here the CS terminates the channel '1' msgno '4' command that was
   requested by the CUA above. In this example a NUL command is sent
   because there had already been at least one ANS message sent by
   the CS. If no ANS messages had been sent by the CS, the CS would
   have issued a RPY message below and not a NUL message.

   S: NUL 1 4 . 2723 111
   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCAP
   S: METHOD:REPLY
   S: REQUEST-STATUS:2.0.3;Request Aborted by the CUA.
   S: END:VCAP
   S: END

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Jan 2002 08:14:30 -0500

> to the original channel until the operation is aborted, times-out,

  I couldn't find the channel change you're referring to (they 
all seem to be using channel 1). In what example did you notice 
this?

  If you meant message number change (not channel), then 
this is intentional, and was previously discussed on the list.

see:
   http://www.imc.org/ietf-calendar/mail-archive/msg02516.html

 You are correct indicating that in draft-06 the CUA can't 
cancel a request before the timeout. However your proposition 
is incompatible with BEEP.

From RFC3080 section 2.6.1:

 "A BEEP peer acting in the server role must process all "MSG" messages
  for a given channel in the same order as they are received.  As a
  consequence, the BEEP peer must generate replies in the same order as
  the corresponding "MSG" messages are received on a given channel."

The example violates this in in at least 2 ways:

  1. RPY 5 and RPY 6 are sent before the end of the replies of MSG 4.

  2. DEADLOCK: upon timeout processing of MSGNO 4 waiting 
     for MSGNO 5, but MSGMO 5 can't be processed before 
     MSGNO 4 is completed.

  Draft-06 makes use the peer-to-peer nature of BEEP to avoid
these problems, but a CUA can't preemptively cancel a command. 

 While converting CAP to BEEP, we came up with the following 
solution: use a different channel to cancel commands (inter-channel
communication is asynchronous).

  However this approach was not included in draft-06,
for the following reasons:

   - The introduction of inter channel dependencies may 
     raise other issues.
   - Hard to explain/document.
   - Can be added later without breaking compatibility.
   - Draft-05 had the same limitation 
     (even though enhancements were discussed on the list).

---

From: Doug Royer <[email-masked]>
Date: Mon, 14 Jan 2002 10:32:36 -0700

>   the corresponding "MSG" messages are received on a given channel."

Your right, my example should sent the out of band data
on a separate channel. I knew that just after I went to bed :-)

I guess the issue I badly wrote about was that the command
started on channel 1, seems to require states kept across
message boundaries. I would prefer if channel '1' (as used
in the example) did not complete until the CAP command was
complete. I see the usage of multiple BEEP commands for a single
CAP command (as in from initiation to completion of operation),
not in the spirit of BEEP. I think that the MSG/ACK..ACK...NUL
reflects that the fact the command is still in progress.

And as a BEEP implementations should support 257 concurrent channels,
sending the continue or abort on one of those other channels
pretty much is a no-op.

> these problems, but a CUA can't preemptively cancel a command.

I agree 06 says that. And I could live with that as a MAY.

>    - Hard to explain/document.

What's hard? - send command on separate channel.

>    - Can be added later without breaking compatibility.

True.

>      (even though enhancements were discussed on the list).

No. In fact the only limitation was if pipeline was set to 1,
else it did not have that limitation.

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Jan 2002 14:38:42 -0500

On Mon, 2002-01-14 at 12:32, Doug Royer wrote:
> 
> I see the usage of multiple BEEP commands for a single
> not in the spirit of BEEP. 

  Your initial proposition could be fixed. I think it makes very 
interesting use of the an ANS message. However the draft-06 approach
seem to have more advantages.

> I think that the MSG/ACK..ACK...NUL

 Conceptually both approaches uses a REQUEST/ACK,ACK,ACK/RESPONSE.

It's the definition of ACK that differs:
  
In your suggestion (correct me, if a donn't understand it 
correctly): 

  ACK = 1. ANS "timeout" from the CS (advantage of using same msgno).
        2. MSG "continue" from the CUA on a different channel +
        3. RPY from CS.

Draft-06:
  ACK = 1. MSG "timeout" from CS
        2. RPY "continue" from CUA (same channel).

If we consider a basic scenario without a preemptive abort. Then
the draft-06 approach have the following advantages.

 1. Minimize the number frames.

 2. It's clearly stated by BEEP that for every MSG there is
    an associated response. As a consequence a BEEP compliant 
    CUA MUST respond to a timeout request, and the channel 
    waiting for the response will not freeze forever.

 3. All the message flow are sent over the same channel.

 4. Depending on the usage, the channel that receives the 
    continue/abort may be busy. The delay impacts the channel 
    processing the request that generated the timeout.
    With the draft-06 approach it's the CUA receives the timeout 
    message. A CUA MSG queue is likely to be empty (only used for
    timeout), and the RPY from the CUA is not queued on the 
    server.

> sending the continue or abort on one of those other channels

  257 are probably more than enough, but they do take some resources 
on the server. I don't see why we should encourage inter-channel 
communication when not necessary. 

>,,
...
> What's hard? - send command on separate channel.

  You sold me, let use the inter-channel communication for
preemptive "cancel".

> else it did not have that limitation.

  I checked draft-05, and you're correct.