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

From: Stephen Holmstead <[email-masked]>
Date: Wed, 11 Feb 1998 09:29:55 -0700

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: Fumio Nagasaka <[email-masked]>
Date: Sat, 14 Feb 1998 10:14:04 +0900

Dear Mike,
Thanks for your productive information.

May I think your information results that the combined footprint
would be smaller than the sum of the SBP-2 initiator and SBP-2
target footprints?

Also I think SBP-2 is really well designed to support memory-
bus architecture provided by IEEE 1394. So if we adopt socket
stream API on SBP-2, I am afraid of that we might bring some
drawbacks from conventional I/O channel like architecture.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to [email-masked]

-----Original Message-----
From:	Michael D. Johas Teener - CTO & CoB, Zayante, Inc [SMTP:[email-masked]]
Sent:	Saturday, February 14, 1998 2:08 AM
To:	Nagasaka Fumio
Cc:	Stephen Holmstead; 'Turner, Randy'; 'Brian Batchelder'; [email-masked]; pp1394 ML
Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes

Regarding the note from Nagasaka Fumio:
>I agree with Stephen,
>> Also, I don’t believe any of the chip manufacturers support SBP-2
>>for
>both target and initiator.
>
>Do we need to develop a firmware which supports two LINK ICs
>one for initiator and one for target?
>I think “yes”. Because typical LINK IC has only one input
>FIFO in
>each chip. And it is very difficult to implement two different software
>stack utilizing one i/o channel.

1) All of the Pele-based designs (OpenHCI, among others) do an excellent
job as both initiator and target ... indeed, they can support an almost
unlimited number of simultaneous initiator and target contexts
simultaneously. They are, however, PCI bus master designs ... so unless you
are building a relatively high-end printer, they may not be in your price
range (but check with IC suppliers like Sony, Symbios, and FFM for Pele,
and virtually everyone about OpenHCI).

2) Sony has a fine SBP-2 target part that is also useful for initiator use,
but requires more software and external DMA interaction.

3) The number of input FIFOs is not too important, except as an
optimization, particularly when inbound bus bridging is provided (useful
for CPU-type initiators). The key is to have good receive DMA into the
controller memory.

4) 1394 is quite different from traditional "I/O channels" ... mainly
because it's really a memory bus. If you treat it correctly (as a memory
bus), then it is quite simple to implement multiple stacks using the same
hardware. Indeed, our own proto systems implement as many as 4 protocol
stacks using relatively primative hardware.

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

---

From: Fumio Nagasaka <[email-masked]>
Date: Sun, 15 Feb 1998 14:04:15 +0900

Dear Stephen,

Your opinion bring us back to December 1996. Actually we started from
this point. 

I would like to list up existing standards and some proposals here.

Transaction architecture:
------------------------------------------------------------------------------------------
IEEE 1394     |   Memory Bus
------------------------------------------------------------------------------------------
SBP-2         |   Memory Bus
DPP           |   Stream       (PWG-C / Toru Ueda)
TCP           |   Stream
DFA           |   Stream       (PWG / Alan C. Berkema)
1284.4         |   no definition
------------------------------------------------------------------------------------------

Transaction style:
------------------------------------------------------------------------------------------
IEEE 1394     |   push and pull,  symmetrical
------------------------------------------------------------------------------------------
SBP-2         |   pull
DPP           |   push,  symmetrical
TCP           |   push,  symmetrical (may implement passive open)
DFA           |   push,  symmetrical
1284.4         |   push control, symmetrical
------------------------------------------------------------------------------------------

Please correct if I had overlooked something or I am missing some points.

Stephen wrote:
<<
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.

No.
Due to some market reasons, printer manufactures are required
to support USB, conventional parallel port, 1394 and Macintosh serial
interface. However Digital Camera (one of typical consumer imaging
device) does not support parallel port. Thus for some consumer
device manufactures, it is meaning less to have a solution which
provide common protocol stack to cover various existing interface.

If PWG and PWG-C shall have same solution, I think we shall
have only one "Printer Working Group". However many Japanese
companies could not agree with this plan. They might have their own
reasons. And I think we ought to pay consideration for them.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to [email-masked]

-----Original Message-----
From:	Stephen Holmstead [SMTP:[email-masked]]
Sent:	Saturday, February 14, 1998 12:59 PM
To:	'Toru Ueda'; Turner, Randy
Cc:	'Stephen Holmstead'; 'Brian Batchelder'; [email-masked]
Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes

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

