RE: iSCSI: Session Partial Resolution

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

Charles,
I thought we were all together until you said, ...have the initiator budget
one "credit" to be used for this purpose.
Up until that statement there had been no mention of Credit, and I am not
sure why we need to bring that concept in.

Randy (HAAGENS),
You said:
"The question of the storage controller's overcommitting command queue
credits has been raised.  Our initial thought was that this would not be
allowed.  But if it must be allowed, then we could extend the command
sequencing scheme to allow to target to drop commands and later demand
their retransmission.  The command sequence numbers would ensure that,
ultimately, all commands are delivered in order, with no commands lost or
duplicated."

I am confused since I do not find the work "Credits" anywhere in the Draft.
With all the stuff that has been going around about credits, perhaps you
could either tell me what you meant by credits, or tell me where that is
specified in the Draft.  The way it has been use recently is to clone the
approach that FC uses.  This seems confusing, since I do not understand why
that is needed with TCP.  Therefore, I keep thinking that I am
misunderstanding you.

In any event, based on what Charles said (in the rest of his note) I got
the feeling that there was only Two "channels" (or connections) needed per
Session to prevent the blockage folks keep talking about.  One for commands
and one for data, esp.  since Charles made the point that control functions
should be on the same connection with commands.  Do you agree that a double
connection per Session solves most of the problems we have been talking
about?
.
.
.
John L. Hufferd



Charles Monia <cmonia@NishanSystems.com>@ece.cmu.edu on 09/26/2000 05:35:22
PM

Sent by:  owner-ips@ece.cmu.edu


To:   "HAAGENS,RANDY (HP-Roseville,ex1)" <randy_haagens@hp.com>, "David
      Black (E-mail)" <black_david@emc.com>
cc:   "IPS (E-mail)" <ips@ece.cmu.edu>
Subject:  RE: iSCSI: Session Partial Resolution



Hi:

See below for a few comments on flow control.

> -----Original Message-----
> From: HAAGENS,RANDY (HP-Roseville,ex1) [mailto:randy_haagens@hp.com]
> Sent: Tuesday, September 26, 2000 7:51 AM
> To: David Black (E-mail)
> Cc: IPS (E-mail)
> Subject: RE: iSCSI: Session Partial Resolution
>
>
> David,
>
> I. Re: proposed points of consensus
>

<Material deleted>


> (1) Command sequencing was added to the draft for several
> reasons, but the
> important point here is that command flow control is
> necessary when using a
> single TCP connection in order to prevent a command queue
> full condition
> from preventing the reception of write data.  We could just
> leave command
> flow control to the good behavior of the SCSI layer (there is no SCSI
> mechanism defined for it, and so it is
> implementation-dependent), but we
> decided that it was legitimate to treat it at the iSCSI
> "transport" layer,
> since from SCSI's pov, it is a transport problem.  Command
> sequencing also
> solved two other problems (ordered command striping and
> recovery from TCP
> connection failure), so it seemed like an efficient mechanism overall.
>
> Some have objected that command windowing may result in the
> command queue's
> being blocked, and urgent commands' not getting through.  If
> I recall the
> draft correctly, we made provision for this with the notion
> of unnumbered
> commands.  These can be sent at any time by the initiator;
> but since they do
> not have a reserved place in the command queue, their
> reception must be
> considered unreliable: the target can drop them at its discretion.  I
> believe this situation is familiar to the T10 community, and
> acceptable from
> a SAM-2 perspective.  But if not, we could create a separate,
> sequenced,
> command queue for urgent commands.
>

Hi:

I think the above proposal is headed in the right direction with respect to
command windowing. I'd like to make a few observations and suggestions
however.

1.  I'm inclined to reserve the use of unnumbered "slots" for task
management functions, such as "abort task", etc.

2.  As I recall (possibly not very accurately) SAM-xx states that an
initiator should not have more than one pending task management request at
a
time.  In general, such requests are "think-time" limited and therefore non
blocking, so this seems not to be a problem in practice.

3. It's important that this set of control functions flow over the same
control connection that's used for commands (ie.  these functions need to
flow through the command delivery pipe).  Otherwise their behavior is
indeterminate.  An example is an "abort task" function which arrives at the
target while the command to be aborted is still in transit.

4.  Considering the rule of allowing only one pending task management
request at a time,  it might be sufficient to have the initiator budget one
"credit" to be used for this purpose.


> The question of the storage controller's overcommitting command queue
> credits has been raised.  Our initial thought was that this
> would not be
> allowed.  But if it must be allowed, then we could extend the command
> sequencing scheme to allow to target to drop commands and
> later demand their
> retransmission.  The command sequence numbers would ensure
> that, ultimately,
> all commands are delivered in order, with no commands lost or
> duplicated.
>

A good idea in my opinion.

<remainder deleted>

Charles