On Wed, 18 Feb 98 08:49:57 +0900
Greg Shue <gregs@sdd.hp.com> wrote:
>
> > 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.
>
> 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.
>
> > 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.
>
> 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).
>
> > 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.
>
> 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.
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 Connect sequence exactly mirrors an SBP-2 login (w/ command-set
> specific data).
> The Disconnect sequence exactly mirrors SBP-2 logout.
I guess reconnect may be very similar.
> 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.
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 Thin protocol requires both nodes to make memory available to
> 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 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.
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?
> Section 5.7.2 Command, clearly talks about a master/slave paradigm
> 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.)
> DPP is missing:
>
> - 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.
> It also requires devices to support at least a 12 quadlet block write
> instead of an 8 quadlet block write.
>
> > 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?
>
> 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
>
> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division gregs@sdd.hp.com
> ----------------------------------------------------------------
>
Toru Ueda
Sharp Corporation
Software Labs.