Subject: P1394> Print Protocols

From: [email-masked]
Date: Tue, 17 Feb 1998 14:15:15 -0800

This was "RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes"
however I figured it was time for a new name.

--------------------------
     Ozay Oktay wrote:
     I have been quietly monitoring this discussion on the reflector. So 
     far this is the best analysis I have read.
     
     I agree with Brian almost entirely.. When preparing a standard we must 
     look into the future. We could be accommodating but we should never be 
     constricting for the sake of backward compatibility.
     
     Best Regards
     
     Ozay Oktay
     Canon Information Systems
-------------------------------
     
I will second that, good job Brian. 

So, from attempting to follow the discussion it seems to me that we have.

1) 1284.4 over SBP-2 over 1394.

Rough consensus that this is not a great idea.

2) 1284.4 over 1394.

I don't think this works by itself? We still need a layer that takes the 
1284.4 packet and puts it into a 1394 packet with a 1394 address. As Brian 
and others have mentioned DFA does this, however, DFA does not handle out 
of order, lost  or duplicate packets.

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?

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.

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?

Conclusions?

Alan

---

From: Brian Batchelder <[email-masked]>
Date: Tue, 17 Feb 1998 16:02:23 -0800

>however I figured it was time for a new name.

OK, stop it.  My head is getting too big.  ;-)

>of order, lost  or duplicate packets.

I assume that we could take DFA and add the functionality required to
handle out-of-order, lost and duplicate packets.  If we did that, we would
need to compare our solution to SBP-2 to make sure that we didn't end up
re-inventing it.  I've seen that happen all too often...

>each other in a different way than when they communicate with a PC?

I don't know if we should assume that PC-nodes will only be initiators,
even though George Chrysanthakopoulos at Microsoft indicated that PC
targets would not be supported.  I hope that we can change his mind by
showing him why PC targets are important.  BTW, I agree with him that
PC-connect devices could be implemented as targets, but, again, I would
prefer not to limit our future solutions in that way.

>existing protocols, though it could be the right answer.

I agree with the concerns of the TA.  Any protocols we specify MUST provide
solutions in a significantly better way than do the other available
protocols.  If they do not, companies will not implement our protocols, and
they will end up being a waste of time.  In addition, too many protocols
can confuse the industry and our customers, diluting the effect of the
primary ones.

>might like. Not sure of the use model?

IMHO, there will be at least two printing protocols for 1394, TCP/IP and
something else.  If TCP/IP and that something else can't solve the needs of
low-end image printing, parallel-port replacement printing and "network"
printing, then we will need three printing protocols.  No matter what we
end up choosing, my personal goal is that, a few years from now, our
protocols are in widespread use, providing strong value to our customers.
(Hey, maybe I have a career in Marketing ahead!)  ;-)

Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:[email-masked]  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

---

From: Greg Shue <[email-masked]>
Date: Tue, 17 Feb 1998 17:40:15 -0800 (PST)

Gee, so much discussion ...

Hitoshi Sekine writes:
> Saying just 1284.4 over SBP-2 may cause some confusions.  Have
> you described what is inefficient to stack overlapping
> functionality and tried to remove it from 1284.4 over SBP-2?  Is
> supporting socket interface included in the latest proposal?  If
> you have, I am sorry.  My manager didn't allow me to travel to
> Maui, however I loved to be there.  Can you update the latest
> status or a meeting memo in Maui?  I need catching up you.

[Greg Shue]
If anything is removed from 1284.4 or SBP-2 for a combined solution,
then the driver(s) for the protocol(s) affected cannot be used.
They are no longer the standard protocols.

The proposal I made at the January PWG meeting placed no requirements
or restrictions on the API.  Sockets may be supported.

Kazuhiro Hirata asks:
> Alan or Greg, why did you choose SBP-2 based profile rather than 1284.4
> at Jan. PWG?

[Greg Shue]
There are several reasons for choosing SBP-2 rather than 1284.4:

  1.  SBP-2 is defined and exists.
  2.  SBP-2 is preferred by Microsoft and Apple.
  3.  It already addresses the issue of access control and reconnect
  4.  The PWG already expressed preference against a 1284.4 only solution.
  5.  The Unit Architecture provides independent access to multiple services.
  6.  I wanted to prove to myself whether or not it was feasable!

Brian Batchelder writes:
> Actually, I am currently leaning towards SBP-2, but we must use
> it in a way that allows clients to be clients, servers to be
> servers, and both to exist on every device.  This probably means
> implementing both target and initiator (targiator) functionality
> on each device.  If the chip implementations available today
> don't optimally support targiators, well, we won't be optimal
> until they are fixed.  However, I was pleased to read Michael
> Teener's message in which he indicated that targiators should be
> quite possible.

[Greg Shue]
Good job Brian!

I agree that we must use SBP-2 in a way that allows clients to
be clients, and servers to be servers, and both to exist on
every device.

The coined terms "targitator" and "targiator" may get confusing
as they have been used slightly differently.  In one case it
refers to an transport connection composed of cross-SBP-2-logins.
The other case refers to a device which provides both SBP-2
initiator libraries and SBP-2 target libraries.

Good Job Michael!  I completely agree that any device should be
capable of support both SBP-2 initiator and SBP-2 target functionality.
The HW assists are not required.

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

---

From: Akihiro Shimura <[email-masked]>
Date: Wed, 18 Feb 1998 17:02:07 +0900 (JST)

I feel it will not be so uncomfortable to have more than one data
transport mechanism as far as;
  - each has its own benefit,
  - choosing one from them makes the benefit lost.
  - and they can co-exist well and they are consistent.
(Though developers may be uncomfortable.)

In PC-to-Device case, the PC resources like processor power need to be
efficiently shared with many other tasks.

SBP-2 is based on the "message passing/shared memory" model. The
shared memory function is provided by "bus" nature of 1394 and bridge
feature of OHCI style link. The message passing is done using
initiator's request queue (linked list of ORB's) and target's
response queue (status_FIFO) pair in the initiator's memory space.
Because the message passing does not require synchronization with the
target response, (i.e., the "initiator" PC can queue messages as far
as it has resource), SBP-2 will greatly reduce OS involvement (of
latency critical code) in I/O activities. Also bridge feature of OHCI
style link will free the CPU from shared memory accesses. So, SBP-2
"initiator" will efficiently share PC resources with other tasks while
achieving high bandwidth.
Furthermore, "target" device can de-queue the request messages at its
own pace. 

As described above, SBP-2 has a benefit when used as a (possibly
uni-directional) data path between "initiator" PC and "target" device.

Though it will be technically possible to make link peer-to-peer by
"targiator" approach with SBP-2 and it will work on various link
implementations, I think it will be too tough to require expensive
bridge hardware in any device to be "initiator" device. The device
will be cost sensitive with doing dedicated task as contrast with PC
to be general purpose.

Without bridge hardware, the SBP-2 will lose its appeal because
"message passing/shared memory" model is not optimized for packet
exchange on the wire due to its indirect buffer reference.

So, I think Device-to-Device (or peer-to-peer) other than SBP-2
"targiator" should also be addressed.

It may be good to make device-to-device framework that has an extra
SBP-2 data path for "PC-to-device" (or PC-to-PC) in it.

Akihiro Shimura

On Tue, 17 Feb 1998 17:40:15 -0800 (PST)

--
 Akihiro Shimura ([email-masked])
 Office Imaging Products Development Center 3
 CANON INC.