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 at sdd.hp.com
Stephen Holmstead
Hewlett Packard Information Appliance Operation