Subject: RE: [PP1394:00147] Re: P1394> 1284.4 over SBP-2

From: Nagasaka Fumio <[email-masked]>
Date: Fri, 13 Feb 1998 19:54:02 +0900

Greg Shue wrote:
>To highlight the issue:
>   Exactly how does an initiator peer which supports CBT receive a 
>   Credit packet from the target at any indeterminate time?
>This is not provided directly by 1284.4.  How are you planning on 
>solving it for your implementation of option A?

1)	The initiator place “CreditRequest” packet in an out-ORB.
2)	If the target find an in-ORB in the linked list of ORBs, target
fill out
	the buffer associated this ORB with “CreditRequestReply”
packet.
3)	If the target could not find any in-ORB in the linked list of
ORB,
then the target send unsolicited status which requests the initiator
to provide an in-ORB in the list. Then go to step #2. 

Am I missing any steps?
I think step #3 becomes overhead. So CBT supportive SBP-2 profile
does not mark higher speed than pure SBP-2 transaction.

--------------------------------------------
-------------------------------
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:	Friday, February 13, 1998 4:58 AM
		To:	pp1394 ML
		Subject:	[PP1394:00147] Re: P1394> 1284.4 over
SBP-2

		> 
		> This message is in MIME format. Since your mail reader
does not understand
		> this format, some or all of this message may not be
legible.
		> 
		> ------ =_NextPart_000_01BD3784.4C5B70D6
		> Content-Type: text/plain
		> 
		> Dear Eric,
		> Dear Larry,
		> 
		> Please find an attached document which shows issue
Eric and myself
		> had discussed at December 3, 1997.
		>  <<Generation.PDF>> 
		> I am writing printer drivers that covers first
generation of 1394
		> printing.
		> These printer drivers are supporting option A.
		> <<
		> A-	1284.4 with SBP-2
		> B-	New SBP-2 command set with SBP-2
		> >>
		> I also prefer to choose option A at least in these
couple of years. One
		> of my reason is market reason same as Larry. Another
my reason is
		> technical reason. As I mentioned before, a target peer
which supports
		> CBT allows initiator peers to send ORBs safely. Any
data link layer
		> which services only one data path has difficulties to
support multiple
		> logical channels. Because, if once one of logical
channels had been
		> stalled, other requests that goes same data path will
be stalled.
		> The CBT set the data link layer free from these
difficulties.

		Yes, any link which supports only one data path has
difficulties
		to support multiple logical channels.

		This is exactly why I identified the major issue between
option A
		and option B as whether multiple functions within a
device are
		provided via:

		  MUX layer for multiple functions access presented as
one Unit (option A)
		vs.
		  separate units for each function  (option B)

		This is really the choice between the two options.

		The other topic of discussion under this thread deals
with how to
		use SBP-2 to provide independent, opposing,
unidirectional data
		streams over the same login.  Whether option A or option
B is
		chosen, the issue of providing the specified
bidirectional
		service to the layer above SBP-2 still exists.  And, I
think it's
		exactly the same issue.

		To highlight the issue:

		  Exactly how does an initiator peer which supports CBT
receive
		  a Credit packet from the target at any indeterminate
time?

		This is not provided directly by 1284.4.  How are you
planning on
		solving it for your implementation of option A?

		> -------------------------------
		> Fumio Nagasaka
		> Epson Software Development Laboratory Inc.
		> Tel +81 268 25 4111,  Fax +81 268 25 4627
		> E-mail to [email-masked]

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

---

From: Greg Shue <[email-masked]>
Date: Tue, 17 Feb 1998 11:06:21 -0800 (PST)

You are not missing any steps, BUT you are missing the point.
The issue wasn't how to deal with CreditRequest packets (which
is a transaction which follows the flow of data), but how to
deal with a _Credit_ packet (which is a transaction which runs
opposite to the flow of data for which credit is being given).

The transaction direction is completely different and so requires
a completely different mechanism.

To illustrate the difference:

  Data flows from PC to printer
  PC runs out of credit, so issues a CreditRequest to the printer.
  Printer gives the CreditRequestReply back to the PC.

     NOTE: This must be done immediately to allow the PC to
     do other command trasactions and avoid blocking the CBT
     channel.  Otherwise, additional command channel credits
     must be supported and must exist.
     
     Since this must be done immediately, it may be returned with
     zero credit.  In this case, the PC will not ask for additional
     credit because the printer remembers the request and will
     _spontaneously_ give credit when buffer space is available.
     This is done with a Credit/CreditReply transaction initiated
     by the printer, not another CreditRequest/CreditRequestReply!

  PC waits for more credit, WITHOUT polling for credit.
  Printer has buffer space available for PC, so fills out a
    Credit packet to be sent to the printer...

      How is this packet sent?

      What needs to happen is the PC needs to read the packet,
      process it, and send a CreditReply packet in response!
      The mechanisms beneath the CBT protocol need to support this,
      and so we must understand _exactly_ how this is done
      since the Credit packet from the printer could be ready
      at _any_ point in time.

  The difference between Credit and CreditRequest is similar to
  the difference between data push and data pull.

CBT & SBP-2 combined could never match SBP-2 by itself in terms of
performance.  The overhead of explicit credit management guarantees
that.

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