Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes

From: Stephen Holmstead <[email-masked]>
Date: Fri, 13 Feb 1998 20:58:39 -0700

I agree with Toru that we NEED a symmetrical transport.  I really don't
care which option (A or B) is used, as long as we can provide a
symmetrical connection.  In fact, that was one of the PWG transport
requirements from that start, but it just seems that we have accepted a
transport (SBP-2) that isn't symmetrical and we are calling it good.
The PWG-C also needs a symmetrical transport.  I would love to have the
same transport for the PWG and PWG-C (since they both have the same
requirements).  I would HATE to have to make a printer that implemented
two different transports for PWG and PWG-C printing.  I think most
printer manufacturers would agree.

Greg Shue said that he made a proposal to the January PWG that would
extend SBP-2 so that it was symmetrical (at least that is what I
understand--I may be way off here).  If so, that would be great.  I have
not been able to find any minutes from the PWG since Dec 97 (anyone got
some?).

1394 could really use a commonly accepted symmetrical transport layer.
If that's 1284.4, great.  If that's a modified SBP-2, great.  If that's
TCP/IP, great.  If that's DPP's Thin Protocol, great.

Personally, I am biased towards IP or 1284.4 (if you couldn't tell).

Stephen Holmstead

> -----Original Message-----
> From:	Toru Ueda [SMTP:[email-masked]]
> Sent:	Friday, February 13, 1998 5:45 AM
> To:	Turner, Randy
> Cc:	'Stephen Holmstead'; 'Brian Batchelder'; [email-masked]
> Subject:	Re[2]: P1394> Rough SBP-2 & IP1394 core component ROM
> sizes
> 
> 
> I don't want to make any confusion about PC printing protocol. This is
> only for your information.
> 
> >From consumer device point of view, "symmetrical" is the essential
> feature of the protocol.
> For example, a digital still camera wants to send its image data to
> printers.  Also the same camera wants to receive image data from the 
> other still cameras. We want to use the same protocol for both use.
> 
> These are three essential features for consumer device.
> 
> 1) Bi-directional
>   Each side can send and receive data.
>   SBP2 supports bi-directional feature.
>   
> 2) "True" bi-directional
>   Each side can send and receive data at any time.
>   Alan's architecture supports "true" bi-directional feature by using
>   transmit buffer, receive buffer and unsolicited status.
>   
> 3) Symmetrical
>   Each side has the same architecture.
>   This is completely different from bi-directional issue.
>   
> Consumer device needs these three features and the protocol must be
> simple.
> 
> If SBP2 implementation needs 30K for initiator and target, it might be
> difficult to use it for consumer device.
> 
> Toru Ueda
> Software labs.
> Sharp Corp.
> 
> On Wed, 11 Feb 1998 08:35:10 -0800
> "Turner, Randy" <[email-masked]> wrote:
> 
> > 
> > 
> > I didn't know chip sets offered "explicit" support for SBP-2. OHCI
> > maybe, but I hadn't seen the chip set feature in the brochure for
> > "chip-level SBP-2 support".
> > 
> > Also, since 1394 is a peer-to-peer interface, anyone developing a
> > peer-to-peer device (like the majority of the Japanese electronics
> > industry), would have to essentially duplicate the functionality of
> > SBP-2 initiator and target, whether they actually use SBP-2 to do
> this,
> > or some other (potentially proprietary) method for implementing
> > peer-to-peer functionality.
> > 
> > Randy
> > 
> > 
> > 
> > 	-----Original Message-----
> > 	From:	Stephen Homestead [SMTP:[email-masked]]
> > 	Sent:	Wednesday, February 11, 1998 8:30 AM
> > 	To:	'Turner, Randy'; 'Brian Batchelder'; [email-masked]
> > 	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> > ROM sizes
> > 
> > 	My experiences in the past is that combining target AND
> > initiator
> > 	functions into a single device is VERY difficult.  The
> > complexity of the
> > 	state tables and ambiguities that can arise make it very
> > difficult.
> > 	Also, I don't believe any of the chip manufacturers support
> > SBP-2 for
> > 	both target and initiator.  In my opinion, it's NOT just a
> > matter of
> > 	adding the 15K for the target and 15K for the initiator.  The
> > target and
> > 	initiator have vastly different functions.   Designing a model
> > that did
> > 	both (well) would be a challenge.  It was problems like this
> > that fueled
> > 	many of the AEN (asynchronous event notification) debates.
> > 
> > 	Stephen
> > 
> > 	> -----Original Message-----
> > 	> From:	Turner, Randy [SMTP:[email-masked]]
> > 	> Sent:	Monday, February 09, 1998 1:03 PM
> > 	> To:	'Brian Batchelder'; [email-masked]
> > 	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> > ROM sizes
> > 	> 
> > 	> 
> > 	> I am very interested in the combined target/initiator
> > footprint as
> > 	> well.
> > 	> 
> > 	> Thx
> > 	> 
> > 	> Randy
> > 	> 
> > 	> 
> > 	> 	-----Original Message-----
> > 	> 	From:	Brian Batchelder [SMTP:[email-masked]]
> > 	> 	Sent:	Monday, February 09, 1998 9:37 AM
> > 	> 	To:	[email-masked]
> > 	> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core
> > component
> > 	> ROM sizes
> > 	> 
> > 	> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> > 	> 
> > 	> 	[snip]
> > 	> 
> > 	> 	>I approached them about sharing some rough estimates of
> > code
> > 	> size
> > 	> 	>for the IP1394 glue, SBP-2 target and initiator, and
> > 1394 bus
> > 	> 	>manager modules to get a feel for how "heavy" the
> > protocol
> > 	> 	>implementations really are.  They graciously shared the
> > flowing
> > 	> 	>estimates with us, and certainly deserve our thanks.
> > Since the
> > 	> 	>technology is still being developed, these
> > implementations are
> > 	> 	>certainly going to be tuned and the numbers will change
> > a
> > 	> little
> > 	> 	>bit.
> > 	> 	>
> > 	> 	>  Component                Rough ROM size (KBytes)
> > 	> 	>  ---------                -----------------------
> > 	> 	>  SBP-2 initiator core     15 +/- 5
> > 	> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch
> > agent,
> > 	> no exec agent)
> > 	> 
> > 	> 	Any idea how big a combined SBP-2 target/initiator would
> > be?
> > 	> 15-30K? ;-)
> > 	> 
> > 	> 	[snip]
> > 	> 
> > 	> 	Brian
> > 	> 
> > 	>
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 	> ~
> > 	> 	Brian Batchelder      | Hewlett-Packard      |
> > 	> mailto:[email-masked]  
> > 	> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone:
> > (360)
> > 	> 212-4107  
> > 	> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:
> > (360)
> > 	> 212-4227
> >