> 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
> > 
> > 
> > 
> > 	From:	Stephen Homestead [SMTP:[email-masked]]
> > 	Sent:	Wednesday, February 11, 1998 8:30 AM
> > 	To:	'Turner, Randy'; 'Brian Batchelder'; [email-masked]

---

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

>printer manufacturers would agree.

I think everyone would agree to this as an "ideal" solution.
Unfortunately. the reality (at least now) is that the PWG and PWG-C
have requirements that are "similar", but not the "same".
The difference may be small, but seem to be crutial to both sides.
It may be the "level",or depth of each requirement items, or
priority of requirement items (for example, "light", symmetrical VS,
existing
protocol use, OS support)

If we can come up with a PWG solutionthat can cover the difference, that
would be great. On the other hand, if the DPP thin transport can be used fro
PWG printing, that would be good too, and will be the ideal solution.

>, but it just seems that we have accepted a

I think so too. It's one of the reasons why I asked the whether we
ever officially decide to go with SBP-2...

There was still discussion  in Maui whether symmetrical (and/or
bi-directional)
was necessary or not for PWG printing. (must or want ?)
This is one of the questions we need to get consensus first , as well as
prioritizing the requirements. For example, if existing protocol use is much
more important for PWG printing than symmetric, SBP-2 may be good
after all.

-----Original Message-----
·ol : Stephen Holmstead <[email-masked]>
ˆ¶æ : 'Toru Ueda' <[email-masked]>; Turner, Randy
<[email-masked]>
CC : 'Stephen Holmstead' <[email-masked]>; 'Brian Batchelder'
<[email-masked]>; [email-masked] <[email-masked]>
“úŽž : 1998”N2ŒŽ14“ú 13:00
Œ–¼ : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes

---

From: Hitoshi Sekine <[email-masked]>
Date: Sun, 15 Feb 1998 14:17:50 -0800

I love a symmetrical transport also. PC Printing has supported 1284, USB and
1394 soon. If you considers a symmetrical transport for 1284, USB and 1394
(and IP), it will be great for us. To redesign PC software only for a new
1394 print transport will be tough. I don't mean to recommend different
solutions between PWG-C and PWG. We need to get our priorities right. Not to
confuse PC software industry is my first priority.

I personally understand that 1284.4 may be a bridge over those local
interfaces and familiar with an IP printer.

Hitoshi Sekine

> From:	Fumio Nagasaka [SMTP:[email-masked]]
> Sent:	Saturday, February 14, 1998 9:04 PM
> To:	'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
> Cc:	'Brian Batchelder'; [email-masked]; 'PWG-C mailing';
> [email-masked]'; Hitoshi Sekine

---

From: "Atsushi Nakamura" <[email-masked]>
Date: Mon, 16 Feb 1998 12:34:52 +0900

For PWG printing,
We will have to decide whether not we use 1284.4 or not,
but in any case, it is inefficient to stack overlapping
functionality.
My choices would be either :

1) 1284.4 - "glue"- 1394
2) "glue"or cmd set - SBP-2- 1394
3) "glue"or cmd set - other transport(thin?)-1394

I am yet uncertain which is the best( maybe 2) or 3) ),
but I DO have a opinion that in any case :
1284.4 over SBP-2
is not my choice, because in this case;

>Sure, SBP-2 was present, but only as a
>transport, and much of it's potential was wasted.

would happen. (same for 1284.4)
Is using 1284.4 our first priority, or is using SBP-2 our
first priority ? (or something else? )(or using both !?)

P.S I would like to refer to Eric's comment about the 1394 disks
      again.
>Recently, the 1394 community had the opportunity to define a
>storage protocol for 1394.  The first solution, Tailgate, gave
>us essentially an ATA interface bridged over 1394.  Both the
>target and the initiator had to operate as if traditional ATA
>was the interconnect.  Sure, SBP-2 was present, but only as a
>transport, and much of it's potential was wasted.  Tailgate
>was supposed to be quick an easy and lead to rapid market
>adoption.  What actually happened was quite different.

I think this is the same situation with 1284.4 (as ATA) and
SBP-2 (or IP,Thin.... )

>Microsoft and others realized that adopting this model would
>"lock in" ATA for a long time, including long after ATA itself
>was dead.  Emulating a dead technology with new technology may
>yield short-term savings in implementation, but at the expense of
>long-term losses in performance.  Amazingly, reason prevailed,
>and Tailgate was abandoned in favor of a pure SBP-2 protocol
>for disk drives.  As it turned out, Tailgate vendors quickly
>switched to Native Bridge, which still allowed today's drives
>to act like 1394 drives, by making them look (from a 1394
>point of view) like fully native devices.  As far as I can tell
>this switch was not too painful, and now we aren't stuck with
>ATA.  Everyone won.

