Subject: Re: [PP1394:00177] RE: P1394> Print Protocols

From: Atsushi_Nakamura <[email-masked]>
Date: Wed, 18 Feb 1998 09:42:03 +0900

1 clarifiaction, and 1 comment.

Stephen wrote ;

> 4)  DPP is not a transport layer.  The Thin Protocol (defined in the DPP

> spec) that sits BELOW DPP is a transport layer.  I like Thin Protocol.

> It's very lightweight.  I don't think anybody could complain about

> adding the code to implement Thin Protocol.  It doesn't provide multiple

> channels, but it does do segmentation/reassembly.  It provides a very

> generic and simple "stream" transport.

DPP(Direct Print Protocol) =

  Thin Protocol (transport) + DPP Command Set(application cmd set)

(DPP is the name for both the transport and command set.)

Everything else you mentioned is correct.

Brian wrote;

>>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.

>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.

I ,one of the proposing side of DPP also agree with everyone's concern.

However, we are not adding 10 more protocols, just ONE more.

AV/C+FCP(current) :most suited for isochronous data  

SBP-2                  :most suited for asynchronous pull

Thin would cover what would be missing :

thin transport         :most suited for symmetrical asynchronous "push"  

                           (connection-oriented)

"most suited", of course is MY observation, there may be other opinions,

but I assume Thin, with IP1394 would cover (almost) everthing.

P.S.

Of course I assume everyone would agree that the DPP application command set

is required for direct-printing, but that is out of the scope of this discussion.

-----------------------------------------

<bigger>Atsushi Nakamura

</bigger>-----------------------------------------

BJ Technology Develpoment 22,

Canon Inc.

53 Imai Kami-cho

Nakahara-Ku, Kawasaki-shi

postal no. 211

tel:+81-3-44-733-6111(ext.5593)

    +81-3-44-739-6634(direct)

fax:+81-3-44-739-6756

email(1):[email-masked]

email(2):[email-masked]

-----------------------------------------

---

From: Stephen Holmstead <[email-masked]>
Date: Tue, 17 Feb 1998 18:02:10 -0700

Greg Shue wrote:
>If the applications which run above the transport are not
>peer-to-peer in and of themselves, then there is no NEED for the
>transport to really be peer-to-peer (though it doesn't hurt).

I need peer to peer.  PWG-C needs peer to peer.  I don't think it would
be incredibly intelligent to eliminate a feature of 1394 by a
restriction of the transport layer.

>I have just reread the DPP proposal, and it strikes me as equivalent
>to SBP-2.

I agree; it is similar.  The major difference is that Thin Protocol
provides a SYMMETRICAL connection.

>  The Connect sequence exactly mirrors an SBP-2 login (w/ command-set
>    specific data).

Also, either end can initiate the connect.  In SBP-2, the initiator logs
in with the target.

>  The Disconnect sequence exactly mirrors SBP-2 logout.
>  The Reconnect sequence is similar to the SBP-2 reconnect sequence,
>    though it's not specified which end is supposed to attempt the
>    reconnect and what happens if both try it simultaneously.  Also,
>    the reconnect window has been doubled from SBP-2.
>  The Thin protocol requires both nodes to make memory available to
>    the 1394 address space, instead of SBP-2's policy of initiator
only.

This allows for  the symmetrical connection missing from SBP-2.

>  The Thin protocol does explicit segmentation and reassembly.
>    SBP-2 does implicit segmentation and reassembly (it uses the
>    naturally available 1394 address ranges).
>  The Abort mechanism is provided by both.

>  Section 5.7.2 Command, clearly talks about a master/slave paradigm
>    in the two bullets spelling out the transfer sequences.

Yes, but it allows either end to issue commands.  In SBP-2, only the
initiator can issue commands.

>DPP is missing:
>  - flow control

Yes, but can be added at a higher level in the OSI model.  Many
transport layers do not provide flow control.  This is not a requirement
for my application.  Some "command sets" implicitly control pacing of
data.

>  - multiple logical channels

I don't recall reading how SBP-2 provides multiple logical channels
either.

>  - info about how this fits into a Unit Architecture

I don't recall the PWG having a "Unit Architecture" requirement.  This
may be a feature of SBP-2, but I wasn't listed as a requirement for the
PWG.

>  - Actual command definitions

This is not actually part of the OSI transport layer.

>  - error detection/reporting

I agree with this one, but I would word it slightly differently.  Thin
protocol does not provide a "reliable" connection.  However, the 1394
link layer does provide reliabilty on an MTU basis, so all that would
have to be added would be a reconnection mechanism to handle transient
link failures (cable temporarily unplugged).

> I'll take SBP-2.  It's better defined, available, and probably
equivalent.

It is NOT equivalent.  SBP-2 doesn't provide symmetrical connections.
But hey, if you don't need symmetrical connections, use SBP-2 if that's
what you like.  I'm just saying that SBP-2 doesn't work for me.  It also
doesn't work for the PWG-C.  And from what I've heard over the last
couple days on this thread, it doesn't work for many of the PWG people
either.  In my mind, SBP-2 doesn't fit the bill as a standard 1394
transport layer protocol.

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

Stephen Holmstead
Hewlett Packard Information Appliance Operation

---

From: "Turner, Randy" <[email-masked]>
Date: 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
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:[email-masked]]
	Sent:	Tuesday, February 17, 1998 3:11 PM
	To:	[email-masked]; [email-masked]
	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 
	> 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