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

George Chrysanthakopoulos (georgioc@microsoft.com)
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

> -----Original Message-----
> From: Turner, Randy [SMTP:rturner@sharplabs.com]
> Sent: Monday, February 16, 1998 6:44 PM
> To: Hitoshi Sekine; 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
>
>
> 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
> > > > >>
> > > >
> > > >
> > >
> >
> >
> >
> >
> >