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
On Tue, 17 Feb 1998 14:35:26 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:
(snip)
> 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.
(snip)
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging Products Development Center 3 CANON INC.