Let's not repeat history....

-------------------------------------------------
Atsushi Nakamura
BJ Printing Technology 22
Canon Inc.
-------------------------------------------------

-----Original Message-----
差出人 : Hitoshi Sekine <[email-masked]>
宛先 : 'Fumio Nagasaka' <[email-masked]>; 'Stephen Holmstead'
<[email-masked]>; 'Toru Ueda' <[email-masked]>;
Turner, Randy <[email-masked]>
CC : 'Brian Batchelder' <[email-masked]>; [email-masked] <[email-masked]>;
'PWG-C mailing' <[email-masked]>; [email-masked]'
<[email-masked]>
日時 : 1998年2月16日 7:21
件名 : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes

>> -------------------------------------------------------------------------
-
>> ----------------
>> IEEE 1394     |   Memory Bus
>> -------------------------------------------------------------------------
-
>> ----------------
>> -------------------------------------------------------------------------
-
>> ----------------
>>
>> Transaction style:
>> -------------------------------------------------------------------------
-
>> ----------------
>> -------------------------------------------------------------------------
-
>> ----------------
>> -------------------------------------------------------------------------
-
>> ----------------

---

From: Hitoshi Sekine <[email-masked]>
Date: Sun, 15 Feb 1998 21:59:36 -0800

Nakamura-san,

I still like to provide a same transport for PC software over the other
printer interfaces. Printer manufactures have supported USB, 1284 and .4 for
printers. I believe that no one like to develop software running only with
PWG specific 1394 printer protocol. We need consistency over any printing
devices.

Saying just 1284.4 over SBP-2 may cause some confusions. Have you described
what is inefficient to stack overlapping functionality and tried to remove
it from 1284.4 over SBP-2? Is supporting socket interface included in the
latest proposal? If you have, I am sorry. My manager didn't allow me to
travel to Maui, however I loved to be there. Can you update the latest
status or a meeting memo in Maui? I need catching up you.

By the way, who is Eric? Whom did he contact with in MS? Though I don't own
a storage, I would like to hear the story from him. If someone in MS had
miscommunication with him, I can forward it to proprietary in MS.

Thanks,
Hitoshi

> From:	Atsushi Nakamura [SMTP:[email-masked]]
> Sent:	Sunday, February 15, 1998 7:35 PM
> To:	Hitoshi Sekine
> Cc:	'PWG-C mailing'; [email-masked]; [email-masked]
> ??? : Hitoshi Sekine <[email-masked]>
> ?? : 'Fumio Nagasaka' <[email-masked]>; 'Stephen Holmstead'
> ?? : 1998?2?16? 7:21
> ?? : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> 
> >

---

From: "Turner, Randy" <[email-masked]>
Date: Sun, 15 Feb 1998 22:29:27 -0800

I would like very much to be able to write 1394 multifunction apps
according to the Winsock 2 specification. I am coming to the conclusion
that I would like to see one of the following two architectures to be
used:
		
		1. Application over SBP-2  over 1394 transaction layer
(OHCI, etc.)
		2. Application over 1284.4 over 1394 transaction layer
(OHCI, etc.)

In my opinion we should have a goal of maintaining a single link layer
protocol for both THIN and THICK solutions (if there is a THICK
solution). This means that for DPP solutions I would like to see us use
SBP-2, both initiator and target. If the PWG-C designs a lighter weight
link layer protocol (lighter than SBP-2), then I think we should attempt
to standardize this protocol and use it.

You will notice that I have left out the option of 1284.4 over SBP-2
because I agree with the overall sentiment that there is significant
overlap between what the two protocols offer. If there is a desire to
use 1284.4, then mapping 1284.4 directly over the 1394 transaction layer
is a natural fit. If we want to use SBP-2, then there is really no need
to use 1284.4 and we can still provide the same API to application
software.

In my opinion, a target-only or initiator-only implementation of SBP-2
is not very interesting given the peer-to-peer capabilities of the 1394
interface. Which means that if I need true peer-to-peer functionality,
then I will have to create yet again another new link layer protocol,
and I would rather solve the link layer protocol problem once. I have
not seen a technical reason so far on the DL that would adequately
explain why we cannot settle on a single, peer-to-peer link layer
protocol for 1394.

As far as the "application" specified in options 1 and 2 above, I'm
assuming this would either be DPP, 1284.1, or some other application
layer protocol. 

Randy

	-----Original Message-----
	From:	Hitoshi Sekine [SMTP:[email-masked]]
	Sent:	Sunday, February 15, 1998 10:00 PM
	To:	[email-masked]'
	Cc:	[email-masked]'; [email-masked]';
