Subject: RE: P1394> Print Protocols

From: Stephen Holmstead <[email-masked]>
Date: Tue, 17 Feb 1998 15:54:55 -0700

Here's my opinion. 

1)  I agree that this option is dead.
2)  I think option 2 could work, but there is some political resistance
from the camera guys to adding 1284.4.  It's heavier than Thin Protocol
(Thin doesn't have multiple channels).  There would have to be a
definition of how 1284.4 sits on top of 1394, but I don't think that
there needs to be another layer between 1284.4 and 1394.
3)  I really don't like SBP-2.  SBP-2 is an EXCELLENT model for existing
storage devices.  It is NOT a good model for peer to peer devices.
Sure, the initiator/target model can be modified to have a target notify
the initiator that data is available, but it is kludgy.  Aborting the
task queue is an exceptable solution if your model is primarily single
direction data flow.  But in a peer to peer environment, the data
direction is going to switch a bunch.  That is just not an exceptable
design.  Bottom line, you can make initiator/target model do peer to
peer, but it won't do it well.
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.
5)  I would be happy with IP/1394.  It would allow us to have UDP and
TCP transport layers that are already familiar to many.  Unfortunately,
I think this option is viewed by many to be "heavy", but it doesn't have
to be.  I don't care about DHCP, DNS, and other administrative
protocols.  I just want the transport layer (UDP/TCP).  The real problem
here is that it's going to take a long time until committees decide what
IP/1394 is.  If we are in a rush, this option isn't it.

So, in summary, option 4 looks like the leader in my book.  Options 2
and 5 also have merit.  That's my opinion.  Anyone else?

Stephen Holmstead

> -----Original Message-----
> From:	[email-masked]
> [SMTP:[email-masked]]
> Sent:	Tuesday, February 17, 1998 3:15 PM
> To:	[email-masked]; [email-masked]
> Subject:	P1394> Print Protocols
> 
>      
> This was "RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes"
> however I figured it was time for a new name.
> 
> --------------------------
>      Ozay Oktay wrote:
>      I have been quietly monitoring this discussion on the reflector.
> So 
>      far this is the best analysis I have read.
>      
>      I agree with Brian almost entirely.. When preparing a standard we
> must 
>      look into the future. We could be accommodating but we should
> never be 
>      constricting for the sake of backward compatibility.
>      
>      Best Regards
>      
>      Ozay Oktay
>      Canon Information Systems
> -------------------------------
>      
> I will second that, good job Brian. 
> 
> So, from attempting to follow the discussion it seems to me that we
> have.
> 
> 1) 1284.4 over SBP-2 over 1394.
> 
> Rough consensus that this is not a great idea.
> 
> 2) 1284.4 over 1394.
> 
> I don't think this works by itself? We still need a layer that takes
> the 
> 1284.4 packet and puts it into a 1394 packet with a 1394 address. As
> Brian 
> and others have mentioned DFA does this, however, DFA does not handle
> out 
> of order, lost  or duplicate packets.
> 
> 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?
> 
> 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.
> 
> 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?
> 
> Conclusions?
> 
> 
> Alan

---

From: Greg Shue <[email-masked]>
Date: Tue, 17 Feb 1998 15:49:26 -0800 (PST)

> there needs to be another layer between 1284.4 and 1394.

Yes, there _does_ need to be a layer between 1284.4 and 1394.
This layer provides the functionality of _how_ 1284.4 sits on
top of 1394.  Specifically, it implements the Data Link layer
required by 1284.4.  This functionality is not directly provided
by 1394.  It must address the issues of access control, dynamically
changing topology, transient link interruptions, packetized transfers,
actual data transfer scheduling for each direction.  Not a trivial
piece of the puzzle.

> peer, but it won't do it well.

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

> generic and simple "stream" transport.

DPP Rev 0.71 has two distinct parts:  the DPP command set (which
lies above the transport), and the DPP transport stack (made up
of the "new" Thin Session, Thin Transaction, Isochronous, and
Asynchronous blocks).

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

  The Connect sequence exactly mirrors an SBP-2 login (w/ command-set
    specific data).
  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.
  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.

DPP is missing:

  - flow control
  - multiple logical channels
  - info about how this fits into a Unit Architecture
  - Actual command definitions
  - error detection/reporting

