Subject: FW: P1394> unordered execution

From: "Turner, Randy" <[email-masked]>
Date: Sun, 8 Mar 1998 22:24:59 -0800

Sorry everyone, my comments on the previous message were not 
Discernable or readable from Nagasaka-san's mail. I've modified the
Message so you can pick out my comments. My comments are 
Marked <RT>

Randy

-----Original Message-----
From:	Turner, Randy [SMTP:[email-masked]]
Sent:	Sunday, March 08, 1998 9:10 PM
To:	'Nagasaka Fumio'; [email-masked]
Cc:	PWG-C mailing
Subject:	RE: P1394> unordered execution

See my comments below...
Randy

	-----Original Message-----
	From:	Nagasaka Fumio [SMTP:[email-masked]]
	Sent:	Sunday, March 08, 1998 5:14 PM
	To:	[email-masked]
	Cc:	PWG-C mailing
	Subject:	P1394> unordered execution

Does SBP-2 printing protocol need to have out of order execution
for ORB
list?
Let me assume one case shown below.
When an initiator puts an input ORB in linked list of ORBs.
[out::ORB] - [out::ORB] - [out::ORB] - [in::ORB] - [out::ORB] ?
If our SBP-2 target consume them by in order execution. The
target
will stop at fourth ORB and will examine whether it has reverse
data
or not. It is normal and reasonable.
We might have an analogy of C language source code outlines below.
	{
	    putchar(..);    // step 1
	    putchar(..);    // step 2
	    putchar(..);    // step 3
	    getchar( );     // step 4  * INPUT*
	    putchar(..);    // step 5
	    ?..
	}
This process will stop at step 4 and will wait input from TTY.
OK?, next, let?s go back to SBP-2 target problem. Even if
the target does not have any thing to replay at step 4. The
transport layer shall *not* return ?no data flag? or ?something
to say there is nothing to reply?. The target?s application may
reply
?no data? , ?this is data? or any thing. This action shall be
taken
by application?s responsibility.

<RT>Yes, the requesting application code would not issue a READ
operation if no application <RT>response was expected.  The application
would return an application level response *no-<RT>data*, or the
application would return some other appropriate response.

By the way, for second case is shown below.
When the initiator has some requests which shall be delivered to
each logical channels like these,?(#k means logical channel
?k?).
[out::#1::ORB] - [out::#1::ORB] - [out::#1::ORB] - [in::#2::ORB]
-
[out::#1::ORB] ?
Then if the transport layer in the target waits reverse data is
passed
through from the application, fifth ORB which shall be delivered
to
channel #1 will not be delivered while the transport is pending
on
fourth ORB.

<RT>We should never have a single ORB list processing multiple logical
channels. Each ORB <RT>list handles a single logical channel, at least
according to the current profile document <RT>decisions we have made.

If our SBP-2 protocol may allow out of order execution. The target is
able to consume sixth ORB earlier than fifth. Then the protocol provides
concurrent executive opportunity for each logical channels.
*	Shall the transport provide out of order execution ?

I want to say no. The initiator shall place [input::ORB] if it expects
reverse data will be sent from the target. I would like to say, the
currents SBP-2 protocol has enough facility.
I am curious why unordered execution is required for ?HPT?.
May be there are something I am missing.
Thank you, best regard.
	--------------------------------------------
	-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to [email-masked]

---

From: Nagasaka Fumio <[email-masked]>
Date: Wed, 11 Mar 1998 10:13:19 +0900 (JST)

Dear Randy,
Thank you, you pointed what I want to say.

On Sun, 8 Mar 1998 22:24:59 -0800

> according to the current profile document <RT>decisions we have made.

We need to invoke some login(s) to make some fetch agents.
I don't like it, because,...

1) Multiple logical channel shell be involved with a LUN.
   For example, FAX LUN may have several logical channels.
   According to the current profile document, we are
   required to invoke login(s) to a LUN or to some LUNs.

2) However Sekine-san told us, a consumer OS invokes one
   login to a LUN.

3) So we need to have a facility to provide MLC in a single
   ORB List.

The current profile document is good and well designed. Even
so we need to revise some points to make it is executable on
existing Operating System.
-----
Fumio Nagasaka
EPSON Software Development Laboratory Inc.,
TEL: +81 268 25-4111 // FAX: +81 268 25-4627
HomePage = http://www.venus.dti.ne.jp/~fumiona/

---

From: Greg Shue <[email-masked]>
Date: Wed, 11 Mar 1998 09:07:30 -0800 (PST)

[Shue, Greg]
Your concern comes because you have a new requirement under issue 1:

  multiple channels being _associated_ with a single session (login
  to a LUN).

This should have been brought up many, many months ago.
The current requirements are for multiple _independent_ channels.

No discussion has occurred about what the standard FAX model
should look like.  Apparently your model is different from
others as no one else has raised this requirement.

If we want to have a standard FAX driver stack, then I would
encourage us to start an e-mail discussion about how a standard
FAX device should be modeled.

I'm not suprised that a consumer OS provides one login per LUN.
Nothing has been clearly stated about how SBP-2 LUNs should
be treated.  The Microsoft SBP-2 implementation has it's own
behaviors which must be addressed.  I don't have any issues
with saying that "this is the standard way of supporting XXX
device."

Nothing prevents providing a 1284.4 service on top of the current
proposal.  This may be the direction you choose to go if your FAX
service is modeled as having more than a unidirectional SEND
channel and a unidirectional RECEIVE channel, and you don't want
to model each data source/data sink as a different service.

I have a couple of issues with supporting "MLC" over a single ORB
list, so I'll assume you meant "CBT" (1284.4).  That provision
already exists by using the current proposal in packet mode and
making the supported packet size (per direction) be able to hold
the largest packet transferred in that direction.  Since the
current proposal supports packets of 65535+6 bytes, nothing needs
to be changed.  The nature of CBT will prevent the fetch agent
from blocking while waiting for a data transfer.  No data
transfer commands will be sent which could not be immediatly
processed.  No out-of-order processing is required.

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			[email-masked]
----------------------------------------------------------------