Subject: P1394> SBP-2 vs. DPP 0.71 Cheat Sheet (?)

From: Greg Shue <[email-masked]>
Date: Fri, 20 Feb 1998 16:46:07 -0800 (PST)

Hi all,

The more I look at DPP 0.71, the more similar it looks
to SBP-2.  So, I put together a concept "cheat sheet"
to see how the two really compared.  I thought you
might be interrested, so here it is...  What do you think?

- Greg Shue

===============================
SBP-2 vs. DPP v0.71 Cheat Sheet
===============================

There are many similar concepts between SBP-2 and DPP v0.71 which
may not be well understood.  The main difference between the
protocols revolves around the a/symmetry of the protocol stacks.
This "cheat sheet" is intended on laying the groundwork for a
direct comparison of the protocol stacks.

SBP-2 Model of Use for Comparison
---------------------------------
In order to get a reasonable comparison of the protocols, then
a Command Set and Model-of-use must be outlined for SBP-2.  Many
of the details can be left out of the outline as long as the
essence of the profile is maintained.

Model of Use
------------

  - cross-logins are established between the two devices.
      (This avoids a merged target/initiator driver)

  - each device provides a fetch engine and a task list.

  - each task list contains commands to transfer data in one direction
      (we'll choose it such that only WRITE transactions occur for
       moving the ORB data block)

  - each ORB allows one "data unit" to be processed.

Command Set Provides For
------------------------
  - cross-login information
  - negotiated max data block size per task per direction.
  - indicating byte-size of completed packet
  - carrying of Command IDs in CDB  (2 bytes)
  - carry "SDU segmentation number" in CDB  (4 bytes)
  - carry "SDU end of segment flag" in CDB  (1 bit)
  - carry routing info in CDB  (2 byte Dest PID, 2 bytes Src PID)

Cheat Sheet
===========

    CSR structures       Thin Protocol           SBP-2
    -----------------------------------------------------------------------
    Access Control i/f   Connection Reg          Mgmt Agent Reg

    Response Space       SDU Response Space      Fetch Agent Regs

    Completion status    SDU Control Space       Status FIFO

    Transfer block       SDU Register            data block referenced by ORB

    Functional layers    Thin Protocol           SBP-2
    -----------------------------------------------------------------------
    Connection mgmt      Thin Session            Management Agent

    Data Transfer eng    Thin Transaction        Fetch Agent

    Session Mgmt         Thin Protocol           SBP-2
    -----------------------------------------------------------------------
    Access Request       S_Connect               login

    Reconnect            T_Reconnect             reconnect

    Execute App Cmd      S_Command               ORB exists on task list

    Access Release       S_Disconnect            logout

    Error Notification   <none>                  Mgmt-ORB specified Status FIFO
						   completion notification

    Data Transfer        Thin Protocol           SBP-2
    -----------------------------------------------------------------------
    Transfer Space       SDUAck                  ORB exists on task list
      Available          (write implies avail)   (existance implies available)

    Transfer completion  SDUComp                 Notification write to
      notification                                 Status FIFO

    Transfer Abort from  SDUStop                 Abort Task (Set)
     data receiver

    Transfer Abort from  SDUStop                 Notification write to implicit
     data sender                                   Status FIFO - Abort

    Error Notification   T_error                 Notification write to implicit
						   Status FIFO - error ind.

Feature Comparison
==================

Feature                  Thin Protocol           SBP-2
-----------------------------------------------------------------------
Each node can send/rcv   Yes                     Yes
  data

Dynamically allocates    Yes                     Yes
  CSR Reg space when
  estab. connect

Selectable Transfer      Yes                     Yes, requires Create Stream
  Mode                                             request and separate
                                                   task list

Symmetric Structure      Yes                     Yes

Negotiated Data Unit     Yes                     Yes
  size independently
  per direction

Isochronous Support      Yes                     Yes

Multiple Cmd Support     Yes                     Yes

Bidirectional Cmds       Yes                     Yes

Multiple Independent     Unspecified (possible   Yes, via Multiple LUNs &
 Connection Support      w/ multiple UNIT Dirs)    multiple UNITS

Session segmentation     Yes                     Yes, in CDB
  support

Distinctive differences:

Feature                  Thin Protocol           SBP-2 w/ proposed profile
-----------------------------------------------------------------------
Reconnect Support        2 sec window;           1 sec window, proposal made
                         either end may          for programmable extension;
                         establish               both ends must reestablish

SDU Available            SDU Ack timeout exists  None (?)
  timeout                Does this imply a real-
                         time processing req. on
                         whatever data is sent
                         in an SDU?

Connection Process       2 block writes          6 block writes (probably)
                                                   (2 logins @ 2 per login,
                                                    2 for negotiated params)

Shared memory buffer     Fixed location during   Relocatable, partitionable
                         connection

Data Transfer            more efficient for      More flexible and standardized
                         data < MTU size

   data < MTU size       SDUAck +                WR Agent Reset + WR ORB ptr +
                         SDUComp +               ORB prefetch + data xfer +
                         SDUAck                  Completion Notify
                            (3 transactions vs. 5 transactions)

   MTU size << data <    SDUSend +               WR Agent Reset + WR ORB ptr +
   SDU size              SDUComp +               ORB prefetch + page table +
                                                 data xfer +
                         SDUAck                  Completion Notify
                            (SBP-2 costs 3 extra transactions,
                             but a small overhead

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

---

From: Toru Ueda <[email-masked]>
Date: Mon, 23 Feb 98 20:08:16 JST

Greg,

Thank you for your effort to make the comparison table.

I agree that DPP has similar functions with SBP2 if you use two SBP2s
with cross-logins.
I guess the reason you need two SBP2s for single print task and DPP
needs only one comes from the differences of the models.
Because SBP2 is host-target model, you needs two logins for one peer to
peer connection.

I don't say DPP is more suitable to any tasks or any printing tasks. I
just want to say DPP is being defined for Peer to Peer printing.

Also I prefer one application uses only one session. Of course some task
requires more than one session but at least for very simple print task
or file transfer task, I prefer small number of sessions.

model 1)
---------------
|  Application  |   This is better for consumer products than model 2.
----------------
| One Protocol  |
| or One session|
----------------

model 2)
------------------
| Application     |
------------------
| more protocols  |
| or more sessions|
------------------

Again I don't want compete with SBP2. SBP2 has more functions like ORB and natural flow control.

We are developing DPP and THIN protocol. The biggest priority for THIN
protocol is  the size and simplicity. I cannot explain the reason we
need two logins for simple print task to our product engineers. Also I
cannot explain the reason we need 20 or 30KB for print protocol, while
the file transfer protocol using IR(Infra-Red) communication (called Ir
TranP) needs only several Kilo bytes.

Toru Ueda
Sharp Corp.
Software Labs.

On Fri, 20 Feb 1998 16:46:07 -0800 (PST)