RE: iscsi : default iscsi mode page settings.

["Elliott, Robert" <Robert.Elliott@compaq.com>]

> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Thursday, September 20, 2001 6:44 PM
> ...
> 2) Defaults on iscsi mode pages:
> ================================
> Typically, no protocol defaults are specified for mode page settings.
> Initiators should be able to function correctly without 
> having to do either mode select or mode sense. Any initiator that 
> needs advanced settings should be prepared to do the extra work of 
> issuing mode sense/select to enable these features. It should NOT 
> be the other way around. (i.e. simple initiators should NOT have to 
> first issue a mode select in order to ensure
> proper operation of their sessions).

If an initiator cares about any settings it better run MODE SENSE
to set them.  In a multi-initiator environment with various kinds
of reset events occuring on the SAN, an initiator can't be sure 
of the state of a mode page.  (see the tape problem discovered by 
Veritas in FCP-2 public review; tape mode pages were reset without
the knowledge of the application, breaking backups).

> Logical Unit Control Mode Page
> ==============================
> This mode page definition can be removed from the iscsi draft since it
> governs per-LUN state information and LUN state is the realm of the
> SCSI ULP. In particular, it is the SCSI ULP that decides whether to
> enable/disable CRN, since CRN is generated by the SCSI ULP.
> 
> Thus, it is un-clear why the "Enable CRN" is negotiated at a 
> protocol level & not at a SCSI ULP mode page such as the 
> Control Mode Page. (??).
> 
> Could anybody comment on why CRN (a ULP feature) needs to be 
> enabled in an iscsi protocol mode page ?
> Perhaps, for FCP it made sense to negotiate something like 
> "Enable CRN" in FCP specific mode pages, since early revisions 
> of FCP did'nt specify the CRN field in FCP_CMD IU and so, 
> the "Enable Precise Delivery" (EPDC) bit was required to 
> be queried/set using mode sense/select, prior to using CRN.
>
> Since iscsi supports CRN in its scsi command pdu from its 
> initial rev, I don't see why "Enable CRN" is needed to be done 
> at the iscsi protocol level.

You're right that history is the reason.  CRN was created in FCP-2
and wasn't added to SAM-2 until recently.  Thus, it was 
protocol-specific.  The Logical Unit Control mode page was 
created as a new page separate from the Port Control mode page 
specifically to host the EPDC bit, which does not have 
target-wide scope like the other Port Control mode page fields.

The Control mode page doesn't have any fields whose implementation
depends on the protocol, so it's not really a good home for this.  
The Disconnect-reconnect mode page does, but CRN doesn't really 
fit with its other fields.  Since FCP-2 has already committed to 
using the Logical Unit Control mode page, it makes sense for 
iSCSI to do the same.

This should make bridging iSCSI to FCP easier; if software enables
CRN on one side, a bridge probably wants it enabled on the other 
side so it doesn't have trouble reordering packets.  By using
the same page the bridge can just pass through the Mode 
Select/Mode Sense data when the software issues those commands.  
If a different page was used, it might need to generate
additional Mode Select/Mode Sense commands and translate 
the information.  This is also why I think EMDP needs to 
remain controlled by the Port Control mode page, rather than
just be delegated to text key exchange.

---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com