Subject: RE: P1394> RE: [PP1394:00137]

From: "Atsushi Nakamura" <[email-masked]>
Date: Sat, 10 Jan 1998 00:47:31 +0900

Just for clarification;

I think we have 2 choices in defining a 
"PWG profile CDB ",

1st choice:
If we decide to define the PWG profile CDB in a way that there is 
a 1284.4 specific CDB content encapsulated in a
"generic CDB frame structure" (generic, meaning supporting various upper
layers) which is intended to support other upper layers as well as 1284.4,
we will need to define 2 things:

 1)"generic CDB frame structure"...will include header to distingush 
              actual content (ex. 1284.4, or other alternative layers)

 2)1284.4 specific CDB content  ....actual content of CDB which is 1284.4
information

2nd choice:
If we decide that the PWG profile CDB will be 1284.4 specific,
in this case we will only need to define:

1) 1284.4 specific CDB content

In either case,
1284.4 supportive flag and packet header will be included in 
1284.4 specific CDB content.
I AGREE that this 1284.4 "short-cut" may be effective 
AS LONG AS it is not defined in the "generic structure" but defined in
1284.4 
specific content definition.
    
---
Now, my opinion on making he PWG profile CDB "generic" vs making it 
"1284.4 specific".
Since SBP-2 already has a mechanism to distinguish the contents of the CDB
("command_set_spec_id" and "sw_version"), I think we do not need a "CDB
frame"
to do the same thing.
SBP-2 itself is already "generic"
I think the PWG profile should define the CDB to be 1284.4 specific.

P.S. Alan,Nagasaka-san, I apologize if this discussion is already out of
synch.
      I have not yet had time to read the updated profile.   

Atsushi Nakamura
Canon Inc.

----------
> 差出人 : Nagasaka Fumio <[email-masked]>
> 宛先 : [email-masked]'
> CC : [email-masked]'
> 件名 : P1394> RE: [PP1394:00137] 
> 送信日時 : 1998年1月9日 16:59
> 
> Thank you Alan, for your great effort updating PWG profile document.
> 
> Larry wrote: (in "P1394> December Meeting Minutes")
> > H- Section 14, Multiple Logical Channels
> > Routing information needs to be provided here, not .4 Channel 
> information.
> リ	=> PSID and SSID should be removed from the command_block
> 
> At LA meeting, we agreed to remove PSID and SSID from CDB of normal
> command block ORB. However, now I would like to suggest to enclose
> 1284.4 supportive flag and 6 bytes 1284.4 packet header in CDB.
> 
> The reason is outlined below.
> 1)	IEEE 1284.4 is providing "out-of-band packet control flag" in the 
> header
> for 1284.4 packets.
> 2)	However if we does not enclose any 1284.4 information in normal 
> command
> block ORB. Fetch Agent needs to examine buffered data that wad 
> fetched
> after the fetch agent processed the ORB.
> 3)	Basically, out-of-band packet shall be extracted as soon as 
> possible.
> 4)	Thus we would like to make short cut to detect out-of-band requests 
> without
> reading buffer space associated with each ORB.
> 
> --------------------------------------------
> -------------------------------
> 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:	[email-masked] 
> [SMTP:[email-masked]]
> Sent:	Friday, January 09, 1998 7:38 AM
> To:	pp1394 ML
> Subject:	[PP1394:00137]
> 
>  << File: ccMail >>  << File: pwgprof.pdf >>
>

---

From: Fumio Nagasaka <[email-masked]>
Date: Mon, 12 Jan 1998 22:05:00 +0900

> [Shue, Greg]
> What leads you to think that a fetch agent is expensive?  Is it
> any more expensive than the CBT agent managing credit for a given
> CBT channel?  My guess is that the SBP-2 fetch agent is actually
> cheaper, especially since all the code to run the fetch agent
> could probably be reused across all instances.  But, I may be
> missing some complexity behind an SBP-2 fetch agent.

[Nagasaka, Fumio]
May be CBT credit management for multiple channels could be
expensive from memory requirements reason. And multiple login
requires SBP-2 target to have server capabilities. A server style
program consumes many threads and memory, also it brings
complexities into software development. Actually these difficulty
would be solved by software development effort.

But as you know, Windows NT5.0 SBP-2 initiator invokes one log-in
to the target device when PC boots up. And the initiator never log-out
until an user shut down his PC. I am afraid of that log-in function of
SBP-2 is not exported to other software, in Windows NT5.0 environment.

I mentioned two reasons above. Basically single login for one CBT
is merely simple. Because, SBP-2 layer shall be a simple data path
as data link layer for the transport protocol. 
--------------------------------------------
-------------------------------
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:	Saturday, January 10, 1998 11:29 AM
To:	Fumio Nagasaka
Cc:	[email-masked]
Subject:	P1394> RE: [PP1394:00137]

Hi,
Fumio wrote:
> My colleague pointed out same thing. I misunderstood usage of
> "out-of-band". But still I would like to enclose some control information
> in CDB. Because current specification has problem shown below,...
> 1) if one data channel is stalled, the fetch agent does not pass data
> toward upper layer ( in this case upper layer is CBT).
> 2) thus the fetch agent stops consuming data from a linked list of ORBs.
> 3) By the way an application would append new ORB which requests
> status reply as the application need to solve the problem. (may be
> new ORB uses other logical channel. But the logical channel number
> is enclosed in data buffer associated with this ORB)
> 4) The fetch agent does not read this new data buffer, because he is
>     busy. And he does not have any internal FIFO space to read new data.
> 5) Finally the fetch agent does not pass new request to CBT. He will
> know that new ORB should be delivered to other logical channel, thus
> he could do that, but he didn't.... It is too late.
> 
> We can provide ORB pre-fetch queue as the front end process, before
> the fetch agent really consumes data stored in data buffer. And I believe 
> that ORBs shall *not* be executed in order. And I prefer to choose
> one login for one transport. Thus I want to say "A linked list of ORBs may
> contain many requests to various logical channels".

[Shue, Greg]
As I understand it, ORB "pre-fetching" is a desirable (required?)
characteristic of out-of-order processing and out-of-order
completion.  Either there is one login for one transport, and no
multiplexing needs to be done at the SBP-2 level, or there is one
login for multiple transports, so routing information is required
in the ORB CDB (yuck!  :-).  The whole purpose of CBT is to
provide multiplexing and data pacing such that whatever data
packets are sent already have the memory space reserved at the
other end, so all packet transfers can be completed immediately.

[Shue, Greg]
I think we need to choose whether multiple transports are
supported for one login or not.  (Haven't we already decided no?)
If one transport per login, and one login per transport, then
routing is not an issue.

> "One login for one logical channel" solves this problem. However multiple
> login supportive SBP-2 target is very expensive.

[Shue, Greg]
What leads you to think that a fetch agent is expensive?  Is it
any more expensive than the CBT agent managing credit for a given
CBT channel?  My guess is that the SBP-2 fetch agent is actually
cheaper, especially since all the code to run the fetch agent
could probably be reused across all instances.  But, I may be
missing some complexity behind an SBP-2 fetch agent.

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