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 <gregs@sdd.hp.com> 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 gregs@sdd.hp.com ----------------------------------------------------------------