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

From: "Atsushi Nakamura" <[email-masked]>
Date: Tue, 24 Feb 1998 00:13:51 +0900

Greg, and all

Though I think this is good effort,
my impression of the list is that it doesn't
look too different from the requirement list
we have been discussing for the past several months.

I think ANY (good) transport protocol would support
most of the items listed in the cheat sheet section one way
or another, thus look alike if you compare it this way.
SBP-2 and Thin are both good transports because they
both support the list of requirements !
I don't think one is better, or worse than the other.

I think it is HOW each protocol supports an item
that make the difference, not WHAT they support.

This relates to the thinking behind the development of each
protocol and the intended applications or solutions.
If each one(SBP-2, thin) has their benifits, and people see the
benifits, (which I think is the situation now )
we don't necessarily HAVE TO decide the ONLY one just now.

( After all, the thin transport is only  a few kilo-bytes....
  No big deal to add a few more KB to 30(?)KB of SBP-2 ? (^^;)
  Just joking ! )

Ats,

-------------------------------------------------------
Ats Nakamura
BJ Printing Technology Development 22
Canon Inc.

-----Original Message-----
·ol : Greg Shue <[email-masked]>
ˆ¶æ : [email-masked] <[email-masked]>
CC : [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
“úŽž : 1998”N2ŒŽ21“ú 9:49
Œ–¼ : P1394> SBP-2 vs. DPP 0.71 Cheat Sheet (?)

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