Subject: RE: P1394> unordered execution

From: Nagasaka Fumio <[email-masked]>
Date: Fri, 13 Mar 1998 19:05:18 +0900

Greg Shue wrote:
> [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.

I brought up this idea at 1394 PWG on September 15, 1997.
Please show the meeting minutes posted below.  Was it many,
many months ago?

<<<
ftp://ftp.pwg.org/pub/pwg/p1394/mtg091597/9709_min.pdf

III.B.2 Fumio Nagasaka-Epson
SBP2 Printing Model
Minimal requirements for PC Printing protocol
Multiple Logical Channels
Flow Control
Multiple Hosts Connectivity
Multiple Targets Connectibility
Reconnection after bus reset
Multiplexing to support multiple clients for the transport.
Implementation of multiple logical channels through SBP2
How many logins does one printing session require
    *1-Build MLC internally within one login*
    2-Requires multiple login as same number of logical
           channel
    3-Prioritize logins

Unfortunately we spent many months getting few results.

Greg Shue wrote:
*	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 just said for example any unit may have multiple logical channels.
Not only printer but also scanner or FAX could have MLC.
I have no urge to discuss FAX driver stack in this e-mail.

Greg Shue wrote: (reformatted)

> ….. 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 immediately
> processed.  No out-of-order processing is required.

Agreed. I think we can eliminate out-of-order processing model.
My motion is to vote elimination of out-of-order processing model
at Portland meeting.
To have productive result we must move forward. We shall start
from Greg and Alan’s proposal.
-------------------------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to [email-masked]

	-----Original Message-----
	From:	Greg Shue [SMTP:[email-masked]]
	Sent:	Thursday, March 12, 1998 2:08 AM
	To:	Nagasaka Fumio
	Cc:	[email-masked]; [email-masked]
	Subject:	Re: P1394> unordered execution

	[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.

		> On Sun, 8 Mar 1998 22:24:59 -0800
		> “Turner, Randy” <[email-masked]> wrote:
		> 
			> > <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.
			> > 
		> 
		> 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/
		> 
		> 

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

---

From: Akihiro Shimura <[email-masked]>
Date: Mon, 23 Mar 1998 23:12:51 +0900 (JST)

Hello, All,

I have prepared an alternative proposal for bi-di communication
mechanism utilizing unordered model to overcome inefficiencies
potentially caused by the ordered model.

Unfortunately, I cannot attend the next Portland meeting, so 
Mr.Isoda from Canon will make a presentation on this document in the
meeting instead of me.

I appreciate if 20 or 30 minutes slot is assigned for the presentation.

Please find attached model part of the document and comment below....

On Fri, 13 Mar 1998 19:05:18 +0900

> Agreed. I think we can eliminate out-of-order processing model.

I don't think so.

Though the CBT may prevent deferring(re-ordering or retrying) the ORB
for initiator-to-target transfer in the initiator, there still exists
an inefficiency on target-to-initiator transfer.
In order to prevent ORB re-ordering in the initiator, it is necessary
to guarantee the completion of each request. In case of target-to-
initiator transfer, the CBT may only guarantee the receiving space on
the initiator and does not necessarily guarantee the completion on
the target because the target may not be ready to send a data. 
To prevent this, it will be necessary for the initiator to defer
appending target-to-initiator request ORB until ready-to-send is
indicated by the target. Because appending pending read request to
the task set requires indication from the target and the initiator
need appending process based on the indication after the indication
arrived, this procedure will not so efficient as shown by the spirit
of SBP-2.

I have prepared a "Model" part of a document utilizing "Unordered
Model" to overcome these inefficiencies potentially caused by the
"Ordered Model".
Though the model part of the document(Simple HPT or SHPT) is revised
>from the HPT document, the model itself is very different from the
original HPT model.

In this SHPT model, re-ordering the ORB between write and read
request in the initiator is not required at all because the target
does re-order between them.
In the "ordered model", the ORB re-ordering in the initiator will
occur whenever the requested order in the task set is not appropriate
for the "target" to execute.
Because the ORB re-ordering in the initiator requires aborting tasks
by the target, re-appending the tasks to the task list by the
initiator and re-fetching the tasks by the target potentially in
non-linear order of retries, it will be expensive for the initiator,
the target and the bus.

Also, in this SHPT model, the initiator does not need to synchronize
with the indication from the target to append the pending read request
to the task set because the pending state is achieved in the execution
agent on the target.
In the "ordered model", if the initiator limits the number of
requests in the task set very small (e.g., one) to avoid potential ORB
re-ordering in the initiator, the target will enter suspend state
frequently before requests are appended to the task list. In this case,
the bandwidth benefit of the SBP-2 will be reduced by the latencies on
each side.

In addition, this SHPT model does not require to limit maximum data
payload size, and does not need to prepare the maximum data payload
size of (intermediate) receive buffer to guarantee the delivery.

Regards,

Akihiro Shimura
--
 Akihiro Shimura ([email-masked])
 Office Imaging Products Development Center 3
 CANON INC.

---

From: Greg Shue <[email-masked]>
Date: Mon, 23 Mar 1998 09:55:37 -0800 (PST)

> the target because the target may not be ready to send a data. 

A CBT-style mechanism covers data flow in both directions.

> arrived, this procedure will not so efficient as shown by the spirit

The "ready-to-send indication" from the target is implicit with
each credit.

> the bandwidth benefit of the SBP-2 will be reduced by the latencies on

I think you're missing one big clause about the Unordered Execution
Model.  SBP-2 spec rev 3a, Section 4.6 states:

  "The unordered model is usually appropriate for direct-access
  devices for which no poisitional or other context information
  is inherited from one command to the next."

  "Unrestricted reordering leaves the responsibility for the
  assurance of data integrity with the initiator.  If the integrity
  of data on the device medium could be compromised by unrestricted
  reordering involving a set of active tasks, {T0, T1, T2, ... Tn}
  and a new task T', the initiator shall wait until {T0, T1, T2, ... Tn}
  have completed before appending T' to an active request list."

We have talked quite a bit in various threads on this reflector
about the "spirit" of SBP-2.  In continuing with this emphasis,
the spirit of the Unordered Execution model is _completely_
unordered.  Since the nature of our buffer transfers are ordered
within each direction, the previous clauses really require no
more than one message be queued for each direction at a time!
Anything else is really not consistent with the Unordered
Execution model.

The only possible supported way around this is to set the 'q' bit
in the Logical_Unit_Characteristics entry to be one and define a
command-set dependent queuing model.  But I'm still not sure that
the interpretation of the 'o' bit in the same entry is affected.

> size of (intermediate) receive buffer to guarantee the delivery.

In order to support transient link interruptions, either
additional restrictions are placed on ORBs being queued (that
they MUST be explicitly completed or aborted to be removed from
the task set), or maximum sizes must be set.  If neither of these
mechanisms are defined, then it is possible for the data stream
to be corrupted because of a Bus Reset which resulted in a
partially processed ORB being requeued, or a new ORB being
queued, but interpreted as a partially fetched one.

---

From: Akihiro Shimura <[email-masked]>
Date: Tue, 24 Mar 1998 22:02:25 +0900 (JST)

See comment below....

On Mon, 23 Mar 1998 09:55:37 -0800 (PST)

> Akihiro Shimura wrote:
(snip)
>   have completed before appending T' to an active request list."

Thank you for the clarification.
In this mean, the SHPT model will not be an "Unordered Model" under
the "Basic task management model" but be sort of an "Unordered Model"
under the "Queuing Model".

> Anything else is really not consistent with the Unordered

I'm not sure but I suppose the SHPT model will be still in the "spirit"
of SBP-2 because its features seem to be maintained.

> the interpretation of the 'o' bit in the same entry is affected.

The SHPT model will set the 'q' bit as it was in the original HPT.

> queued, but interpreted as a partially fetched one.

The SHPT model requires two things as briefly described in the
document.
One is that the initiator shall keep up the "CONTENTS" of buffer until
the request is completed, and shall keep up the relationship between
"sequence identifier" and associated buffer (contents).
Another is that the target shall maintain the "sequence identifier"
and "offset" for the incomplete request, and shall be responsible in
avoiding the duplicated execution.

Since the synchronization between the initiator and the target may be
lost in the way that initiator is behind (the target is ahead), the
target examines the "sequence identifier" provided just after the
re-synchronization is taken by the initiator(possibly behind) and the
target completes without duplicated execution.
Because the "CONTENTS" of buffer and related "sequence identifier"
are kept up by the initiator and the target avoids the duplicated
execution by using maintained "sequence identifier" and "offset", the
data stream will not be corrupted.

Am I still missing something?

Akihiro Shimura

---

From: Akihiro Shimura <[email-masked]>
Date: Wed, 1 Apr 1998 14:46:34 +0900 (JST)

Hello, All,

Preliminary presentation material and documentation of the unordered
queuing model(SHPT) are now available at;

ftp://ftp.tokyoweb.or.jp/pwgc1394/pub/proposals/canon/SHPTprs4.pdf
and
ftp://ftp.tokyoweb.or.jp/pwgc1394/pub/proposals/canon/SHPT04d.pdf

Regards,

Akihiro Shimura

On Mon, 23 Mar 1998 23:12:51 +0900 (JST)

(snip)