[email-masked]'
	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes

	Nakamura-san,

	I still like to provide a same transport for PC software over
the other
	printer interfaces. Printer manufactures have supported USB,
1284 and .4 for
	printers. I believe that no one like to develop software running
only with
	PWG specific 1394 printer protocol. We need consistency over any
printing
	devices.

	Saying just 1284.4 over SBP-2 may cause some confusions. Have
you described
	what is inefficient to stack overlapping functionality and tried
to remove
	it from 1284.4 over SBP-2? Is supporting socket interface
included in the
	latest proposal? If you have, I am sorry. My manager didn't
allow me to
	travel to Maui, however I loved to be there. Can you update the
latest
	status or a meeting memo in Maui? I need catching up you.

	By the way, who is Eric? Whom did he contact with in MS? Though
I don't own
	a storage, I would like to hear the story from him. If someone
in MS had
	miscommunication with him, I can forward it to proprietary in
MS.

	Thanks,
	Hitoshi

	> >I love a symmetrical transport also. PC Printing has
supported 1284, USB
	> and
	> >1394 soon. If you considers a symmetrical transport for 1284,
USB and
	> 1394
	> >solutions between PWG-C and PWG. We need to get our
priorities right. Not
	> to
------------------------------------------------------------------------
-
------------------------------------------------------------------------
-
------------------------------------------------------------------------
-
------------------------------------------------------------------------
-
------------------------------------------------------------------------
-
------------------------------------------------------------------------
-
	> -
	> >> ----------------
	> >>
	> >> Please correct if I had overlooked something or I am
missing some
	> points.
	> >> understand--I may be way off here).  If so, that would be
great.  I
	> have

---

From: Nobuhiko Shinoda <[email-masked]>
Date: Mon, 16 Feb 1998 15:00:19 +0900

Nagasaka-san:

Seeing the previous mail of Ueda-san, the ROM size isuue is not the discussing
point.  And I hardly understand your comparison of the code size to VxWorks or
Jet Send.

The value of 30k itself has not determined well enough.  Even if it is true,
does 30k cover real symmetric structure for the equipment and  some upper layer
i/f capability which Thin Protocol might cover to put on DPP command/data set
?

I am slightly sensitive to talk about just ROM size based on someone's
imagination or illusion which has not well identfied the functionality.  

Jet Send's code size is not worth for comparing or discussing transport layer.
"Consumer" product is very sensitive to cost of code size, but it also depends
on the benefit of "consumer".  In my experience, the first EOS system had 64kB
total ROM 10 years ago, but it was successful in the market for the reason of
integration of automatic and manual tuning capability with simple user
interface.  JetSend might lead successful product in consumer market regardless
of its code size.  But this is not the discussiong point in PWG-C.

I may be wrong, or misunderstood your point due to my lack of knowledge, but
the questioning the ROM size to Ueda-san sounds very strange after checking the
back log you attatched.

At 14:11 98/02/15 +0900, you wrote:
> Dear Toru san,
> 
> One point.
> I think 30k is good size even for cheap consumer devices.
> This size is smaller than typical VxWorks implementation, and it
> may be smaller than JetSend.
> 
> So please give us information how big your DPP ROM size is expected to.
> 

篠田　信比古
Ｎｏｂｕｈｉｋｏ　Ｓｈｉｎｏｄａ
Bシステム開発部部長
General　Manager
BJ Printing System Development Division
B機器技術開発センター副所長
Assistant Senior General Manager
BJ Printing System Technology　Development Center
Ｃａｎｏｎ　Ｉｎｃ．

---

From: Nagasaka Fumio <[email-masked]>
Date: Mon, 16 Feb 1998 20:57:32 +0900

Dear Toru,

Thanks for your productive information.
My colleague has written a SBP-2 target software for our printer
optional board fitted with H8 CPU. The ROM size was 18k B.
Those source code was developed by C and assembler. Thus
we confirm Greg’s estimation for SBP-2 ROM size is correct.
And I also think this size of ROM or CPU would not be acceptable for
some consumer devices. For these devices, DPP could be a
desirable solution.

So please continue to explain your idea about 1394 printing.
Does your DPP seem to be stream style protocol? Or are you
going to have any plan to provide memory bus style protocol?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to [email-masked]

		-----Original Message-----
		From:	Toru Ueda [SMTP:[email-masked]]
		Sent:	Tuesday, February 17, 1998 12:26 AM
		To:	Fumio Nagasaka
		Cc:	'Stephen Holmstead'; 'Brian Batchelder';
