Subject: How the solution B works? (Re: P1394> 1284.4 over SBP-2)

From: Greg Shue <[email-masked]>
Date: Tue, 17 Feb 1998 14:35:26 -0800 (PST)

Hi all,

It's time to respond to the discussion along this thread.
I hope this points out some areas of misunderstanding and
makes some of the issues easier to understand.

Akihiro Shimura wrote: (reformatted)
> If target request data transfer by "Data Available" flag in
> certain status block, initiator will subsequently append "SND
> data-in" ORB in the current task list.  It will be possible for
> the target to check if there is a "SND data-in" ORB in the task
> list BEFORE the initiator appends the "SND data-in" ORB.  After
> finding there is no "SND data-in" ORB, the target may issue
> another unsolicited status which indicates "Data Available".  By
> this status, the initiator may append one more (total two) "SND
> data-in" ORB in the task list.  After that, the target will need
> to abort the excessive ORB.
> 
> Is this a way the SBP-2 only solution works?

[Greg Shue]
No.  The behavior described assumes the ability to scan through the ORB
list and potentially process them out of order.  The proposal that Alan
and I gave used the ORDERED processing model.  In this model, only what
is at the head of the Task List can be used to make processing decisions.

[Akihiro Shimura]
> I would like to introduce these rules shown below,
> 1)      The initiator clear Unsolicited_Status_Enable register to forbid
> the target
>         to issue unsolicited status which says "Data Available", while
> the initiator
>         is appending new ORBs in the list.
> 2)      The target shall observe Unsolicited_Status_Enable register,
> whether or not it is
>         set to one, before it scans linked list of ORBs.
> 3)      When the target found Unsolicited_Status_Enable register is set
> to one,
> and there is no in-ORB in the list, then the target may send unsolicited
> status.
> 
> Then the initiator will not generate too many in-ORBs in the list.

[Greg Shue]
There are some problems with the rules:

  Rule 1 changes the definition of SBP-2.  SBP-2 does not provide a
  mechanism for the initiator to clear the Unsolicited_Status_Enable
  register.  A write of _any_ value to the register enables
  unsolicited status.

  Rules 2 & 3 assume that an Unordered processing model is used.
  See my previous comment.

Because the ORDERED processing model is used, the rules are unnecessary.

Akihiro Shimura wrote: (reformatted)
> It seems natural to make two independent logins for each
> direction, one for down-link and another for up-link by using the
> idea to map them into logical units.  Furthermore, by extending
> this to allow to allocate up-link in reverse fashion (i.e., the
> target of down-link makes a login to the initiator of down-link),
> the link between two devices will become symmetric if both ends
> have both initiator and target functionality.

[Greg Shue]
The idea of an task list for each direction to provide independent
data flow is a natural one.  The idea of requiring cross logins
(or 2 logins to the same device) would accomplish this.  Having
each login and task list on a separate device provides symmetry.

This is very similar to Alan's DFA proposal.  It is just abstracted
one layer.  The packet "write" is accomplished by an ORB rather than
an MTU.  The size of the FIFO is limited to the max size of the data
referenced by the ORB.

Can multiplexing of logical channels be provided on top of this?
Yes, but this could also be the communications profile for
services which are in independent Unit directories.

The ISSUE:
  The logins must deal with access control separately even though
  they are coupled together at the next higher layer.  No one has
  come up with a proposal to manage this.

Nagasaka Fumio write:
> If we choose 1284.4 as transport layer in PC printing architecture,
> we can use same transport layer to cover USB, 1394 and conventional
> parallel port. And if we adopt socket API on 1284.4 service, then we
> can use same interface for any local devices and for any network
> devices.
> 
> This feature greatly decrease development efforts to make protocol
> stack in PC printing area. And it would provide better usability even
> for end users.
> 
> If we choose new transport for SBP-2/1394 stack, then we need to
> develop different middle device driver to cover rest of other I/O(s).
> 
> How do you think this point?

Randy Turner writes:
> My point from all of this is that for the layering models discussed so
> far, we don't have to worry about providing a common API for
> applications. So we can keep our discussion focused on relevant
> technical transport issues.

[Greg Shue]
I agree with Randy that we don't have to worry about providing a
common API for applications.  We also don't have to worry about
providing a common transport stack since:

  - all that is required by the API is a common set of services
  - we are NOT going to get a common stack anyway, since IP1394
      will exist.