---

From: "Michael D. Johas Teener - CTO & CoB, Zayante, Inc" <[email-masked]>
Date: Mon, 16 Feb 1998 09:14:09 -0800

>Personally, I am biased towards IP or 1284.4 (if you couldn't tell).

I would also like to see a commonly accepted symmetrical transport layer
... but I have problems with what are currently called "IP" and "1284.4" ...

1) (the simpler one) 1284.4 was designed, if I understand correctly, as a
transport that would run across a variety of links, some with rather
restrictive natures (i.e., 1284 parallel port, minimal options) ... so
1284.4 on top of 1394 is a little bit like running the rts-cts serial port
protocol on top of IP (and I've see *that* done, too).

2) IP is a fine, well tested, and (in the form of v6) fairly simple network
protocol ... it is *not*, however, a transport protocol ... you still need
TCP on top of IP to get reliable two way communication. So you really need
TCP/IP ... and then you need to learn the IP addresses, so you need the
full IP address locating protocols of interest (DNS, maybe DHCP ....).
Which is fine if you already have it, but ....

1394 already has all the infrastructure in the local environment that is
needed. All that is needed is the transport itself. A paired SBP-2
initiator/target may provide this function, as may the "thin" transport
proposed by the PWG-C, as may a version of the transport being proposed by
IP1394. Before you get too excited about using 1284.4, or even pure IP,
take a look at the conversations in the IP1394 group. I suspect that you
will find it enlightening, if a bit frustrating.

The key is looking to *throw away* a protocol or layer ... don't add a new one.

===========================================================================
Michael D. Johas Teener, Chief Technical Officer & Chairman of the Board
Zayante, Inc., 269 Mt. Hermon Rd. #111, Scotts Valley, CA 95066-4000, USA
email: [email-masked]    voice: +1-408-461-4901   fax: +1-408-461-1394
======================== http://www.zayante.com ===========================