It also requires devices to support at least a 12 quadlet block write
instead of an 8 quadlet block write.

> and 5 also have merit.  That's my opinion.  Anyone else?

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

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

---

From: Toru Ueda <[email-masked]>
Date: Wed, 18 Feb 98 22:40:14 JST

I don't believe DPP is equivalent to SBP-2.
Please see below.

On Wed, 18 Feb 98 08:49:57 +0900

> I have just reread the DPP proposal, and it strikes me as equivalent

How can you measure the closeness of two protocols ?
I guess this is very difficult.

I believe most connection oriented protocols have Connect and Disconnect.
These functions are very similar.

>   The Disconnect sequence exactly mirrors SBP-2 logout.
I guess reconnect may be very similar.

>     the reconnect window has been doubled from SBP-2.

Both end can send reconnect request.
We don't have any problem if both end send reconnect simultaneously.
The end who wants to send data can issue reconnect request.
If the end who issues reconnect request receives reconnect request from
another end, this end shall send reconnect ack. This is described in
footnote of page 24.

>     the 1394 address space, instead of SBP-2's policy of initiator only.

This comes from basic concept of DPP.
DPP is designed as a symmetrical protocol. This is the reason why any
DPP nodes have to assign memory space.
The biggest feature of DPP is dynamic memory allocation.
If a high end printer has 16M byte memory in it, 16M byte can be
allocated for data buffer. This will reduce packet iteration.

For low end consumer device, several hundred byte for data buffer is
enough.

Even if it has a small memory, large data can be received.

>   The Abort mechanism is provided by both.

This also comes from basic concept of DPP.
DPP uses PUSH model. Sender node need to have the responsibility for
data segmentation.
I believe this model is very different from SBP2.
This is not an issue that which is good or bad. These models are very
different and each model has suitable applications.

If I understand SBP2 correctly, SBP2 needs segmentation when the node
has larger data than its local memory. Do I misunderstand this?

>     in the two bullets spelling out the transfer sequences.

It's not talking about master/slave. It's just talking a sender and
a responder.
This means each end can send and receive data in one connection. There
is no difference between two ends.
It might be unusual that one end sends and receive data in one
connection for printing function. However it is quit usual for typical
network applications including HTTP and FTP.
(These are not the scope of DPP though.)

>   - flow control
It's not true. We don't use sophisticated flow control like 1284.4 does.
However SDU ack means the next data can be sent. This may not be very
efficient but works. If the receiver node has another memory area for
next segmented data(for example memory bank), it can send ACK packet
immediately.

Also, if it has only one memory for received data, after processing(this
usually means printing) it can send ACK. ACK means next memory available
or I have only one credit.
If you need more sophisticated way of flow control, you can add 1284.4
or other flow control protocol on the top of THIN protocol.

>   - multiple logical channels
This is under discussion. Because each "Connect Request" assigns register
area for this specific connection, thin can support multiple login.
(Each login uses different register space.)
Also, to add channel number, it can support multiple logical channels.

The reason we are discussing about this is that we must select the
functionality very carefully. 

We know we can add sophisticated flow control or multiple logical
channels. However we don't want to develop SBP2 like protocol but
not-SBP2 protocol.
Our protocol for consumer devices should be very simple.
We have to decide which function should NOT be supported for consumer
products.

>   - info about how this fits into a Unit Architecture
I'm sorry but I cannot understand what does it mean.

>   - Actual command definitions
We are discussing about this. Current document has a lot of TBD command
definitions.

>   - error detection/reporting
Do you mention about application error?
If so, this is command level issue. This is under discussion.
Also any communication error should be indicated to upper layer.

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

I agree that you may add SBP2 initiator and target for PC or PC printer.
However we, as a consumer device manufacturer, cannot support both SBP2
initiator and target in $300 digital still camera.

If we choose 1284.4 over SBP2, it will require glue part between two.
If we need 1284.4 + glue + SBP2 for target and 1284.4 + glue + SBP2 for
initiator, I'm afraid that any consumer device can't support this.

I understand that 1284.4 and SBP2 are excellent protocols. 
The reason we don't want to use 1284.4 over SBP2 for our consumer
products is the model is quit different from our peer to peer, low cost
and symmetrical applications.

> > Stephen Holmstead

Toru Ueda
Sharp Corporation
Software Labs.