Re: iSCSI : Review Feedback on iSCSI Rev 06

[julian_satran@il.ibm.com]

comments in text

Julo

Santosh Rao <santoshr@cup.hp.com> on 23-05-2001 04:49:40

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI : Review Feedback on iSCSI Rev 06




Julian,

Thanks for the clarification. A few additional queries below.

Regards,
Santosh

-----------------------------------------------------------------------------------


julian_satran@il.ibm.com wrote:

> 1) Suggest re-naming the following in the interests of better
> clarity :
>
> a) Rename the ExpDataSN in SCSI Response PDU to EndDataSN as was used in
> the previous version of the draft. (indicative of being the final Data
> sequence
> number.)
> +++ Meaning has changed - 0 means none (it was fffffff before) +++

Have the semantics of ExpDataSN in the SCSI Response PDU changed (?).
From the description, it sounds like it is a count of the no of READ
Data PDUs sent by the target for the command. 0 implies none were sent.
(no data xfer). Hence, the name EndDataSN would be fitting since it
really is the last DataSN the target used for this READ I/O.


---ExpDataSN is what would be the next DataSN (not the last). 0 means none
expected, 1 means number 0 was sent and number 1 is expected (if at all)!
---

> 3) Why does the new draft limit the size of text commands and nop
commands
> to
> 4096 bytes ? What is the rationale behind the magic number selection of
> 4096 ?
>
> Since DataPDULength is defined in units of 512 bytes, how does iSCSI deal
> with
> fragmentation caused due to the usage of a DataPDULength < 4K and an
> attempt to
> perform a 4K text , login or nop operation ?
>
> I believe such scenarios were discussed in an earlier thread
> titled "Fragmentation & Reassembly issues in iSCSI."
> (http://ips.pdl.cs.cmu.edu/mail/msg03031.html) and the resolution was to
> enforce a restriction that the size of a login, nop & text operation be
> limited to DataPDULength (?).
>
> +++ we decided to drop negotiating trivia. A fixed maximum is more
> practical
> and 4096 will no create inconvenience for a long time   +++


> 5)  Section 2.8.3
> "The data length of a text command or response SHOULD be less than
>    4096 bytes."
>
> suggest re-wording the above to :
> "The data length of a login, nop & text command or response MUST be less
> than
>  DataPDULength. For the leading session login, the length of the login
> command
>  MUST be less than 512 bytes."
>
> The above will ensure that login, text & nop operations will not result
in
> fragmentation.
>
> +++ I have a hard time understanding the argument +++


One basic question. Does DataPDULength govern the max length of SCSI
Data PDUs only or all iSCSI PDUs ? This does'nt come across clearly from
the definition. If this only governs SCSI Data PDUs, then, I'd suggest
the following re-wrod to make it more clear in the definition on page
129 (Appendix E) :

Change :

"Initiator and target negotiate the maximum data payload supported for
   command or data PDUs in units of 512 bytes."

to :
"Initiator and target negotiate the maximum data payload supported for
   SCSI command or data PDUs in units of 512 bytes."

The above issues (3) & (5) are relevant if DataPDULength governs the
length of all iSCSI PDUs.

--- OK ---
> 9) Section 2.18.1
>
> "Target requests logout".
>
> Suggest removal of the above option. A target that needs to logout would
> use
> either :
> "Target will drop the connection"
> or
> "Target will drop all connections"
>
> The "Target requests logout" also does not allow the target to specify
> which
> flavor of logout it wishes to receive. It is better to remove this option
> and
> use only a single scheme.
>
> +++ The reason for introducing it was to allow a maintenance operation
> (getting out a NIC card) to start
> at the target. However only the initiator knows when the connects gets
> quiet. This is why will have to keep this form. The other 2 are for
> emergency handling +++

Why is "target will drop connection" or "target will drop all
connections" not sufficient for this purpose ? In this case, the target
would send the async message, drop the connection/session and abort all
outstanding I/O. The initiator on seeing the async message would
clean-up all outstanding I/O on that session/connection and would
attempt to re-login after LogoutLoginMinTime.

--- Because there might be commands in flight that the target does not know
about when issuing the request ---
 - santoshr.vcf