If we want to keep the application programming interface consistent
across all different kind of link types, then I think a socket interface
is the best way to do this. Note that this application interface only
provides access to a "transport" stack. The actual application protocol
used (DPP, IPP, 1284.1, etc.) would still be done by the application.
And if we want to use a socket interface as the common transport
interface for applications, this socket interface would support all of
the layering models that have been proposed thus far, including, but not
limited to:
1284.4 over SBP-2
SBP-2 over transaction layer (OHCI,
etc.)
1284.4 over 1284.3
TCP/IP over ethernet
TCP/IP over 1394
Note that the SBP-2 over transaction layer option would also support DPP
over socket interface as well.
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.
Randy
-----Original Message-----
From: Nagasaka Fumio [SMTP:Nagasaka.Fumio at exc.epson.co.jp]
Sent: Friday, February 13, 1998 4:47 AM
To: Greg Shue; Larry Stein
Cc: p1394 at pwg.org; P1284_3 at lexmark.com; PWG-C mailing
Subject: RE: P1394> 1284.4 over SBP-2
Hi Greg,
Your opinion persuade me 95%,? I like your opinion.
However I could not agree these points.
Greg Shue wrote:
<<
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 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?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111, Fax +81 268 25 4627
E-mail to nagasaka.fumio at exc.epson.co.jp
-----Original Message-----
From: Greg Shue [SMTP:gregs at sdd.hp.com]
Sent: Wednesday, February 11, 1998 12:21 PM
To: Larry Stein
Cc: p1394 at pwg.org; P1284_3 at lexmark.com
Subject: Re: P1394> 1284.4 over SBP-2
> I await your responses.
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 at sdd.hp.com
----------------------------------------------------------------