Re: 3.3 Bounded Latency

[Patrice Lapierre <patricel@xxxxxxxxxxx>]

On Mon, 2002-01-14 at 12:32, Doug Royer wrote:
> 
> 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. 

  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
> reflects that the fact the command is still in progress.
> 

 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.
   
   	  
> 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.
> 

  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. 

>,,
> >  While converting CAP to BEEP, we came up with the following
> > solution: use a different channel to cancel commands (inter-channel
> > communication is asynchronous).
> > 
...
> >    - Hard to explain/document.
> 
> What's hard? - send command on separate channel.

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

> >    - Draft-05 had the same limitation
> >      (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.

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