Subject: Re: P1394> Print Protocols

From: "Eric Anderson" <[email-masked]>
Date: 17 Feb 98 23:11:12 +0000

> 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

---

From: "Michael D. Johas Teener - CTO & CoB, Zayante, Inc" <[email-masked]>
Date: Thu, 19 Feb 1998 10:54:19 -0800

Eric, Greg, Brian ...

I really like the way this discussion is shaping up, but I have one small
comment on the following:

At 3:11 PM -0800 2/17/98, Eric Anderson wrote:
>I

Actually, I think it is a bit more complicated.

1) In SBP-2, most of the pacing (flow control) is done by the target (it's
the target that fetches the ORBs and decides exactly when to do the data
transfer), it is best for the device that has the most constraints on
timing to be the target. It's a toss-up between a scanner and a printer,
but between a CPU and a printer *or* a scanner, it's the CPU that has the
most relaxed timing, so it should be the initiator.

2) Devices that have a natural memory model (CPUs come to mind) should be
initiators, since that allows them to implement a simple bus bridge
function to support the target read and write operations directly, without
software intervention.

===========================================================================
Michael D. Johas Teener, Chief Technical Officer & Chairman of the Board
Zayante, Inc., 269 Mt. Hermon Rd. #111, Scotts Valley, CA 95066-4000, USA
email: [email-masked]    voice: +1-408-461-4901   fax: +1-408-461-1394
======================== http://www.zayante.com ===========================

---

From: Greg Shue <[email-masked]>
Date: Thu, 19 Feb 1998 11:44:22 -0800 (PST)

> most relaxed timing, so it should be the initiator.

"Actually, I think it is a bit more complicated."

Flow control:
  If "flow control" refers to the scheduling of bus transactions to
  process a task, then I agree it is done by the (target's) fetch
  agent.
  
  If "flow control" refers to the presentation of the task requests
  (ORBs) and shared memory space then it is managed the initiator,
  since we're talking about one task request (ORB) referring to one
  "packet" transfer.
  
  If "flow control" refers to the policy for availability of the
  shared memory space for doing transactions, then it's shared between
  the target and the initiator (depending on the direction of data flow).

I still prefer Eric's proposal that whatever device has initiated
the operation is the initiator.  It avoids having to have the
connected-to devices from polling the want-to-connect devices to
figure out when the connection needs to happen.  That's much more
wasteful of processing power and bus bandwidth than providing
target functionality on a PC and using it only when appropriate.

Besides, who said we had to use the same SBP-2 device profile
for PC printing and "peer-to-peer" printing?

> function to support the target read and write operations directly, without

"Silly me, I thought that any device driven by a CPU (whether a PC
or embedded device) has a natural memory model."

I guess that you mean devices which effeciently support memory
accesses from other 1394 notes should be initiators.  No, that
doesn't sound quite right either.  How about:

  Devices which cannot provide timely scheduling of 1394 transactions
  should not be driving fetch agents?

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

---

From: Jack Hollins x2309 <[email-masked]>
Date: Thu, 19 Feb 1998 12:21:42 -0800

See embedded comment below

>   since we're talking about one task request (ORB) referring to one

Actually a single ORB can point to a data buffer which is larger than the
maximumlegal 1394 packet transfer size.  Therefore multiple data packet
transfers can be
caused by one ORB.

>   should not be driving fetch agents?

Jack Hollins
ASIC Architect
Adaptec

---

From: Greg Shue <[email-masked]>
Date: Thu, 19 Feb 1998 12:40:32 -0800 (PST)

> maximumlegal 1394 packet transfer size.  Therefore multiple data packet

Ah, another case of overloaded terms.  Yes, an ORB can refer to
a much larger data buffer than the maximum possible MTU of the bus.
This results in many MTU transfers per ORB.  Thanks for keeping me
honest and consistent.

I was using "packet" with respect to the transaction layer.
I was thinking of the case where a 10 MByte print job is consumed by
a device with 1 MByte of buffer space, and the flow of data into the
1 MByte buffer space must be controlled.  In this case I was thinking
that ORBs with 0.5 MByte to 1 MByte data blocks would be reasonable.

---

From: Jack Hollins x2309 <[email-masked]>
Date: Thu, 19 Feb 1998 15:57:32 -0800

> that ORBs with 0.5 MByte to 1 MByte data blocks would be reasonable.

Actually the initiator does not need to be aware of buffer limitations of the
targetin regards to the initiator sizing the data buffers associated with an
ORB.  A target
is under complete control of the consumption rate once an ORB has been put in
the
initiator's linked list (assuming linked lists are used) or if the ORB pointer
CSR is
written in the non-linked list case.  This allows  different target
architecture
performance/cost tradeoffs to be made without impacting an initiator.  A more
cost
sensitive target might have a smaller buffer space than a higher performance
target.

Jack Hollins
ASIC Architect
Adaptec

---

From: Greg Shue <[email-masked]>
Date: Thu, 19 Feb 1998 16:57:18 -0800 (PST)

> sensitive target might have a smaller buffer space than a higher performance

This is true if the tasks being processed by the target are
idempotent.  (In other words, that they may be executed one or
more times and end up with exactly the same result.)  This
feature is needed to support the following situation:

  - a task to be partially processed
  - a Bus Reset to occur (which implicitly aborts the task)
  - the task requeued on the list
  - the task completely restarted
  
I think this is an inheirent attribute of mass storage commands.
Unfortunately, printers are not.

Sending a set of commands which are larger than the printer can
buffer forces the printer to process some commands before they
are all received.  If a Bus Reset occurs, then either the printer
must validate that the same ORB was requeued and try to resume
from the last valid offset fetched, OR the protocol can guarantee
that the ORB's data block has been completely transferred before
the data is processed.  The first case is difficult at best, the
second is easy and provides idempotency at the cost of
negotiating the maximum sizes of the data blocks referenced by
the ORBs.

So, it's easier for the initiator to be aware of the transport
packet sizes supportable by the target than it is to work around
the Bus Reset problem by another mechanism.  If you have a better
suggestion, I'll certainly consider it.

"Need" is relative to the context.  In this thread, we're talking
about using SBP-2 for printing services.

---

From: "Michael D. Johas Teener - CTO & CoB, Zayante, Inc" <[email-masked]>
Date: Fri, 20 Feb 1998 10:26:39 -0800

Very good wording ...