[email-masked]; 'PWG-C mailing'; Turner, Randy
		Subject:	Re[2]: Re[2]: P1394> Rough SBP-2 &
IP1394 core component ROM sizes

		Hi Nagasaka-san,

		Actually a Digital Cam corder is around $2000 list
price. It's not CHEAP
		though :-).

		We are still working to finalize the protocol and
estimate the ROM size.
		I only can say is that our target ROM size for Thin
protocol of DPP is
		less than 10KB. This includes sender and receiver
function.

		If your node doesn't have to implement all
functionality, it will be
		smaller. This is the case that the node must receive the
connection
		request but doesn't need to send the request of
connection.

		We also want to emphasize that DPP has simple scheme. 
		 1) send "connect request"
		 2) send "data"
		 3) receive "acknowledge"
		 4) do 2) and 3)
		 5) send "disconnect request"

		The other side can also do 2),3),4),5).
		This is very straightforward.

		Again I don't want to make any confusion in PC printing
discussion. 
		I just want to tell DPP to PWG correctly.

		Toru Ueda
		Sharp Corp.
		Software Labs.

		On Sun, 15 Feb 1998 13:21:45 +0900
		Fumio Nagasaka <[email-masked]> wrote:

		> Sent:	Saturday, February 14, 1998 6:45 AM
		> To:	Turner, Randy
		> Subject:	Re[2]: P1394> Rough SBP-2 & IP1394 core
component ROM sizes
		> > SBP-2 initiator and target, whether they actually
use SBP-2 to do this,
		> > 	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
		> > 	> I am very interested in the combined
target/initiator
		> > footprint as
		> > 	> 	Subject:	Re: P1394> Rough SBP-2 &
IP1394 core
		> > component
		> > 	> 	>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
		> > 	> 	>  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?
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
		> > 	> ‾
		> > 	> 	Connectivity Futurist | 1115 SE 164th
Ave.   | Phone:
		> > (360)
		> > 	> 212-4107  
		> > 	> 	DeskJet Printers      | Vancouver, WA
98684 | Fax:
		> > (360)

---

From: "Eric Anderson" <[email-masked]>
Date: 16 Feb 98 10:45:28 +0000

Hello Sekine-san,

I am "Eric".  I am the FireWire Software lead at Apple Computer.

You wrote:
  "I love a symmetrical transport also. PC Printing has supported
   1284, USB and 1394 soon. If you considers a symmetrical transport
   for 1284, USB and 1394 (and IP), it will be great for us. To
   redesign PC software only for a new 1394 print transport will be
   tough."

Do you speak officially for Microsoft in Redmond?  Is this a policy
statement that Microsoft will support 1284.4 over 1394 instead of
a pure SBP-2 native printer protocol?  This would be very different
from Microsoft's position about Tailgate.  The 1394 team in Redmond
has been quiet on this subject, so an official response would help.

Since you did not recognize my name, perhaps you did not see my
original message.  A copy is attached below.

--------------------------------------
Eric Anderson            [email-masked]
Apple Computer, Inc.      408-974-8187
--------------------------------------

============
== This letter was sent to [email-masked] and [email-masked]
== by Eric Anderson ([email-masked]) on 98.02.09:

Hi Larry,

Since you asked, I'll try to politely explain my preference for
solution B: New SBP-2 command set with SBP-2.  I regret that I
can't make a strong argument, because I haven't had the time to
track closely your progress with solution A.  Still, I think
there are compelling reasons to consider solution B.

Now we have a similar situation with printers.  1284.4 is a
very well established technology.  Compared to 1394, I think it
would be fair to say that 1284.4 is also a very slow and clumsy
technology (nothing personal!).  Surprise, surprise - the idea
comes up to bundle 1284.4 in SBP-2 because some purported savings
can be had, in the short term.  From what I have seen of how this
works, it is quite inefficient, with lots of unsolicited status
requests and in general lots of hand-holding by the CPU on the
initiator.  This is not what SBP-2 was designed for.

As printer resolutions climb, printer bandwidth rises very
quickly.  Yes, we all still do dull black and white word
processing, but I think you printer vendors will agree that the
exciting (high-margin) areas are in con-tone large-format high-
speed printers - just the sort that need 1394.  Or sparing that,
even consumer-level inkjets now have remarkable resolutions and
consume quite a lot of bandwidth.

Used properly, SBP-2 allows huge data transfers that can proceed
at the pace of the consumer (printer), with no hand-holding by
the host (computer).  Since host systems have 32 or more megs of
RAM today, ideally, printing should proceed with at most one
interrupt per megabyte of data transferred (assuming no errors),
leaving the CPU free to do useful work (like rasterizing).  SBP-2
and OpenHCI make this possible - but only if protocols are designed
with care to avoid needless interruption of the host.

