As is too often the case, we seemed to have narrowed our focus only on
printing, when several members of both PWG and PWG-C produce peripherals
for which printing is only ONE function; and we DON'T want a separate
transport and datalink layer for every application we come up with. The
most common type of peripheral that provides more than just printing is
the multifunction fax, scan, and print device. In this scenario, in
which the scan and fax can theoretically operate independently of a
"host", its not hard to see where the peripheral might want to initiate
a connection to some other device (could be a PC, but might be something
else). This would typically mean the device just received a fax and
wants to transfer the contents of the fax (possibly post-OCR) to some
other device on the 1394 bus. Likewise, at any time, someone might walk
up to a networked digital copier/printer and scan something. The user
interface on the device may have given the user the ability to direct
this scanned image to some other device on the 1394 bus.
In both fax and scan scenarios I have presented, the peripheral wants to
initiate the connection to some other device on the 1394 bus. Sure, its
possible to design this system to use an initiator / target model,
wherein the PC ALWAYS has connections to both fax and scan "logical
units" and is ready to receive data, but we should no way preclude the
design of systems that truly want to support "peer" transport
capability.
In the 1284.x working groups we were "electrically" bound to support the
single-initiator model, and we talked about some rather elaborate means
for simulating peer-to-peer capability for 1284.4. Let me emphasize the
word "simulating" because basically we were faking it at the datalink
layer. In the 1284 scenario, because of the nature of our underlying
physical layer, we were on fairly firm technical grounds for proposing
peer-to-peer simulation at some layer in the stack. However, in my
opinion, looking at the 1394 physical layer, I have seen NO technical
ground to justify implementing a single-initiator transport for what
will be the only alternative to TCP/IP on the 1394 bus (I hope).
Let me also say that my convictions with regard to symmetry do not
necessarily preclude the use of SBP-2. In my earlier mail messages,
which have been echoed in the last week by Greg Shue and (I think) Alan
Berkema, we can achieve the symmetry that we would all like to see by
requiring "compliant" devices to support both initiator and target
SBP-2.
However, we also may be able to use the "thin" transport design being
proposed by the PWG-C. Personally, I would like to see a detailed
side-by-side analysis of an SBP-2 (both initiator and target)
implementation and the PWG-C "thin" stack implementation. I have a
hunch, like Greg Shue stated earlier, that the actual implementation
differences between the two will be minor, in both code size and RAM
requirements. But this is just a hunch until I see more data on this
subject.
Randy
(Just my additional $0.02)
-----Original Message-----
From: Eric Anderson [SMTP:ewa at apple.com]
Sent: Tuesday, February 17, 1998 3:11 PM
To: p1394 at pwg.org; pp1394 at cpdc.canon.co.jp
Subject: Re: P1394> Print Protocols
> So, from attempting to follow the discussion it seems to me
that we have.
>
...
>
> 3) SBP-2 over 1394.
>
> Has merit. Good native 1394 solution that takes advantage of
1394's
memory
> address capabilities and works well with descriptor based DMA.
>
> If PC nodes only want to be Initiators we don't have a
symmetric
solution.
> I think we can make it work, though, I am concerned that non
PC peers
that
> implement both Target/Initiator functions would need to
communicate with
> each other in a different way than when they communicate with
a PC?
I still believe this is the way to go. I'd like to clarify one
point and then ask a question:
Symmetry: You are all correct that the peer-to-peer nature of
1394 favors symmetry. For example, we'd like to have a scanner
send an image straight to a printer (less work for us OS
folks!).
SBP-2 is not symmetric - it is an initiator/target model. What
I would like to clarify is that this is not automatically a
problem. In any particular session, we can define roles of
initiator and target, even between devices that are peers. I
would suggest that generally whatever device has initiated the
operation is the initiator (simple, huh?). In the
scanner-printer
case, probably we pressed a button on the scanner to cause it to
print the image. So the scanner is the initiator in this case.
By the way, Apple does plan to support SBP-2 target functions in
Mac OS. We see SBP-2 as a good way for two computers on 1394 to
talk to each other. We also want to emulate a 1394 printer so
that the 1394 scanner can print to a legacy device (through us).
Now the question: I understand that printing is not a purely
one-way communication. The printer may need to communicate
various
information back to the iniator during a print job. This need
led
to much of the 1284.4-over-SBP-2 work, as far as I can tell.
But
I have never seen a careful explanation of exactly what need
exists.
If reverse-flow communication is used only rarely, then we can
use
a slow, awkward mechanism for it, as long as we don't slow down
the
primary forward-flow data communicatin. If reverse-flow
communication is used a lot, then maybe we need a more symmetric
transport. But my guess is that reverse-flow communication is
much
smaller and less frequent than forward-flow communication. So
adding all the overhead of the 1284.4 credit-based transfer does
not pay off, because we don't need that for the forward-flow
data.
So, when do we need printer-initiated data flow back to the
host?
Error conditions are one obvious case. But errors are rare.
Job
setup is the other obvious case. We might negotiate a bit with
the printer before we start printing. But that happens only
once
at the start of a job, not during active data transfer. Is
there
any other reverse dataflow that matters? If we can limit the
reverse data flow to error reporting, light status reporting,
and
setup, then perhaps it's OK to use SBP-2 in a clumsy way for
this,
leaving the normal dataflow to happen quickly and efficiently
(in
SBP-2).
> 4) DPP over 1394.
>
> Sounds good. I have not seen enough of the detailed mechanism
to
determine
> if it delivers (I need to learn more about DPP). Did receive
some
comments
> at the TA about totally inventing a new mechanism instead of
reusing
> existing protocols, though it could be the right answer.
As Greg wrote, my view of DPP is that it is almost as complex as
SBP-2, but less well documented, and it has holes such as flow
control. When these things are all fixed, we essentially have
another SBP-2 (an incompatible one). Also DPP was very
expensive
on the host side, with lots of CPU-driven polling and
transmission,
rather than the passive SBP-2 model where the printer just reads
data out of our memory.
> 5) TCP/IP over 1394.
>
> I think this is a given. (IP happens). This could give us
printing
similar
> to the way it works today, as well as all the new internet
possibilities.
> Address administration and configuration, (DNS and DHCP and
others as
> Michael points out), make a full implementation larger than
some devices
> might like. Not sure of the use model?
I also agree that IP-1394 will happen. However, this is a low-
performance solution, because a lot of host software work is
required to send and receive IP, and the flow control does
not map well to printing and 1394. Furthermore, this does
nothing
for isochronous printing. The value of IP-1394 is in
compatibility,
not performance. The shared-memory services of 1394 are lost
with
IP, as far as I can tell.
> Conclusions?
>
> Alan