Subject: RE: iscsi : default iscsi mode page settings.

From: "Elliott, Robert" <[email-masked]>
Date: Fri, 21 Sep 2001 09:27:18 -0500

> -----Original Message-----
> From: Santosh Rao [mailto:[email-masked]]
> 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
[email-masked]

---

From: Santosh Rao <[email-masked]>
Date: Fri, 21 Sep 2001 12:27:17 -0700

> the knowledge of the application, breaking backups).

Rob,

Is'nt this all the more reason to avoid setting FirstBurstSize through a
mode page and use a login key for this ? Shared mode pages can cause some
strange side effects on I/Os that are using un-solicited data.

> using the Logical Unit Control mode page, it makes sense for

Does the EPDC bit verify the CRN capabilities of both the target FCP layer
and the target SCSI ULP (device server) ? One would think the capabilities
of the 2 layers need to be checked through seperate bits. The device
server's ability to support CRN is a SCSI ULP feature and seems more like a
bit in the Control Mode Page. (does not exist today ?). The target FCP's
CRN capability is tested through the FCP specific EPDC bit in the FCP
specific lun control mode page.

For iSCSI, no protocol specific test should be required since iscsi always
supports CRN. Regarding the device server's support for CRN, this seems
like a better fit in the Control Mode Page.

Regards,
Santosh

---

From: James Smart <[email-masked]>
Date: Sun, 23 Sep 2001 20:58:11 -0400

In my mind, this completely illustrates why there should be a clean division
between SCSI device server parameters and transport parameters. Transport
controls should be controlled via the transport - by a transport mechanism, with
the SCSI Device completely unware of the transport (yes, I'm a layering purist).
I've always completely disliked the notion that you had to fully come up on the
transport to send a SCSI command to obtain/change transport information. The
tightly integrated implementations (transport + scsi) may have succeeded earlier
in this argument (especially for FCP and PLDA), but in the end, it breaks down
horrendously as the more complex environments are put together (such as
multi-initiator (aka SAN) environments), or hardware is moved from one
configuration to another (and heaven forbid you can't communicate at the
transport level due to a saved parameter, thus you can't send the scsi command
to change the parameter!).

-- James

"Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:

> * From the T10 Reflector ([email-masked]), posted by:
> * "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <[email-masked]>
> *
>
> ----- Original Message -----
> From: "Santosh Rao" <[email-masked]>
> To: "IPS Reflector" <[email-masked]>
> Cc: "T10 Reflector" <[email-masked]>
> Sent: Friday, September 21, 2001 9:27 PM
> Subject: Re: iscsi : default iscsi mode page settings.
>
> > "Elliott, Robert" wrote:
> >
> Rob, Santosh,
> I would still go in favour of running a mode sense rather than using a login
> key because
> 1. by providing a value in login key essentially means that we are doing
> some sort of mode select to the target
> 2. if multiple initiators send different values of firstburstsize then
> target has to behave accordingly with all different targets.
>
> This goes completely against the semantics of mode sense and mode select
> defined in SCSI specifications. Any such parameteres are although
> settable/changeable by clients but are mainly the properties of SCSI
> LUs/targets.
>
> Mode sense command from initiator will simplify the logic at target's end as
> well.
>
> regards,
> sanjeev
>
> >
> > >
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to [email-masked]

---

From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <[email-masked]>
Date: Mon, 24 Sep 2001 01:12:41 +0200

----- Original Message -----
From: "Santosh Rao" <[email-masked]>
To: "IPS Reflector" <[email-masked]>
Cc: "T10 Reflector" <[email-masked]>
Sent: Friday, September 21, 2001 9:27 PM
Subject: Re: iscsi : default iscsi mode page settings.

Rob, Santosh,

regards,
sanjeev

---

From: Santosh Rao <[email-masked]>
Date: Mon, 24 Sep 2001 09:30:05 -0700

> some sort of mode select to the target

Sanjeev,

I dis-agree with the above. A login key serves as a mechanism to either
negotiate or query for a parameter value.By sending :
FirstBurstSize=?

you could query the target for its current setting of this parameter and you
would achieve this in a more optimal manner than having to send one extra SCSI
command on the wire during session establishment solely for the purpose of
querying this key.

In addition, even if the initiator attempted to negotiate this key, the target
is allowed to send back a different value for this key based on the buffering
abilities of the target.

For ex :
I -> T : MaximumBurstSize=128
T -> I : MaximumBurstSize=8

is a valid negotiation and the target is allowed to send back a default setting
for all initiators without allowing any initiators to make a change.

Thus, the login keys are as effective, but more optimal in use and more
accurate in scope, than the use of scsi mode sense/select for querying/setting
the FirstBurstSize.

> target has to behave accordingly with all different targets.

See above.

Regards,
Santosh