>Incidently, this transport should already be as predictable as
>1284.4.
This is the answer I was waiting for.
If 1394 PWG transport is as predictable as 1284.4,
then we shall remove descriptions which are describing
two queues model in 1394 PWG profile. Because these
descriptions are implementation issue and beyond the
specification. In addition to this, if our transport
is as predictable as 1284.4, then why do we need to describe
something about two queues model. The forward direction
(I to T) transaction and the reverse direction (T to I)
transaction will not be stalled. If so, we do not need
to assume a target to have two independent queues.
Also 1394 PWG profile describes in "1. Scope".
(reformatted)
>This document specifies the communications profile and device
>communications command set for imaging devices attached to
>the IEEE 1394 High Speed Serial Bus.
>SBP-2 provides multiple, concurrent, independent connections
>which do not preclude concurrent operation of other protocol
>stacks; is data, application, and OS independent In order
>to meet the requirements for imaging devices, SBP-2 must be
>supplemented by a device profile, which specifies:
>Information supplemental to the IEEE 1394 and SBP-2
>specifications are provided in this document.
> * a policy to be used for maintaining device access across
> "transient" link interruptions
> * a model of use for maintaining guaranteed, in-order data
> deliver across "transient" link interruptions
> *a command set which supports
> * independent, bi-directional, half-duplex communication
> * data tagging of an associated data payload
> * ability for either end of a connection to close the
> connection at any time
The current command set does not meet the scope of 1394
PWG profile. Because the command set does not allow for
either end of a connection to close the connection at
any time. Also the current command set does not describe
the way to support multiple host connectivity. Actually
when a host A is printing to a target B utilizing LUN #1,
then the other host C cannot login to receive status of
the target B. Or the fetch agent of the target B shall
implement multiple login capability to allow the host C
to login to receive status, while the host A is printing.
I felt only two commands;
- TRANSPORT_I2T_DATA
- TRANSPORT_T2I_DATA
is required to develop data link layer for printing. And
any OS vender may use IEEE P1284.4 or MLC 3.x over this
data link layer to make a predictable multiple logical
channel supportive transport layer. I beleive 1284.4 is
beyond the specification of 1394 PWG command set. But 1394
PWG cannot forbid any OS vender to use 1284.4 over the data
link layer defined by 1394 PWG. Why do we need to define
something quite new from scratch? IEEE P1284.4 is one of
the excellent result from our PWG and it is very new.
I had experienced my proposal 1284.4 over SBP-2 was
eliminated through 1394 PWG discussion. Thus I realized
we need to define something better than 1284.4. However
for me, current commands set seems to be more poor than
1284.4.
| 1284.4 | 1394 PWG cmd set |
------------------|--------------|--------------------|
Multiple Logical | YES | NO |
channels | | or YES/w LUNs |
open/close from | YES | NO |
both peer | | |
predicatble | YES | YES |
API for WinSock2 | YES | NO |
standardization | 99% ALREADY | NOT YET |
Multi Host support| NO | NO |
|or YES/w LUNs | or YES/w LUNs |
------------------------------------------------------|
The chair man shall drive our discussion to clear pros/cons
of these idea;
1) something already existing over SBP-2 as data link
2) new command set now we are discussing over SBP-2
And 1394 PWG profile shall clear the method to support
multiple hosts connectivity. Design for the timer is
less priority. We will be able to define timer
requirements later, when we've got a real model of
transaction.
I don't feel my opinion bring us several month back to
the confusion. If the current model is not suitable for
current protocol driver provided in existing consumer PC OS,
we need to pay great effort to develop new device drivers.
And these effort will easily take several months to write,
to test and to debug new software. May be, my job becomes
more busy as code developer. :-) Thus we shall choose better
way to ship real products into the market.
Greg wrote:
>
>Fumio! Are you serious about this timer? You know as well as I
>do that:
>
> - There is no need for the target to send all the data
> requested by the initiator before completing the request,
> since the _residual_ field will indicate the difference.
> Padding bytes are not necessary.
>
>(and as discussed at the August meeting and a bit on the
>reflector(?))
> - The target is at liberty to complete the ORB at it's
> own discretion. Since there is no reason for the
> transport to hold it open for long periods of time
> after it has moved some data, it should complete it
> soon after moving all the data which was pending.
>
>This means there is no _need_ for a hanging read ORB timeout at
>the transport layer. If one happened to be used, then it would
>need to be sensitive to the expected completion time of an ORB.
>Since the transport specifies a hanging TRANSPORT_T2I_DATA ORB to
>exist at all times, this ORB may not be completed for hours. If
>this is a problem with current SBP-2 implementations, then we
>need to raise that issue.
>
>Incidently, this transport should already be as predictable as
>1284.4.
>
>If an initiator-side application is expecting "500" bytes to be
>returned by the target, and wishes to maintain a timeout for that
>transfer, then this is beyond the scope of the transport.
>
>- Greg Shue, HP
>
>Fumio wrote:
>> Hanging read ORB release timer;
>>
>> When an initiator assume a target will reply 500 bytes,
>> but the target device only replies 300 bytes, then this
>> input ORB will not be completed. The initiator is waiting
>> for 200 bytes as rest of the contents. If we do not have
>> any timer to detect this situation and if the transport
>> layer software does not resolve hanging ORB to avoid input
>> pipe stalling, a higher level client software need to solve
>> this problem.
>>
>> One possible solution for the problem is that the transport
>> software of the target fills padding data (null data) when
>> this timer over runs, and the target force to complete this
>> input ORB, and also the target shall reply the valid length
>> of data in the input buffer.
>>
>> However I do not feel that we need to define this timer.
>>
>> Because I prefer to design a predictable transport like CBT.
>> If we choose a CBT style solution, the target may ask the
>> initiator to provide credit to receive data from the target.
>> Then the target sends a packet which contains length field
>> of valid data length and real data itself. Thus I believe
>> timer design depends upon whether we can define predictable
>> transport or not. Actually IEEE 1284.4 does not require to
>> have this sort of timer, because it does not need to assume
>> a communication pipe to be stalled.
>>
>> Fumio
>>
>> Alan wrote:
>> >August 25, 1998
>> >
>> >This is a call for discussion on Timers for the 1394 Image Profile.
>> >At the last meeting we attempted to address this issue and only identified 3
>> >timers. Are there others we missed? Please submit comments and suggestions.
>> >
>> >1) Reconnect Timer - This one is taken care of by SBP-2 as part of the Login
>> >process.
>> >
>> >2) Management ORB Timer - When the Initiator writes a Management ORB address to
>> >the Management Agent Register, how long should it wait for a response to be
>> >written to the management ORBs status fifo? How is the timeout value determined
>> >and communicated?
>> >
>> >3) Abort Task Set Timer - An Abort Task Set may issued by an Initiator in
>> >response to Target Inactivity. How is the timeout value determined and
>> >communicated?
>> >
>> >Any other timers that we did not include at the last meeting?
>> >
>> >
>> >
>>
>> ---
>> Fumio Nagasaka
>> EPSON Software Deveopment Lab., Inc.
>> voice: +81 268 25-4111
>>
>
>
>--
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division gregs@sdd.hp.com
>----------------------------------------------------------------
>
--- Fumio Nagasaka EPSON Software Deveopment Lab., Inc. voice: +81 268 25-4111