I am just saying one existing transport design seems to be
better than current 1394 PWG commands set. We need to do
more effort. If someone improve the design and persuade me
to realize 1394 command set is better, I willingly agree
with the idea. If not, my idea is the 1394 PWG command set
shall be a data link layer to be utilized with other
transport command set.
For example, usb printing class design seems to be providing
something convenient data link layer which is flexible to
meet higher protocol layer. I am not sure whether someone
had developed already, but may be someone can apply 1284.4
over usb printing class. Usb printing class design is
providing two bi-directional communication queue, bulk-in,
bulk-out and default pipe. And one bi-directional queue is
applicable for data session and the other is applicable for
transport control. One bi-directional communication pipe may
be enough to meet 1284.4. But in this thread, I have no
urge to say something about usb, thus I will stop to say more
about usb in here. I prefer 1394 :-)
Greg Shue wrote:
>Let's look at some other characteristics:
> effecient: LESS | MUCH MORE
> -> Bus Utilization: low to moderate | high
> (credit pkts aren't) |
> -> Max size transfer: 64KBytes | 2 GBytes - 1
I agree with you, but 64kB is max_length of one packet
delivered from a peer to the other peer. The title "Max size
transfer" may cause misunderstanding for someone who are
subscribing our reflector without knowledge about 1284.4.
> -> Max amt of data
> queuable: as much memory as max (negotiated) size
> allocated by device transfer * MAX_TASK_SET_SIZE - 1
Ok, if you say "queeable", the max size queuable in memory
cannot exceed max size of memory allocated by Operating System.
Thus your description is misleading the discussion.
Our scanner OS will not allocate 2 GB for queuable memory
space. :-) This is just a specification writing technique.
> for that connection
> -> Processing overhead: MUCH MORE | LESS
Agreed. Thank you! good pont.
>
> Defined SBP-2 No | Yes
> command set
This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
I mean 1284.4 is abstracted from any data link layer and it
does not have any dependency for data link design. If you
want to say your commands have some dependency for SBP-2
in words "defined SBP-2 command set", I feel it is better
to develop command set which does not have any dependency on
data link layer. We are defining transport layer.
>1284.4 is insufficient by itself as a data link.
>Without a description of an SBP-2 command set,
>target device model, Config ROM description,
>and model of use, you have an incomplete solution.
Let's clear the points;
I'm not saying I would like to use 1284.4 over SBP-2.
This idea was eliminated in February. I am saying that we
shall develop something better than 1284.4 to utilize
SBP-2, or something just a data link layer which is
applicable for transport protocol. But in later case
each vendor need to choose or develop higher layer to
apply this data link. Thus I prefer first idea. We shall
develop something more effective than 1284.4 to utilize
SBP-2. May be Greg is thinking current command set
is better thna aother, but I am thinking we need to pay
more effort to exceed even 1284.4.
>
>Fumio Nagasaka wrote:
>> >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.
>
>The services provided by the command set are the same as provided by a
>1284.4 connection. Separate logins provide separate channels.
>The big question in my mind is how many services and instances
>are combined in one UNIT. There is at least one path forward
>simply by defining each service instance is a separate unit.
>There may be other reasonable options.
>
>As far as predictability of the transport goes, you must not have
>done much debugging of 1284.4 communications. The exact sequence
>of packets going across the wire is not predictable. Neither is
>the sequence if IP packets going to an Ethernet node.
>
>The reason for providing the "two queues" descriptions on the command
>set is because we must describe how to use SBP-2 and what the contents
>of the CDB mean. Removing the description of "two queues" from
>the profile is equivalent to removing the concept of "credit"
>from 1284.4.
>
>The "two queues" is a conceptual description. There is nothing
>that requires that an implementation actually maintains two
>distinct queues. It could do it using a single linked list
>and searching through the list each time. It just must behave
>as though it were maintaining two distinct queues. This description
>is what gives it some degree of predictability.
>
>As far as "stalling" goes, the I2T direction and T2I direction
>could be stalled simply by the initiator not providing ORBs.
>What is prevented is that the data flow will not be blocked by
>_other_ communication.
>
>> 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.
>
>The command set by itself could never meet the scope of the
>profile. If it did, it would be the entire profile.
>
>In the command set, the concept of a "closed connection" is
>distinct from a "Logout". The transport client within the target
>can "close" a connection (or either direction of a connection) at
>any time. When an ORB is queued for a "closed" direction, that
>status is returned in the completion notification of the ORB.
>
>> Also the current command set does not describe
>> the way to support multiple host connectivity.
>
>That is beyond the scope of the command set. The command set
>describes how to manage one connection. Multi-host connectivity
>may be (and should be) addressed elsewhere in the profile.
>
>> 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.
>
>This is beyond the scope of the command set. Your example is
>true if the "status" service is done as a separate LUN instead of
>a separate service found in a different Unit directory.
>
>Also, I'd recommend using LUN #0 since it must be supported. :-)
>
>> 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 would not recommend you using MLC 3.x for anything. Using
>P1284.4 is an option, and we discussed this in the PWG many, many
>months ago and _voted_ against going that direction. If you'd
>like to do independent work and present a written proposal at the
>next meeting, please feel free to, but that issue has been
>addressed.
>
>> 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 |
>
>And yes with multiple Units!
>
>> open/close from | YES | NO |
>> both peer | | |
>See above comment, the answer is YES for PWG, to exactly
>the same degree that it would be for 1284.4 over ??? over SBP-2.
>
>> predicatble | YES | YES |
>> API for WinSock2 | YES | NO |
>When was this a transport requirement?
>
>> standardization | 99% ALREADY | NOT YET |
>OK, show me the standard document.
>
>> Multi Host support| NO | NO |
>> |or YES/w LUNs | or YES/w LUNs |
>> ------------------------------------------------------|
>
>Let's look at some other characteristics:
> effecient: LESS | MUCH MORE
> -> Bus Utilization: low to moderate | high
> (credit pkts aren't) |
> -> Max size transfer: 64KBytes | 2 GBytes - 1
> -> Max amt of data
> queuable: as much memory as max (negotiated) size
> allocated by device transfer * MAX_TASK_SET_SIZE - 1
> for that connection
> -> Processing overhead: MUCH MORE | LESS
>
> Defined SBP-2 No | Yes
> command set
>
>> 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
>
>I doubt the chair would re-open a closed issue without
>a written complete proposal.
>
>1284.4 is insufficient by itself as a data link.
>Without a description of an SBP-2 command set,
>target device model, Config ROM description,
>and model of use, you have an incomplete solution.
>
>> 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.
>
>We already have a real model of transaction.
>I haven't heard any other complaints about it.
>
>--
>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