RE: [iSCSI] Resolution of management commands and multiple head of queue commands.

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

Julian,

The reject response requires the entire PDU header be returned.  That would
then require resources to store these headers for such a response.  If there
are resources to store this command, that then begs the question how many
must be stored even if only to reject?  Do you have any insight as how a
multi-connection task set resolve state with independent status
serialization?

Doug

> Immediate commands don't just get discarded - they are rejected.
>
> Julo
>
> "Douglas Otis" <dotis@sanlight.net>@ece.cmu.edu on 06-08-2001 16:57:42
>
> Please respond to "Douglas Otis" <dotis@sanlight.net>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "Ips" <ips@ece.cmu.edu>
> cc:
> Subject:  [iSCSI] Resolution of management commands and multiple head of
>       queue commands.
>
>
>
> All,
>
> iSCSI version .7 is a significant improvement.  Two areas that prompted a
> draft still seem unresolved.  Section 8.1 mentions a potential problem
> without addressing at least a suggested means of handling these
> situations.
> There are management commands that can not resolve with connection
> allegiance alone.  On another point, with no assurance or direct
> confirmation of Immediate Delivery Commands (IDC) and the potential for
> only
> a single command resource being allocated by the target, one must wonder
> how
> these commands are to be handled in practice.  Preventing more than a
> single
> command to be sent as IDC would be one solution as there is
> assurance there
> will be resources for only a single command.  If this were to be
> adopted as
> the method of handling these IDC commands, then such a flag could serve to
> allow an exception to the command window limit and avoid creating an
> overlaid command sequence count that then only serves to befuddle
> acknowledgement.  If multiple IDC commands need to be sent, then either
> waiting for acknowledgement or sending these commands consecutively where
> acknowledgement would indicate quickly status of these commands
> without the
> initiator pondering their status at a point in time where speed of
> resolution is important.
>
> Doug
>
>
>
>
>