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

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

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

Turner, Randy (rturner@sharplabs.com)
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:hitoshis@MICROSOFT.com]
Sent: Monday, February 16, 1998 6:08 PM
To: George Chrysanthakopoulos; 'Eric Anderson'
Cc: John Nels Fuller; 'p1284_3@lexmark.com';
'p1394@pwg.org'; 'pp1394@cpdc.canon.co.jp'
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

> -----Original Message-----
> From: George Chrysanthakopoulos
> Sent: Monday, February 16, 1998 5:39 PM
> To: Hitoshi Sekine; 'Eric Anderson'
> Cc: John Nels Fuller
> Subject: RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
>
> 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
>
> -----Original Message-----
> From: Hitoshi Sekine
> Sent: Monday, February 16, 1998 5:29 PM
> To: John Nels Fuller; George Chrysanthakopoulos
> Cc: 'Eric Anderson'
> Subject: RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
>
> George and John,
>
> Have you spoke to Eric at Apple? Are you aware of the story of
Tailgate?
>
> thanks,
> hitoshi
>
> -----Original Message-----
> From: Eric Anderson [SMTP:ewa@apple.com]
> Sent: Monday, February 16, 1998 2:45 AM
> To: Hitoshi Sekine
> Cc: p1284_3@lexmark.com; p1394@pwg.org;
pp1394@cpdc.canon.co.jp
> Subject: RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
>
> 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 ewa@apple.com
> Apple Computer, Inc. 408-974-8187
> --------------------------------------
>
> ============
> == This letter was sent to p1394@pwg.org and
P1284_3@lexmark.com
> == by Eric Anderson (ewa@apple.com) 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.
>
> 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.
> ============
> > 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
> >
> > > -----Original Message-----
> > > From: Atsushi Nakamura [SMTP:atsnaka@mxa.mesh.ne.jp]
> > > Sent: Sunday, February 15, 1998 7:35 PM
> > > To: Hitoshi Sekine
> > > Cc: 'PWG-C mailing'; p1284_3@lexmark.com;
p1394@pwg.org
> > > Subject: RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
> > >
> > > 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 <hitoshis@microsoft.com>
> > > ?? : 'Fumio Nagasaka' <fumiona@venus.dti.ne.jp>; 'Stephen
Holmstead'
> > > <stephen@hpb16977.boi.hp.com>; 'Toru Ueda'
> <ueda@slab.tnr.sharp.co.jp>;
> > > Turner, Randy <rturner@sharplabs.com>
> > > CC : 'Brian Batchelder' <brianb@vcd.hp.com>; p1394@pwg.org
> > > <p1394@pwg.org>;
> > > 'PWG-C mailing' <pp1394@cpdc.canon.co.jp>;
'p1284_3@lexmark.com'
> > > <p1284_3@lexmark.com>
> > > ?? : 1998?2?16? 7:21
> > > ?? : RE: P1394> Rough SBP-2 & IP1394 core component ROM
sizes
> > >
> > >
> > > >
> > > >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
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
> > > >> Sent: Saturday, February 14, 1998 9:04 PM
> > > >> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
> > > >> Cc: 'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
> > > >> 'p1284_3@lexmark.com'; Hitoshi Sekine
> > > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
> > > >>
> > > >> 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 nagasaka.fumio@exc.epson.co.jp
> > > >>
> > > >> -----Original Message-----
> > > >> From: Stephen Holmstead
[SMTP:stephen@hpb16977.boi.hp.com]
> > > >> Sent: Saturday, February 14, 1998 12:59 PM
> > > >> To: 'Toru Ueda'; Turner, Randy
> > > >> Cc: 'Stephen Holmstead'; 'Brian Batchelder';
p1394@pwg.org
> > > >> 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
> > > >>
> > >
> > >
> >
>
>
>
>
>