RE: iSCSI: Session Partial Resolution

[Charles Monia <cmonia@NishanSystems.com>]

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