OK, here we go...
Larry Stein wrote:
> 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.
>
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.
> 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.
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 gregs@sdd.hp.com ----------------------------------------------------------------