> I have estimated the worst case (probably) in solution B.
>
(snip)
>
> This scenario requires the SECOND POWER order ("n-1"+"n-2"+...+1) of
> aborts.
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.
> 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).
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).
> 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.
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.
> 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?
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. :-)
> 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.
>
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------