Perhaps I have misunderstood your recent work regarding 1284.4 on
1394 in SBP-2, but I believe that the present plan will have far
more overhead than what I just described.  Specifically, I believe
this overhead comes from carefully emulating 1284.4 rather than
using SBP-2 in it's most natural way.  Over the lifetime of
1394, the cost of that overhead in wasted MIPS and wasted time will
far exceed any possible savings from recycling current protocols
and software.

1394 is far more "future friendly" and scalable than other
interconnects were at their introductions.  That didn't stop
Ethernet, ATA, SCSI, Parallel Port, and the like from living as
useful technologies for one or two decades.  Our goal should be
to make 1394 last at least as long, if not longer.  Portability
of a protocol to new interconnects at the expense of efficiency
doesn't seem valuable to me in this context - in fact, it seems
counter-productive.  The more inefficient the protocol we choose,
the more demand there will be for ever-faster interconnects.  A
well-designed, efficient protocol can last a very long time, and
serve everyone's needs better during that time.

I hope I haven't gone too far overboard here or stepped too hard
on any toes.  To conclude, I want to ask a simple question:  Has
anyone run this idea past Microsoft?  Microsoft killed off
Tailgate, and my guess is that they may have similar feelings
about printing.  Market reality is that we'll all follow whatever
they decide, so it really makes sense to get them involved.

Alas, I can't join you in Austin, but I do welcome your comments
by email.  Please be patient if you ask good (ie hard) questions.
============
> > >I love a symmetrical transport also. PC Printing has supported 1284,
USB
> > >solutions between PWG-C and PWG. We need to get our priorities right.
Not

---

From: Hitoshi Sekine <[email-masked]>
Date: Mon, 16 Feb 1998 18:07:52 -0800

Thank you, George.

Eric, Thank you for forwarding your mail. It is what I needed to know.
Though I don't think we can throw an official comment to this public mail
alias, we can do our best to work with the industry together.

Using Sbp-2 is fine with us. I can easily implement printing stack at the
top of SBP-2. It is also reasonable with Printers. It seems that many people
in PWG can agree it.
I haven't personally decided which "option" is better since I haven't done
any technical investigation of 1284.4 over SBP-2. But the reason why I like
it is that we can provide same interfaces to any printing interfaces such as
1284, USB and 1394. Some people (Randy and ...) mentioned to define Socket
interface at the top of the layer. If it can be implemented over any
printing interfaces, it may be enough. I am particular about "SBP-2" but not
so particular about "1284.4 over SBP-2".

Thanks,
Hitoshi

> From:	George Chrysanthakopoulos 
> Sent:	Monday, February 16, 1998 5:39 PM
> To:	Hitoshi Sekine; 'Eric Anderson'
> Cc:	John Nels Fuller
> Hi i am very familiar with the hole tailgate deal since i made my best to
> get rid of it. Our intentions for printing are the same as for storage.
> Use a protocol/command set that makes sense over 1394.  Sbp2 is used for
> both, same driver same stack...
> 
> For storage we are using MMC2/RBC.
> For printing i had no intention to support 1284.4 by making any special
> adjustments to the 1394/sbp2 stack. If somebody managed to attach 1284.4
> on top then thats fine ( although i agree its not the preferred method)
> 
> The current plan is to use the scsi command set over sbp2, to talk to
> scanners/printers. If the scsi command set is not adequete( or too
> bloated), then we neeed to go towards that direction(just like RBC). Right
> now however using SCSI will make existing scanner technology and hopefully
> printers come faster in the market using the sbp/1394.
> 
> i have made our intentions clear to the printing/scanner vendors i have
> been in touch so far..
> 
> thanx
> g
> 
> From:	Hitoshi Sekine 
> Sent:	Monday, February 16, 1998 5:29 PM
> To:	John Nels Fuller; George Chrysanthakopoulos
> Cc:	'Eric Anderson'
> George and John,
> Have you spoke to Eric at Apple? Are you aware of the story of Tailgate?
> 
> thanks,
> hitoshi
> 
> From:	Eric Anderson [SMTP:[email-masked]]
> Sent:	Monday, February 16, 1998 2:45 AM
> To:	Hitoshi Sekine
> Cc:	[email-masked]; [email-masked]; [email-masked]

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 16 Feb 1998 18:44:01 -0800

Hitoshi,

