RE: iSCSI : Command Ordering Proposal.

["Douglas Otis" <dotis@sanlight.net>]

Santosh,

I was trying to view iSCSI as isolated from either SCSI or TCP.  The mixing
of SCSI tags or TCP Acks together with Client/Server sequencing clouds this
conversation.  By resources, I was focused only on the iSCSI function and
not either TCP or SCSI.  SCSI uses tags, TCP uses its sequence number.
iSCSI uses CmdSN and StatSN.  An iSCSI PDU may require repeating if ExpCmdSN
does not acknowledge reception due to digest failure perhaps.  This is a
thorny issue as there is no sense of time to allow recovery.  If there is a
digest error, should the server tell the client via a type of selective
acknowledgement or by means of reporting a digest error on who knows what?

iSCSI v3:
   "It may happen that a target receives a message with a format error
   (inconsistent fields, reserved fields not 0, inexistent LUN etc.) or
   a digest error (invalid payload or header). The target returns the
   header of the message in error as the data of the response."

   "When a target receives an iSCSI data PDU with a data payload digest
   error, it MUST discard it and request retransmission with a R2T.
   When a target receives an iSCSI PDU with a header digest error or a
   payload digest error in anything but a data iSCSI PDU it MUST answer
   with a Reject iSCSI PDU with a Reject iSCSI PDU with a Reason-code of
   Digest-error."

Here is where a sequence is lost.

   "When an initiator receives an iSCSI data PDU with a data payload
   digest error or any other iSCSI PDU with a header or payload digest
   error it MUST discard it, and restart the task - the later provided
   it could recognize the Initiator Task Tag.  If the initiator can't
   recognize the Initiator Task Tag, (e.g., a header digest error) the
   initiators MUST logout the connection and restart it (including
   restarting all outstanding tasks)."

From the client's perspective, its PDU was sent only if acknowledged.  The
same should be true for the server.  Rather than using this level of
handshake, a restart of the SCSI command is seen as recovery but then we
lose any sense of sequence nor have these handshakes been fully utilized in
establishing a reliable link.  Using bad data to restart a command?  That
does not seem a means of ensuring reliability.  View iSCSI as a transport
independent of both TCP and SCSI and then we can make progress on
understanding how this should work.  A brew of all three is where we are
now.

Doug

> Doug,
>
> I'm not sure if we are speaking the same issue here. Can you
> please elaborate further on your concerns.
>
> The handshake being discussed by me does NOT have to do with
> freeing resources. It is a handshake b/n the target &
> initiator on the CmdSN/ExpCmdSN, so that "retry" commands
> from initiator to target remain with the (ExpCmdSN, MaxCmdSN)
> window.
>
> Resources at the target end are de-allocated when it receives
> an ExpStatSN for the StatSN. (IOW, resource de-allocation has
> to do with StatSN ACKs from the initiator, not CmdSN).
> If a target were not to implement status recovery, resource
> de-allocation can occur once a TCP ACK is received for the
> SCSI Response PDU. (if a mechanism were to exist to identify
> that all the octets that constitute the Status PDU have been
> ACK'ed.)
>
> This also brings up an interesting issue which is :
>
> If the target needs to hold onto its status PDU until at least
> the TCP ACK is received for all of the bytes that constitute
> the PDU and there is no easy mechanism to associate b/n
> a TCP ACK and all bytes of the Status PDU being ACK'ed,
> the simplest approach becomes de-allocation of status &
> I/O resources based on ExpStatSN.
>
> If that is the case, the spec should change
> "targets MAY implement status recovery"
> to "targets MUST hold onto status PDU until ExpStatSN" update
> is received.
>
> Regards,
> Santosh
>
> >
> > Douglas Otis wrote:
> > >
> > > Matt,
> > >
> > > Whether you use the CmdSN or the tag to associate the retry,
> the CmdSN is
> > > still used as a means to handshake freeing of resources and
> not the tag.
> >
> > You are wrong.  It specifically states in the document in 1.2.2.1:
> >
> > "CmdRNs are significant only during command delivery to the target.
> > Once the device serving part of the target SCSI has received a
> > command, CmdRN ceases to be significant."
> >
> > Any resources the target allocates must be based on the task tag.
> >
> > -Matt
> >
> >
> >
> > >  It
> > > seems like a cleaner solution not to include exceptions on
> maintaining the
> > > sequence just to allow this type of non-sequential use.
> Clearly there is an
> > > alternative that has benefits. Simply have the target allow
> exceptions based
> > > on the command or task attribute and not drop the ability to
> handshake.  I
> > > am aware of the present concept, but you did not speak about
> any downside to
> > > this alternative.
> > >
> > > Doug
> > >
>
>
> --
> #################################
> Santosh Rao
> Software Design Engineer,
> HP, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> #################################
>