Subject: Re: iscsi : default iscsi mode page settings - Consensus call

From: Santosh Rao <[email-masked]>
Date: Mon, 01 Oct 2001 08:45:23 -0700

Ralph Weber wrote:

> I read SPC-2 to promise applications that such
> a value will appear in the proper field in the
> Disconnect-Reconnect mode page.

Ralph,

I don't see where in SPC-2 is it stated that "such a value
(MaximumBurstSize) will appear in the disconnect-reconnect mode page of
each protocol." 

I read the following in SPC-2 definition of disconnect-reconnect mode
page :

"The parameters appropriate to each protocol and their interpretation
for that protocol may be specified in the individual protocol
documents."

Further below in that same section :

"If a parameter that is not appropriate for the specific protocol
implemented by the SCSI device is non-zero, the device server shall
return CHECK CONDITION status. The sense key shall be set to ILLEGAL
REQUEST and the asc set to ILLEGAL FIELD IN PARAMETER LIST."

Since there are other fields in this mode page that differ from one SCSI
transport to another, I don't see how an application that is performing
a mode sense/select operation can be guaranteed reliable semantics when
it uses the SPC-2 definition of this page.

Any such application will need to be aware of all the SCSI transport
specific versions of this page and use the appropriate version based on
the transport in use.

Also, the mode sense(6) & mode sense(10) sections state that :
"If an application issues a mode sense command with a page code that is
not supported by the target, the device server shall return CHECK
CONDITION status and the sense key shall be set to ILLEGAL REQUEST and
the asc to INVALID FIELD IN CDB."

The above implies that specific implementations are allowed to not
support certain page codes [like the disconnect-reconnect mode page]. In
the case of iscsi, a class of targets (iscsi targets) will not be
supporting this page.

Again, from the above, I don't see how an application would be
guaranteed that every SCSI target would support the disconnect-reconnect
mode page. 

Please help me understand where in the SPC-2 definition is the
application assured that :

a) the disconnect-reconnect page code is required to be supported on all
targets.

b) all or any specific fields of the disconnect-reconnect field
definitions will be available to the application in each of the SCSI
transports.

Thanks,
Santosh

> Recourse to the SPI-4 definition of First Burst Size
> is a lame defense since SPI-4 simply has no First
> Burst Size concept to present in the Disconnect-
> Reconnect mode page. First Burst Size was invented
> for FCP-2 and never had any meaning for the
> parallel SCSI bus.
> 
> Since SCSI-2 there has been a promise that the
> Maximum Burst Size field in the Disconnect-Reconnect
> mode page will have meaning. Any application that
> sees zero (the preferred value for "reserved") in
> that field has every right to assume it means what
> SPC-2 says zero means, to whit: "A value of zero
> indicates there is no limit on the amount of data
> transferred per data transfer operation."
> 
> I disapprove of the proposal that First Burst Size
> be made "reserved" in the Disconnect-Reconnect
> mode page, since iSCSI has a First Burst Size
> value that could appear in the mode page. But
> owning to the parallel SCSI usage, the most that
> can be said about iSCSI making the field reserved
> is that doing so would be very bad form.
> 
> There is no basis for insisting that either of
> these parameters be "changeable" via a MODE SELECT
> command, and I leave that choice to iSCSI.
> 
> However, you all might consider remaining silent on
> the subject and thus allowing vendors whose customers
> have real needs the option of making the parameters
> changeable without failing to meet iSCSI compliance
> tests.
> 
> Knowing when to say nothing also is part of the
> art of standards writing.
> 
> Thanks for your consideration.
> 
> Ralph Weber
> SPC-2 technical editor

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: Santosh Rao <[email-masked]>
Date: Mon, 01 Oct 2001 09:48:10 -0700

Ralph Weber wrote:
> 
> Santosh,
> 
> I was not aware that you were proposing that iSCSI
> not support the Disconnect-Reconnect mode page at
> all.  Now that would be a radical step.

Ralph,

The intent was that iscsi not specify any iscsi specific mode pages (as
Julian brought up a few days ago.). Could you please clarify why & how
would this be in violation of SPC-2, in particular, commenting on the
following clarifications that I previously sought :

Where in the SPC-2 definition is the application assured that :

b) all or any specific fields of the disconnect-reconnect field
definitions will be available to the application across all of the SCSI
transports.

In the absence of the above 2 assurances to applications, how would
iscsi be breaking any legacy applications by taking this "radical" step.
(?)

IMHO, the parameter rounding mechanism renders the mode sense/select
mechanism of parameter negotiation inefficient, when compared with a
text key based scheme, and the intent of these changes is to simplify
the negotiation of these parameters and localize them to iscsi specific
efficient negotiation schemes like the current text key negotiation. 

Thanks & Regards,
Santosh

> If on the other hand you are proposing that iSCSI
> have a Maximum Burst Size but refuse to provide
> that information in the Disconnect-Reconnect mode
> page whose page code iSCSI devices accept, then
> I think you are at least violating the ISP charter
> as regards interactions with T10 standards (specifically
> SPC-2).
> 
> This is my rather strongly held opinion and unless
> you find an argument that is substantially better
> than anything presented to date I expect to maintain
> this opinion to the bitter end.
> 
> Ralph Weber

---

From: "Dev - Platys" <[email-masked]>
Date: Mon, 1 Oct 2001 10:18:13 -0700

All,

I prefer that the default value for ImmediateData be set 'no'. This allows
the initiators/targets, that support immediate data or not, to negotiate
this value with minimal handshakes during login phase. I feel that
discussions on the benefits of immediate data, complexity of implementing it
etc, though
useful, have gone off path, to determine what could be the default value.

My vote is for the default value of 'Immediatedata' to be set as 'No'.

Thanks

Deva
Adaptec

---

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 1 Oct 2001 14:37:52 -0400

I vote NO.

Eddy

-----Original Message-----
From: Dev - Platys [mailto:[email-masked]]
Sent: Monday, October 01, 2001 1:18 PM
To: IPS Reflector
Cc: [email-masked]
Subject: RE: iscsi : default iscsi mode page settings - Consensus call

All,

I prefer that the default value for ImmediateData be set 'no'. This
allows
the initiators/targets, that support immediate data or not, to negotiate
this value with minimal handshakes during login phase. I feel that
discussions on the benefits of immediate data, complexity of
implementing it
etc, though
useful, have gone off path, to determine what could be the default
value.

Thanks

Deva
Adaptec

---

From: Ralph Weber <[email-masked]>
Date: Mon, 01 Oct 2001 14:41:04 -0500

Santosh

> would this be in violation of SPC-2 ...

If the words "mode page" never appear in the iSCSI draft, then there is 
no problem with SPC-2.

If the words "Disconnect-Reconnect mode page" and "SHALL NOT implement"
appear too close to each other, then there is a problem.

> In particular, commenting on the following clarifications that I 
> previously sought :
>

The Disconnect-Reconnect mode page is and should be allowed to be
supported by any target.

> definitions will be available to the application across all of the SCSI

The only reason for not including fields in the protocol specific
description of the Disconnect-Reconnect mode page is that said fields 
do not apply to that protocol.

Neither of these prescriptions are written down since until now
they have been obvious to all.

Ralph Weber