Re: iSCSI : Review Feedback on iSCSI Rev 06

[Santosh Rao <santoshr@cup.hp.com>]

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.




> 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.


> 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.
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard