P1394 Mail Archive: RE: P1394> Print Protocols

P1394 Mail Archive: RE: P1394> Print Protocols

RE: P1394> Print Protocols

Turner, Randy (rturner@sharplabs.com)
Wed, 18 Feb 1998 01:01:11 -0800

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

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

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

(Just my additional $0.02)

-----Original Message-----
From: Eric Anderson [SMTP:ewa@apple.com]
Sent: Tuesday, February 17, 1998 3:11 PM
To: p1394@pwg.org; pp1394@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
> address capabilities and works well with descriptor based DMA.
> If PC nodes only want to be Initiators we don't have a
> I think we can make it work, though, I am concerned that non
PC peers
> 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
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
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
information back to the iniator during a print job. This need
to much of the 1284.4-over-SBP-2 work, as far as I can tell.
I have never seen a careful explanation of exactly what need
If reverse-flow communication is used only rarely, then we can
a slow, awkward mechanism for it, as long as we don't slow down
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
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

So, when do we need printer-initiated data flow back to the
Error conditions are one obvious case. But errors are rare.
setup is the other obvious case. We might negotiate a bit with
the printer before we start printing. But that happens only
at the start of a job, not during active data transfer. Is
any other reverse dataflow that matters? If we can limit the
reverse data flow to error reporting, light status reporting,
setup, then perhaps it's OK to use SBP-2 in a clumsy way for
leaving the normal dataflow to happen quickly and efficiently

> 4) DPP over 1394.
> Sounds good. I have not seen enough of the detailed mechanism
> if it delivers (I need to learn more about DPP). Did receive
> at the TA about totally inventing a new mechanism instead of
> 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
on the host side, with lots of CPU-driven polling and
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
> to the way it works today, as well as all the new internet

> 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
for isochronous printing. The value of IP-1394 is in
not performance. The shared-memory services of 1394 are lost
IP, as far as I can tell.

> Conclusions?
> Alan