It is my impression that SBP-2, as being implemented by Microsoft, is
initiator-only. Is this still the case? Overall, I would agree with you
that SBP-2 would work fine for printing, but I would like the same
transport to be used for multifunction devices, including printing,
scanning, fax, etc. For this reason I would like our specification to
say that we can support an overall SBP-2 that contains both target and
initiator functionality. 

There has been some discussion on the list in the past that this request
is "difficult to do". To date, I haven't seen any technical rationale
for this sentiment. Rather, Michael Teener and others have stated that
it can be accomplished. One other reason that was mentioned, was that
supporting target-SBP-2 would require dynamic settings to the
configuration ROM for NT 5.0. I do not think supporting both
initiator-and-target SBP-2 would require dynamic config ROM settings.

And yes, I would also like to reiterate my desire to see access to this
transport available through a Winsock-2 address family.

Randy

	-----Original Message-----
	From:	Hitoshi Sekine [SMTP:[email-masked]]
	Sent:	Monday, February 16, 1998 6:08 PM
	To:	George Chrysanthakopoulos; 'Eric Anderson'
	Cc:	John Nels Fuller; [email-masked]';
[email-masked]'; [email-masked]'
	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes

	Thank you, George.

	Eric, Thank you for forwarding your mail. It is what I needed to
know.
	Though I don't think we can throw an official comment to this
public mail
	alias, we can do our best to work with the industry together.

	Using Sbp-2 is fine with us. I can easily implement printing
stack at the
	top of SBP-2. It is also reasonable with Printers. It seems that
many people
	in PWG can agree it.
	I haven't personally decided which "option" is better since I
haven't done
	any technical investigation of 1284.4 over SBP-2. But the reason
why I like
	it is that we can provide same interfaces to any printing
interfaces such as
	1284, USB and 1394. Some people (Randy and ...) mentioned to
define Socket
	interface at the top of the layer. If it can be implemented over
any
	printing interfaces, it may be enough. I am particular about
"SBP-2" but not
	so particular about "1284.4 over SBP-2".

	Thanks,
	Hitoshi

ROM sizes
ROM sizes
ROM sizes
	> original message.  A copy is attached below.
1284 and .4
	> for
	> > printers. I believe that no one like to develop software
running only
	> with
	> > Saying just 1284.4 over SBP-2 may cause some confusions.
Have you
	> described
	> > what is inefficient to stack overlapping functionality and
tried to
	> remove
included in
	> the
allow me to
	> > By the way, who is Eric? Whom did he contact with in MS?
Though I don't
	> own
ROM sizes
	> > > >transport, and much of it's potential was wasted.
Tailgate
	> > > 'PWG-C mailing' <[email-masked]>;
[email-masked]'
supported 1284,
	> USB
	> > > and
	> > > >1394 soon. If you considers a symmetrical transport for
1284, USB and
	> > > 1394
	> > > >(and IP), it will be great for us. To redesign PC
software only for a
	> new
	> > > >1394 print transport will be tough. I don't mean to
recommend
	> different
priorities right.
ROM sizes
	> > > >>
	> > > >> Dear Stephen,
	> > > >>
	> > > >> Your opinion bring us back to December 1996. Actually
we started
	> from
missing some
	> > > points.
	> > > >>
	> > > >> Stephen wrote:
	> > > >> <<
	> > > >> requirements).  I would HATE to have to make a printer
that
	> implemented
	> > > >> to support USB, conventional parallel port, 1394 and
Macintosh
	> serial
[email-masked]
ROM sizes
	> > > >>
	> > > >> I agree with Toru that we NEED a symmetrical transport.
I really
	> don't
	> > > >> 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
	> > > >> requirements).  I would HATE to have to make a printer
that
	> implemented
	> > > >> Greg Shue said that he made a proposal to the January
PWG that
	> would
	> > > >> 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
	> > > >> Personally, I am biased towards IP or 1284.4 (if you
couldn't
	> tell).

---

From: George Chrysanthakopoulos <[email-masked]>
Date: Mon, 16 Feb 1998 19:09:00 -0800

Hi,
our intentions is to use the same transport over 1394. Right now we plan to
use ( and already have driver support for) scanners,printers and storage
devices under sbp2. There no need to have a target/initiator functionality
on the PC and that  is one of the reasons sbp2 was designed the way it was. 
So even if there is no need for the PC to become a target sbp2 node, even
for multilun devices, it is possible but not recommended for normal
printer/scanner applications. And yes it will require dynamic config rom
settings.

In any case, its not necessery and scanners/printers/HDD/cdroms will work
just fine with the PC being initiator. Through unsolicited status and a
proper command set the target can initiate requests, if that is your
concern.

