P1394 Mail Archive: RE: P1394> Print Protocols

RE: P1394> Print Protocols

Stephen Holmstead (stephen@hpb16977.boi.hp.com)
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 gregs@sdd.hp.com

Stephen Holmstead
Hewlett Packard Information Appliance Operation