Subject: Re: P1394> 1284.4 over SBP-2

From: "Eric Anderson" <[email-masked]>
Date: 9 Feb 98 22:33:35 -0800

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.

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.

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.

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.

Sincerely,

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

> Hello Everyone,
> 
> I'm sending this message to see if we can stimulate some discussion on
this
> subject prior to the 1394PWG meeting in Austin next month.
> 
> For the past year we have been meeting to develop a standard to provide
the
> high functionality transport method for printing over the IEEE 1394
> interface.  This is 'high functionality' , or 'thick' transport, as
opposed
> to the 'thin' transport that is being developed by the PWG-C.  The
> direction that our group has taken has involved reviewing FCP, DFA,
SBP-2,
> and others, as the lower transport and datalink interface, with something
> else as the transport interface.  This something else has focused on
1284.4
> or on a native 'glue' layer to the underlying datalink.
> 
> At this point in time we have apparently narrowed our potential solutions
> to the following:
> 
> A- 1284.4 with SBP-2
> B-  New SBP-2 command set with SBP-2
> 
> As many of you are aware, I'm primarily in support of option A as the
> preferred solution.  I'd like to take this opportunity to provide some of
> my reasoning and get feedback from you.
> 
> My support for this solution is not necessarily a technical reason, but a
> market reason.  As Greg Shue et al pointed out at the Maui meeting, it is
> possible to provide the required functionality by defining a new Command
> Set for SBP-2.  This would provide a transport solution for 1394 that is
> based solely on the SBP-2 protocol.  Technically, this is probably a
better
> solution than option A.
> 
> My question is "Is this really the best solution for the market today?".
> Many of us have expended great effort in developing the IEEE P1284.4
> standard.  One of the purposes and goals of  the development was to
create
> a datalink independent transport standard that could be used over the
> parallel port and other physical interfaces.
> 
> The intent here was to create a standard that would allow a peripheral to
> operate over various interfaces without requiring major architectural
> changes to the product.  In other words, a modular approach to the
> peripheral design.  A printer or MFP device could be developed to work
with
> 1284.4 over parallel today, and 'easily' adapted to work over 1394
> tomorrow.  The host application interface may not even know the
difference.
> 
> I think that this is the primary reasons for choosing option A.  It sends
a
> clear statement to peripheral and OS vendors that 1284.4 is the preferred
> transport interface for printer and MFP peripherals.  We back this up by
> providing solutions for parallel (1284.3) and for 1394.  This is not a
> stagnant industry and certainly new interfaces will appear in the future.
> I think it would be a great service that we provide a clear migration
path
> between interfaces that do not require redesign of the entire system.
> 
> Providing both options may be the result of this effort.  I think that
> option A should be the preferred one.
> 
> I await your responses.
> 
> Thanks,
> Larry
> 
> 
> ***************************************************************
> Larry A. Stein			Phone: 	(619)292-2742
> Warp Nine Engineering		Fax:	(619)292-8020
> 				Web: 	http://www.fapo.com
> ***************************************************************

---

From: Atsushi_Nakamura <[email-masked]>
Date: Sat, 14 Feb 1998 10:40:40 +0900

To All,

>From the discussions, I will ASSUME that SBP-2 has somehow been 

chosen to be THE transport for PC printing, and we will work the "glue"

for it. Has it ?  

This is a very important decision, and I have not heard anything

"official" about it. (Did I miss something in one of the meetings ?

I apologize if I did.)

IP over1394 ?, thin protocol(DPP)?, AVC? ... 

Nothing negative about SBP-2, I just want to take I thing at a time.

On the other hand, if we decide to use 1284.4, the natural way of thinking 

technically is to come up with a "glue" ( or SBP-2 subset, which was once 

proposed but turned down) between 1284.4 and 1394, since 1284.4

and SBP-2 has overlapping functionality.

I don't think anyone is planning on doing that.

I  would like to consider supporting B, IF we have decided to use

SBP-2 for PC printing.  

Eric' s note about Taigate and native-bridge was very convincing,

and I also think the same kind of situationt applies fro the printing world.

The HPT proposal, along with Alan's January proposal are 2 details 

of the "B" work, which is similar to the direction the strorage protocol

went from Tailgate to native-bridge, which I think is the natural way of 

thinking purely technically.

Ats Nakamura

At 22:33 98/02/09 -0800, Eric Anderson wrote:

-----------------------------------------

<bigger>Atsushi Nakamura

</bigger>-----------------------------------------

BJ Technology Develpoment 22,

Canon Inc.

53 Imai Kami-cho

Nakahara-Ku, Kawasaki-shi

postal no. 211

tel:+81-3-44-733-6111(ext.5593)

    +81-3-44-739-6634(direct)

fax:+81-3-44-739-6756

email(1):[email-masked]

email(2):[email-masked]

-----------------------------------------

---

From: Greg Shue <[email-masked]>
Date: Tue, 17 Feb 1998 11:45:10 -0800 (PST)

> chosen to be THE transport for PC printing, and we will work the "glue"

No.

We "all" acknowledge that IP1394 will provide _a_ 1394 printing
solution, and that it will exist on the cable.

The motion was made at the December meeting (and tabled until the
January meeting) for the PWG to pursue only a 1284.4 over SBP-2
solution.  In light of the SBP-2 only proposal which Alan and I
presented at the January meeting, the motion was withdrawn.

The issue came up of, 'if the solutions we're proposing are as
heavy as an IP1394 solution, then why not just use IP1394?'

As a result, I chased down the information about one company's
implementation and shared the _rough_ numbers.  The results,
IP1394 is signficicantly larger than even a combined initiator/
target SBP-2 solution.  So, an SBP-2 (or DPP) style solution
is not pointless.

> I don't think anyone is planning on doing that.

I already did that.  I tried to explain (in a previous posting)
what the SBP-2 subset would have to provide for that solution.
The result was a solution which also allowed SBP-2 to be used
_without_ 1284.4 if each service was modeled as a separate unit
directory, and each instance was modeled as a separate login.
So, I presented an SBP-2 only solution at the January meeting.

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