Thanks for your comments. The purpose of starting this thread was to get
some of these issues and questions discussed before the next meeting. I
think it's working.
Thanks,
Larry
At 2/10/98 07:21 PM, Greg Shue wrote:
>
>> I await your responses.
>
>OK, here we go...
>
>
>Larry Stein wrote:
>
>> 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.
>>
>
>As I understood it, the ability for 'a peripheral to operate over
>various interfaces without requiring major architectural changes
>to the product' is provided by meeting the specified transport
>service requirements. As long as the transport requirements are
>met, no architectural changes are required of the product. Thus,
>the transport layers are all modular with respect to the product.
>(I think this is also why the PWG has not tried to eliminate a
>TCP/IP printing solution. :-)
>
>
>The main difference between options A and B is whether multiple
>services are made available through a 1284.4 MUX layer, or
>through a combination of Unit Directories and Logical Unit
>Numbers. The command set features needed for a combined
>1284.4/SBP-2 solution are essentially identical as for an
>SBP-2 only solution (as shown below).
>
> In order to provide a combined SBP-2/1284.4 solution, an
> SBP-2 command set must be provided which meets the Data Link
> requirements spelled out for 1284.4. These are:
>
> R1) Register/Unregister transport layer with the Data Link layer
> R2) Packet Data Transfer - error free, in order, as a whole
> R3) Asynchronous Operation - no polling shall be required.
>
> In order to map this within SBP-2, then the command set must
> provide (at least) the following features:
>
> F1) Transient link interruption support
> (to support R2 and R3)
> F2) Non-transient link loss indication (to support F1)
> F3) Extended SBP-2 Access Control to the transport
> interface (to support F1)
>
> F4) SBP-2 ORB execution model for packet transfers
> (to support R2 and R3)
> F5) Encapsulating of 1284.4 packets into ORBs
> (to support R2)
> F6) Policy to determine maximum DL packet size
> (to support R2 and F1)
> F7) Policy for how 1284.4 dialogue maps into SBP-2 access
> control (to support R2, R3, and F1)
>
> F8) Standard mechanism for indicating existence of 1284.4
> peer (to support R1)
>
> So, any of these features which are common with an SBP-2 only
> solution are outside the scope of concern here. (For the
> unfamiliar, they all are provided in the (very rough) SBP-2
> only proposal presented at the January PWG 1394 meeting.)
>
>These features are also those required for an SBP-2 only solution.
>Since these are in common, they _don't_ affect the choice of option A
>vs. option B.
>
>
>I can't give an answer to Larry's question directly, because "best"
>is rather subjective. What's "best" for a customer might not be
>"best" for a developer, and that might not be "best" for a
>technology, which are all indirectly related to what is "best"
>for the market. I tried to identify above what are not areas of
>tradeoffs between the two options so that we can look at what are.
>
>
>If "best" is thought of in terms of market, then (I suppose)
>supportability and deployment of the solution(s) matter the most,
>because the 'market' has almost no history. There really is no
>legacy issue which makes either choice A or choice B preferred,
>even though there are "legacy" printing solutions which will need
>to be supported (i.e. AVC, IP1394). So, each of the following
>areas become signficant:
>
>
>If "best" is thought of in terms of providing the transport
>services outlined by the requirements, then there is no
>signficant difference between the SBP-2 only solution or the
>combined solution.
>
>If "best" is thought of in terms of developers and development
>effort, then there is no significant difference between providing
>the SBP-2 only solution or the SBP-2 portion of a combined
>solution. There will be additional effort for a combined
>solution if a 1284.4 driver needs to be developed.
>
>If "best" is thought of in terms of (availability of) OS support,
>then the SBP-2 only solution is preferred because a greater portion
>of the total solution already is provided by or is committed to
>by OS vendors.
>
>If "best" is thought of in terms of product cost, then the SBP-2
>only solution is preferred because it has fewer layers.
>
>If "best" is thought of in terms of performance, then the SBP-2
>only solution is preferred because it isn't limited to 64-KByte
>packets.
>
>If "best" is thought of in terms of 1394 bus usage, then the
>SBP-2 only solution is preferred because it doesn't have the CBT
>crediting traffic of 1284.4.
>
>If "best" is thought of in terms of compliance testability, then
>the SBP-2 only solution is preferred because it is simpler and
>has fewer layers.
>
>If "best" is thought of in terms of availability customer
>solutions, then the SBP-2 only solution is preferred because of
>it's smaller footprint (which makes it more attractive to
>integrate into more devices) and it's spreading use for varying
>types of services on 1394.
>
>
>> 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.
>
>Unfortunately, that message of 1284.4 being "the preferred
>transport interface for printers" has been lost in the shuffle.
>There are (currently) four transport protocols being defined on
>1394 for printing. These are:
>
> + AVC (for video snapshot)
> + DPP (for non-PC device-to-device)
> + PWG 1394 solution(s) (being discussed)
> + IP1394
>
>I also haven't seen it get embraced for standardization on USB,
>where hardware limitations and lack of a multiplexing transport
>protocol solution identify a hole which 1284.4 can fill.
>
>
>When this is added to (Apple's) Eric Anderson's thoughts of:
>
> - Emulating a dead technology with new technology may yield
> short-term savings in implementation, but at the expense of
> long-term losses in performance. (philisophical)
>
> - Amazingly, reason prevailed, and Tailgate was abandoned in
> favor of a pure SBP-2 protocol for disk drives. (historical)
>
> - From what I have seen of how this (1284.4 over SBP-2) 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. (perceptual)
>
> - 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)... SBP-2 and OpenHCI make this possible - but
> only if protocols are designed with care to avoid needless
> interruption of the host. (practical)
>
> - 1394 is far more "future friendly" and scalable than other
> interconnects were at their introductions... 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. (consequential)
>
> - 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. (REALISTIC!!)
>
>And (from a previous posting of Eric's):
>
> - Microsoft says that their treatment of printers will be
> different. They will only login to printers and other shared
> devices when they actually want to use the printer. So a printer
> with only one login could be shared by several Windows systems.
> Apple plans to do the same thing for printers using SBP-2.
>
>And the most quotable quote from the January 98 PWG 1394 meeting:
>
> "Every protocol looks light until it's implemented."
>
>
>Given all of this, I am compelled to support option B.
>
>
>--
>Greg Shue
>Hewlett-Packard Company
>Office Products Division gregs@sdd.hp.com
>----------------------------------------------------------------
>
**********************************************************
Larry A. Stein Ph. 619-292-2742
Warp Nine Engineering Fax 619-292-8020
lstein@fapo.com http://www.fapo.com
**********************************************************