As for the thoughts expressed by Nagasaka Fumio, the idea is nice,
but impractical.

  - IP1394 will exist, so 1284.4 will not be THE (only) printing
       architecture.

  - I have not seen 1284.4 get strongly adopted over USB by the
       industry, though it makes sense for USB.

  - I think there is as much work developing an appropriate Data Link
       to fit beneath 1284.4 as there is to turn SBP-2 into an
       equivalent transport.  So I don't agree with it 'greatly
       decreasing development efforts,' especially since SBP-2
       will already be provided by OS vendors.

  - I don't think we have to keep the same transport protocol
       between USB (or 1284) and 1394.  I think that 1394 needs
       to provide at least the same kind of service.

  - We're not talking about only a _printing_ connection.  The PWG
       agreed to look at MFPs also, which is why I was brought on
       in the first place.  So, let's not forget scanning paradigms
       and preferred connection solutions.  This is where an SBP-2
       transport solution w/ multiple units really is preferred
       since it maps _directly_ to a SCSI model, and allows for
       other types of functionality.

Akihiro Shimura writes:
> As far as I understand, the "another unsolicited status" will not
> happen in this scenario by the definition given by Greg because the
> target is already in "Data Available" state. (Greg, thank you for the
> clarification.)
>
(snip)
>
> I'm not sure if I understand your question, but the functionality
> equivalent to multiple logical channel is already done in the SBP-2
> only solution (option B) via unit architecture. If the target does NOT
> behave as expected by the initiator, like asynchronous notification,
> "aborting task"(which implies subsequent retry) will be necessary to
> keep each direction independent.  To avoid the use of "aborting task"
> while keeping each direction independent, I thought it may be natural
> to allocate two independent links(logical units) for down-link and
> up-link instead of using "aborting task".

[Greg Shue]
You are correct about the unsolicited status behavior.
You are also correct about the Unit Architecture providing the
equivalent of "multiple logical channels."

You are also correct that the "task abort" mechanism is not
needed if the packets of data are kept on two different task lists.
But this leads to the issues I mentioned above.

Akihiro Shimura writes:
> Greg Shue <[email-masked]> wrote:
> >   If the target doesn't behave as expected and has lots of unsolicited
> >   data for the initiator, the target aborts the current task set and
> >   the initiator pauses sending data to the target until the target has
> >   no more data for the initiator.
> 
> The flow control part of "target-to-initiator" data transfer seems to
> be missing here.
> 
> I suppose that the condition follows to "until" in the above sentence
> would be "until the target has no more data for the initiator OR the
> initiator does not have resources to receive more data from the target."
> Is this what you intended or am I still missing something?
> 
> >   If we are doing unidirectional printing, then there is no data
> >   for the initiator, and the task set is never aborted.
> >
> >   If we are interacting with the device, and it behaves as expected,
> >   then there is no unexpected data for the initiator, so the task
> >   set is never aborted.  (For interactive Postscript, scanning models,
> >   and request/reply paradigms like SNMP)
> 
> This sounds like expectation (or requirement) for client applications
> to be master/slave.
> It seems that "request/reply" is expected to be done indivisibly and
> sequencially. Does the solution well cover the case "requests/replies"
> are done in parallel (more than one request are outstanding) as well?

The flow control occurs implicitly.  One "packet" gets transferred
from the target to the initiator per empty ORB queued.  The max
amount of data which may be sent has already been negotiated.  The
buffer is provided by the initiator and referenced by the ORB.  The
completion status indicates whether or not more data is immediately
available.  If more data is available and the initiator has buffer
space, the initiator will provide another ORB.  If no more data is
available, then the initiator may requeue the pending task set.  If
more data is available, but the initiator does not have buffer space
available, then both sides are blocked, so it doesn't really matter
what the initiator does.  It might as well requeue (at least the head
of) the task set and let the target proceed when possible.

As far as the expectation for client applications to be master/slave,
this is probably true.  I can't think of a client/server model
which isn't master/slave.  I also can't think of a scanning or
printing model which isn't master/slave.  I can't even think
of a case where request/replies aren't master/slave.

  Can anyone else come up with a good example to convince
  me otherwise?