RBC is designed exaclty for that purpose, for storage devices using sbp2.
MMC/2 i used for cdrom/dvd type of devices.
In any case the OS is going to use one single lower driver stack to
accomodate scanners, printers, storage devices etc as long as they use sbp2
as the transport on 1394. The command set can and will be slightly different
between devices but we like it to be as similar to SCSI as possible ( for
several reasons). This is the major premise RBC and MMC2 are being specified
on...

it would be great if the scanner/printing group chooses a similar method as
RBC/MMC2. This makes sbp2 devices have driver support today , reusing the
upper class drivers used for other buses (ide/scsi). 

So for example the scsi class driver used on top of a scsi scanner on SCSI,
can be re-used with absolutely NO modifications, for an 1394/SBP2 scanner,
that uses the scsi command set today.... In the 1394 scanner however, th
elower drivers will be the sbp2port driver and the 1394 lower drivers.

if you would like more details about our implementation please just let me
know ( so we dont flood the reflector with replies)

thanx

george

> Sent:	Monday, February 16, 1998 6:44 PM
> To:	Hitoshi Sekine; George Chrysanthakopoulos; 'Eric Anderson'
> Cc:	John Nels Fuller; [email-masked]'; [email-masked]';

---

From: "Oktay, Ozay" <[email-masked]>
Date: Tue, 17 Feb 1998 10:03:02 -0800

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

	----------
	From:  Brian Batchelder [SMTP:[email-masked]]
	Sent:  Tuesday, February 17, 1998 12:30 AM
	To:  [email-masked]
	Subject:  Re: P1394> Rough SBP-2 & IP1394 core component ROM
sizes

	Time to put in my $0.02-worth.  I apologize if any of this is
redundant.  I
	wrote it a few days ago, but only now have been able to send it.

	1394 was designed for, and will be used as a symmetric,
peer-to-peer bus.
	The majority of devices will benefit from being able to
communicate with
	every other device, which includes both initiating that
communication and
	sending and receiving data.  Other devices that don't need
peer-to-peer
	functionality will also move to 1394 for other factors, e.g.
throughput,
	installed base, etc.

	IMHO, SBP-2 was designed to provide for those non peer-to-peer
devices by
	emulating old master-slave busses on top of this inherently
peer-to-peer
	bus.  (Flame away!)  This works well for mass storage devices,
for example.
	 The initiator always initiates (sorry) communication.  The
target never
	initiates communication.  The initiator knows the sequence and
quantity of
	data to be transferred.  The target paces and executes the
transfer of that
	data.  

	Unfortunately, this doesn't map well to true "peers".  As I
indicated
	earlier, each peer wants to initiate communication with other
peers, in
	addition to being the target of other peers.  You can think of
this from
	the application point of view.  Applications that operate as
clients want
	to initiate communication with applications that operate as
servers.  Most
	devices will have both types of applications.  Printers have
print engines
	(servers) and status engines (clients).  Scanners have control
engines
	(servers) and scan engines (clients).  Multi-function
peripherals have all
	of that plus maybe FAX engines, which might act as servers and
clients.

	In the past, we have made clients look like servers and
vice-versa, because
	of the limitation of our busses.  Fine.  I can see SBP-2 as a
mechanism to
	bring those old implementations to 1394.  We have also figured
out ways to
	allow clients and servers over master/slave busses by hiding the
	"master/slaveness" in the transport layer (1284.4 is an example
of this).
	To make SBP-2 work AS IS for us, we would have to choose one of
those two
	paths, and we still have to add some other functionality.

	Actually, I am currently leaning towards SBP-2, but we must use
it in a way
	that allows clients to be clients, servers to be servers, and
both to exist
	on every device.  This probably means implementing both target
and
	initiator (targiator) functionality on each device.  If the chip
	implementations available today don't optimally support
targiators, well,
	we won't be optimal until they are fixed.  However, I was
pleased to read
	Michael Teener's message in which he indicated that targiators
should be
	quite possible.

	If, however, targiators CAN'T be supported, I believe we will
have to look
	elsewhere for a solution.  I like Ats' idea of 1284.4 over
something else
	(DFA?).  I agree that 1284.4+SBP-2 does feel quite redundant.  I
know that
	we chose SBP-2 largely because it was an existing standard with
support
	from both Microsoft and the mass-storage industry.  One thing
this long
	discussion has DEFINITELY taught me is that SBP-2 is not
unanimously
	believed to be the obvious solution.

	Remember, we are specifying a protocol that we must assume will
be used for
	at least the next 10 years.  Can we afford to limit the
functionality of
	our implementations?

	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