Subject: P1394> 1284.4 over SBP-2

From: Larry Stein <[email-masked]>
Date: Mon, 09 Feb 1998 08:25:11 -0800

Hello Everyone,

I'm sending this message to see if we can stimulate some discussion on this
subject prior to the 1394PWG meeting in Austin next month.

For the past year we have been meeting to develop a standard to provide the
high functionality transport method for printing over the IEEE 1394
interface.  This is 'high functionality' , or 'thick' transport, as opposed
to the 'thin' transport that is being developed by the PWG-C.  The
direction that our group has taken has involved reviewing FCP, DFA, SBP-2,
and others, as the lower transport and datalink interface, with something
else as the transport interface.  This something else has focused on 1284.4
or on a native 'glue' layer to the underlying datalink.

At this point in time we have apparently narrowed our potential solutions
to the following:

A- 1284.4 with SBP-2
B-  New SBP-2 command set with SBP-2

As many of you are aware, I'm primarily in support of option A as the
preferred solution.  I'd like to take this opportunity to provide some of
my reasoning and get feedback from you.

My support for this solution is not necessarily a technical reason, but a
market reason.  As Greg Shue et al pointed out at the Maui meeting, it is
possible to provide the required functionality by defining a new Command
Set for SBP-2.  This would provide a transport solution for 1394 that is
based solely on the SBP-2 protocol.  Technically, this is probably a better
solution than option A.

My question is "Is this really the best solution for the market today?".
Many of us have expended great effort in developing the IEEE P1284.4
standard.  One of the purposes and goals of  the development was to create
a datalink independent transport standard that could be used over the
parallel port and other physical interfaces.

The intent here was to create a standard that would allow a peripheral to
operate over various interfaces without requiring major architectural
changes to the product.  In other words, a modular approach to the
peripheral design.  A printer or MFP device could be developed to work with
1284.4 over parallel today, and 'easily' adapted to work over 1394
tomorrow.  The host application interface may not even know the difference.

I think that this is the primary reasons for choosing option A.  It sends a
clear statement to peripheral and OS vendors that 1284.4 is the preferred
transport interface for printer and MFP peripherals.  We back this up by
providing solutions for parallel (1284.3) and for 1394.  This is not a
stagnant industry and certainly new interfaces will appear in the future.
I think it would be a great service that we provide a clear migration path
between interfaces that do not require redesign of the entire system.

Providing both options may be the result of this effort.  I think that
option A should be the preferred one.

I await your responses.

Thanks,
Larry

***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

---

From: Greg Shue <[email-masked]>
Date: Tue, 10 Feb 1998 19:21:19 -0800 (PST)

> I await your responses.

OK, here we go...

> tomorrow.  The host application interface may not even know the difference.

As I understood it, the ability for 'a peripheral to operate over
various interfaces without requiring major architectural changes
to the product' is provided by meeting the specified transport
service requirements.  As long as the transport requirements are
met, no architectural changes are required of the product.  Thus,
the transport layers are all modular with respect to the product.
(I think this is also why the PWG has not tried to eliminate a
TCP/IP printing solution.  :-)

The main difference between options A and B is whether multiple
services are made available through a 1284.4 MUX layer, or
through a combination of Unit Directories and Logical Unit
Numbers.  The command set features needed for a combined
1284.4/SBP-2 solution are essentially identical as for an
SBP-2 only solution (as shown below).

  In order to provide a combined SBP-2/1284.4 solution, an
  SBP-2 command set must be provided which meets the Data Link
  requirements spelled out for 1284.4.  These are:

    R1) Register/Unregister transport layer with the Data Link layer
    R2) Packet Data Transfer - error free, in order, as a whole
    R3) Asynchronous Operation - no polling shall be required.

  In order to map this within SBP-2, then the command set must
  provide (at least) the following features:

    F1) Transient link interruption support
	  (to support R2 and R3)
    F2) Non-transient link loss indication  (to support F1)
    F3) Extended SBP-2 Access Control to the transport
	  interface (to support F1)

    F4) SBP-2 ORB execution model for packet transfers
	  (to support R2 and R3)
    F5) Encapsulating of 1284.4 packets into ORBs
	  (to support R2)
    F6) Policy to determine maximum DL packet size
	  (to support R2 and F1)
    F7) Policy for how 1284.4 dialogue maps into SBP-2 access
	 control (to support R2, R3, and F1)

    F8) Standard mechanism for indicating existence of 1284.4
	 peer (to support R1)

    So, any of these features which are common with an SBP-2 only
    solution are outside the scope of concern here.  (For the
    unfamiliar, they all are provided in the (very rough) SBP-2
    only proposal presented at the January PWG 1394 meeting.)

These features are also those required for an SBP-2 only solution.
Since these are in common, they _don't_ affect the choice of option A
vs. option B.