Since there is no implicit association between data packets flowing
in each direction, it could work for multiple requests being issued
before multiple replies received.  BUT, I don't know how well it
would work.  If the device could buffer all the requests made
before having to send a reply, then it would work well.  If the
device can't buffer all the requests, then it must send the replies
before it can process more requests.  This case is covered because
deadlock is avoided.  You will have to determine for yourselves
exactly how _well_ this is covered.

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			[email-masked]
----------------------------------------------------------------

---

From: Akihiro Shimura <[email-masked]>
Date: Wed, 18 Feb 1998 09:13:43 +0900 (JST)

Just clarification ....

On Tue, 17 Feb 1998 14:35:26 -0800 (PST)
Greg Shue <[email-masked]> wrote:
(snip)

Message below is not from me. It's from Nagasaka-san.

> [Akihiro Shimura]

[Fumio Nagasaka]

--
 Akihiro Shimura ([email-masked])
 Office Imaging Products Development Center 3
 CANON INC.

---

From: Akihiro Shimura <[email-masked]>
Date: Fri, 27 Feb 1998 22:33:42 +0900 (JST)

Hi,

I have estimated the worst case (probably) in solution B.

At first, let me assume "n" write (initiator-to-target) ORB's are in
the task list, and the target has a small data available to the
initiator while the target is processing 1st write ORB in the list.
After finishing 1st write ORB, the target finds deadlock condition
(because the target is almost buffer full status by previous ORB's)
and aborts "n-1" write ORB's in the list.
The initiator appends a read (target-to-initiator) ORB in the task
list, and the target completes this ORB with no more data condition.
Because there is no available data from the target, the initiator
re-queues "n-1" write ORB's just aborted.
The target has another small data available to the initiator while the
target is processing 2nd write ORB in the list.
After finishing 2nd write ORB, the target finds deadlock condition and
aborts "n-2" write ORB's in the list.
The initiator appends a read (target-to-initiator) ORB in the task
list, and the target completes this ORB with no more data condition.
Because there is no available data from the target, the initiator
re-queues "n-2" write ORB's just aborted......, and so on.

This scenario requires the SECOND POWER order ("n-1"+"n-2"+...+1) of
aborts.

Because 1284.4 IS providing independent data flow in each direction in
LINEAR order, this scenario is likely to happen on the applications
expecting independent data flow in each direction(in linear order).

Though "Aborting task" may not be so many if "n" is small enough, "n"
will depend on its bandwidth and latency requirement, but not on the
transport behavior.

I don't want to restrict every applications implicitly to work around
this transport behavior.

So, I prefer to make a login per direction because it provides
independent flow in each direction in LINEAR order, though there is an
issue how to bundle two logins.

I think having multiplexing in two places (multiplex sessions by
logical unit and multiplex each directions by abort) makes the
protocol more complex.

Is this estimation correct? Any comments?

Akihiro Shimura

(snip)

---

From: Greg Shue <[email-masked]>
Date: Fri, 27 Feb 1998 12:28:01 -0800 (PST)

(snip)
> This scenario requires the SECOND POWER order ("n-1"+"n-2"+...+1) of

Yes, this is the worst case.  And, it only occurs with
an unexpected data flow in the reverse direction.  So far
this has been considered an exception, not typical behavior.
So, I didn't mind poor performance for exception handling.
We never said that SBP-2 worked well for the atypical data flow.

> expecting independent data flow in each direction(in linear order).

True.
Are these applications of high bandwidth?
Are they typical?
I don't think that attribute is typical of the device models
used for PC printing (or PC scanning).

> I don't want to restrict every applications implicitly to work around

They don't have to.  That is why the behavior is hidden in the
transport layer.  If the data flow goes as expected, things work
smoothly.  If it doesn't then the transport is basically doing
exception handling beneath the application.  Also, the transport
driver can easily keep "n" small (1-4) without the application
caring or knowing.

> Is this estimation correct? Any comments?

Yes, please make a proposal for supporting dual fetch-agents in
the target under one login, and a plan for getting major OS vendors
to support it, and I'll be happy.  I've just by trying to
address the less formidable problem of using the SBP-2 protocol
and the implemented drivers without change.  :-)

While you're at it, how about figuring out a means of supporting
a fetch agent on each node under a single login.  It's a
related problem that we keep coming back to.  :-)