I can't give an answer to Larry's question directly, because "best"
is rather subjective.  What's "best" for a customer might not be
"best" for a developer, and that might not be "best" for a
technology, which are all indirectly related to what is "best"
for the market.  I tried to identify above what are not areas of
tradeoffs between the two options so that we can look at what are.

If "best" is thought of in terms of market, then (I suppose)
supportability and deployment of the solution(s) matter the most,
because the 'market' has almost no history.  There really is no
legacy issue which makes either choice A or choice B preferred,
even though there are "legacy" printing solutions which will need
to be supported (i.e.  AVC, IP1394).  So, each of the following
areas become signficant:

If "best" is thought of in terms of providing the transport
services outlined by the requirements, then there is no
signficant difference between the SBP-2 only solution or the
combined solution.

If "best" is thought of in terms of developers and development
effort, then there is no significant difference between providing
the SBP-2 only solution or the SBP-2 portion of a combined
solution.  There will be additional effort for a combined
solution if a 1284.4 driver needs to be developed.

If "best" is thought of in terms of (availability of) OS support,
then the SBP-2 only solution is preferred because a greater portion
of the total solution already is provided by or is committed to
by OS vendors.

If "best" is thought of in terms of product cost, then the SBP-2
only solution is preferred because it has fewer layers.

If "best" is thought of in terms of performance, then the SBP-2
only solution is preferred because it isn't limited to 64-KByte
packets.

If "best" is thought of in terms of 1394 bus usage, then the
SBP-2 only solution is preferred because it doesn't have the CBT
crediting traffic of 1284.4.

If "best" is thought of in terms of compliance testability, then
the SBP-2 only solution is preferred because it is simpler and
has fewer layers.

If "best" is thought of in terms of availability customer
solutions, then the SBP-2 only solution is preferred because of
it's smaller footprint (which makes it more attractive to
integrate into more devices) and it's spreading use for varying
types of services on 1394.

> between interfaces that do not require redesign of the entire system.

Unfortunately, that message of 1284.4 being "the preferred
transport interface for printers" has been lost in the shuffle.
There are (currently) four transport protocols being defined on
1394 for printing.  These are:

  + AVC (for video snapshot)
  + DPP (for non-PC device-to-device)
  + PWG 1394 solution(s) (being discussed)
  + IP1394

I also haven't seen it get embraced for standardization on USB,
where hardware limitations and lack of a multiplexing transport
protocol solution identify a hole which 1284.4 can fill.

When this is added to (Apple's) Eric Anderson's thoughts of:

  - Emulating a dead technology with new technology may yield
    short-term savings in implementation, but at the expense of
    long-term losses in performance.  (philisophical)

  - Amazingly, reason prevailed, and Tailgate was abandoned in
    favor of a pure SBP-2 protocol for disk drives. (historical)

  - From what I have seen of how this (1284.4 over SBP-2) works,
    it is quite inefficient, with lots of unsolicited status
    requests and in general lots of hand-holding by the CPU on the
    initiator.  This is not what SBP-2 was designed for.  (perceptual)

  - Used properly, SBP-2 allows huge data transfers that can proceed
    at the pace of the consumer (printer), with no hand-holding by
    the host (computer)... SBP-2 and OpenHCI make this possible - but
    only if protocols are designed with care to avoid needless
    interruption of the host.  (practical)

  - 1394 is far more "future friendly" and scalable than other
    interconnects were at their introductions...  The more inefficient
    the protocol we choose, the more demand there will be for
    ever-faster interconnects.  A well-designed, efficient protocol
    can last a very long time, and serve everyone's needs better during
    that time.  (consequential)

  - To conclude, I want to ask a simple question:  Has anyone run
    this idea past Microsoft?  Microsoft killed off Tailgate, and
    my guess is that they may have similar feelings about printing.
    Market reality is that we'll all follow whatever they decide,
    so it really makes sense to get them involved.  (REALISTIC!!)

And (from a previous posting of Eric's):

 -  Microsoft says that their treatment of printers will be
    different.  They will only login to printers and other shared
    devices when they actually want to use the printer.  So a printer
    with only one login could be shared by several Windows systems.
    Apple plans to do the same thing for printers using SBP-2.

And the most quotable quote from the January 98 PWG 1394 meeting:

  "Every protocol looks light until it's implemented."

Given all of this, I am compelled to support option B.

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

---

From: Larry Stein <[email-masked]>
Date: Wed, 11 Feb 1998 20:41:05 -0800

Greg,

Thanks for your comments.  The purpose of starting this thread was to get
some of these issues and questions discussed before the next meeting.  I
think it's working.

Thanks,
Larry

>Given all of this, I am compelled to support option B.
**********************************************************
Larry A. Stein		Ph. 619-292-2742
Warp Nine Engineering	Fax 619-292-8020
[email-masked]		http://www.fapo.com
**********************************************************

---

From: Akihiro Shimura <[email-masked]>
Date: Fri, 13 Feb 1998 00:05:04 +0900 (JST)

On Tue, 10 Feb 1998 19:21:19 -0800 (PST)

> OK, here we go...

OK, I'll follow...

> > B-  New SBP-2 command set with SBP-2

(snip)

> the transport layers are all modular with respect to the product.

I agree. This was original intent of the HPT which Ueda-san and I
introduced from last June meeting.

(snip)

> Given all of this, I am compelled to support option B.

Basically, I also support to consider option B, but it is still not
clear for me how the data transfer of each direction is done
independently within single login in SBP-2 only solution.

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?

I think that aborting tasks implies subsequent task retries, and may
not be efficient.
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.

Any suggestions?

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

---

From: [email-masked]
Date: Thu, 12 Feb 1998 08:56:43 -0800

I tend to favor option B as well.
     
     I think Shimura san has some good points at the end of his message 
     that goes to the heart of what is still not clear with the option B 
     proposal. I think we need to work up some example scenarios and 
     explore exactly how this will work. Greg Shue got any ideas here.
     
     regards,
     Alan

______________________________ Reply Separator _________________________________
Subject: Re: P1394> 1284.4 over SBP-2
Author:  Non-HP-shimura ([email-masked]) at HP-Roseville,mimegw3
Date:    2/12/98 7:05 AM

     
OK, I'll follow...

(snip)

     
(snip)

     

Any suggestions?

---

From: Greg Shue <[email-masked]>
Date: Thu, 12 Feb 1998 10:24:21 -0800 (PST)

> Is this a way the SBP-2 only solution works?

It's not the way I intended it to work.  Let me work through
the model I've had in mind.

It is a status signal that data is available for the initiator.  It is
not an event requesting a new task be placed on the task list.

The status is updated at exactly two points in time:  on the
completion of a task; and on a spontaneous change from No Data
Available to Data Available when there are to active tasks on the
task list.  It is up to the initiator to determine whether a new
task needs to be enqueued on the task list or not.  The task
enqueuing algorithm for the initiator would basically be:

  for (;;)
  {
      while target has unexpected data available
	  get target data one request at a time

      enqueue one request for an expected data transfer
  }

When the target has data available, and at least one request
exists on the active task list, the data available indication is
given on the completion status of the first ORB.  The initiator
will enqueue a new ORB for receiving target data if, and only if,
no request for target data has already been enqueued on the task
list.  This ORB would be associated with the "hanging read"
already required for independent communication in each direction.

The target would continue to process the ORB list until one of
the following states is reached:

  S1) the ORB list will be empty  (no active task set)

  S2) the ORB list processing stalls at a data transfer to the target,
      and the target has no data for the initiator.
      (no more target buffer space, and no reason to abort the task set)

  S3) the ORB list processing stalls at a data transfer to the initiator
      (initiator expects data from the target, but none is currently
       available)

When data becomes available, the following transitions take place:

  From S1
    the target signals Data Available via unsolicited status;
    the initiator enqueues one ORB to receive the data;
    the target resumes processing the ORB;
    on completion of the request, the target indicates whether
      or not more data is available.

  From S2
    the target aborts all the requests on the task list and indicates
      that data is available for the initiator on each request;
    the initiator enqueues one ORB to receive the data;
    the target resumes processing the ORB;
    on completion of the request, the target indicates whether
      or not more data is available.

    When the target has no more data available, the initiator
      requeues the aborted requests.

  From S3
    the target continues processing the task set

The only ineffeciency occurs when the target doesn't behave the way
the initiator expects.

  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)

  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 worst-case scenario occurs if the target keeps generating bursts
of unexpected data for the initiator and the task sets are perpetually
aborted.  The net effect of this is minimized simply by minimizing
the length of the active task set!  Having 2-4 data transfer requests
queued  (e.g. double-buffering) may be sufficient (for most applications)
to keep the task list running and the target busy.

> I think that aborting tasks implies subsequent task retries, and may

Yes, aborting tasks implies subsequent task retries.
The overhead is in the target (pre) fetching the ORBs
in order to abort them, and in requeuing the task set
when the data available indication disappears.

But don't forget that the maximum data transfer size is known,
so the target doesn't need to fetch any real data until it knows
that it can complete the request!

> devices will become symmetric if both ends have both initiator and

Haven't we been down this road before?  (Yes, and rejected it.)

---

From: Akihiro Shimura <[email-masked]>
Date: Mon, 16 Feb 1998 22:03:16 +0900 (JST)

On Thu, 12 Feb 1998 10:24:21 -0800 (PST)
>   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?

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

Akihiro Shimura

On Thu, 12 Feb 1998 10:24:21 -0800 (PST)