Subject: RE: iscsi : iscsi parameter default values

From: "Julian Satran" <[email-masked]>
Date: Mon, 1 Oct 2001 08:58:47 +0300

Eddy,

For binary negotiations 08 spells out completely that you don't need the 
I->T no (there is even an example).
Other than that the spec does not forbid the behavior Santosh would like 
to see but does not mandate it either.
The exchange is mandated to include only what is needed by both parties to 
compute the new result.
The response required is there to make sure that new values are used not 
old or defaults.

Julo

"Eddy Quicksall" <[email-masked]>
30-09-01 20:19
Please respond to "Eddy Quicksall"

        To:     Julian Satran/Haifa/IBM@IBMIL, <[email-masked]>
        cc: 
        Subject:        RE: iscsi : iscsi parameter default values

I interpret what Santosh to say is:

I->T something
T->I ImmediataData=no
I->T ImmediateData=no

Isn't the I->T response required due to the phrases "For numerical
negotiations, the responding party MUST respond with the required key" &
"Binary negotiations are a restricted for of numerical negotiations"?

So isn't that the "round trip" Santosh is speaking of and don't you have 
to
do it?

BTW, I still have a hard time seeing why an extra round trip is 
significant
when, during a scan, you will have to do so much other I/O anyway (e.g.,
inquiry, test unit ready, send diagnostic, start unit, read capacity, 
report
luns, etc.).

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Saturday, September 29, 2001 2:43 AM
To: [email-masked]
Subject: Re: iscsi : iscsi parameter default values

Santosh,

The text for 08 is now:

   In "numerical" negotiations, the offering and responding party state
a
   numerical value. The result of the negotiation is key dependent;
   frequently the lower or the higher of the two values is used.

   For numerical negotiations, the responding party MUST respond with
the
   required key.

   Binary negotiations (for keys taking the values yes or no) are a
   restricted form of numerical negotiations and the result is a key
   dependent Boolean function of the two inputs. The negotiation MAY
   proceed only up to the point where both parties can unequivocally
   compute the result; continuing beyond this point is OPTIONAL (e.g.,
if
   the function is AND and one of the parties says "no" then this may
end
   the negotiation).

   The value "?" with any key has the meaning of enquiry and should be
   answered with the current value or "NotUnderstood".

   No round trip needed for your example.
   Julo

                    Santosh Rao

                    <santoshr@cup.       To:     [email-masked]

                    hp.com>              cc:

                    Sent by:             Subject:     Re: iscsi : iscsi
parameter default values
                    owner-ips@ece.

                    cmu.edu

                    28-09-01 21:03

                    Please respond

                    to Santosh Rao

John & Julian,

I agree with you that ImmediateData is a powerful performance
optimization and initiators would like to utilize this feature as much
as possible.

However, the decision on what the default setting of ImmediateData
should be depends on 2 factors, that are aside from initiator's
enthusiam to use this feature :

1)
It is the most common feature set supported on most targets that should
be considered while deciding this default. IOW, are most targets able to
support immediate data ? Are they in a position to guarantee data
buffers to initiators up-front, not knowing how many initiators would be
concurrently logged in and how much concurrent I/O load they would be
receiving from the logged-in initiators ?

2)
The decision of the default is also partly influenced by the outcome of
a seperate mail thread I've initiated with the subject "iscsi : target
originated negotiation". Julian, can you please clarify in the wake of
comments from Eddy Quicksall & Rod Harrison on this issue ? I see this
as an area of interop concern since different folks are interpreting the
spec differently.

Of particular interest from that thread to this discussion, is the case
where most targets do not support ImmediateData [due to the factors
mentioned in (1) above] and most initiators are attempting to use
ImmediateData [due to the performance boosts it provides], but, are
using the default of "yes" to negotiate this feature.

In this case, the target would be compelled to originate the
ImmediateData="no" key in order to break the default. Now, if initiators
(the responder to the negotiation, in this case) are required to respond
to this key originated by the target, then, this is going to cause extra
round-trips in the login process for the sole purpose of both sides
agreeing that ImmediateData is not to be used.

It would help to have clarification on how the target originated
negotiation culminates, since that is a factor in deciding this default.

Thanks,
Santosh

John Hufferd wrote:
>
> Robert,
> We have had this debate before, and I guess the sides are still
polarized.
> However, a number of folks believe that immediate is easier to handle
then
> R2T (since all the information they need is with the PDU), and the
> conservative option.  The main discussion has been since they also
want
to
> have  R2T they did not want to have two code paths. However, when
folks
> have looked at the effort to support immediate data, they have found
it
to
> be trivial.
>
> The payback of NOT having multiple round trips to get the data is an
> important feature, and when you think about all the error recovery
items
we
> have been discussing, it is clear that immediate data makes every
thing
> easier.
>
> The important performance improvements are so important to iSCSI (in
my
> mind) that if the worse the Target has to do if it can not handle
immediate
> data, is to send the Text Key of "ImmediateData=no", I do not think
this
is
> a problem.  We need to have this performance feature thought about as
a
> normal property of iSCSI, so that every one that talks about the
advantages
> of iSCSI can include this, with out a bunch of qualifying statements.
> Having this as the default is one way to keep this thought at the
front
of
> everyone's mind.
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: [email-masked]
>
> Robert Snively <[email-masked]> on 09/28/2001 08:25:45 AM
>
> To:   John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL
> cc:   [email-masked]
> Subject:  RE: iscsi : iscsi parameter default values
>
> I vote no as the default value on ImmediateData.
>
> A default value of yes on ImmediateData requires implementation
> of the most complex and demanding mode of operation as the
> default.  SCSI has traditionally made its default behavior the
> simplest and most encompassing, setting more sophisticated
> behavior by subsequent agreement.  While it may be your earnest
> desire to encourage the implementation of this function, it
> is not appropriate to demand that as the default behavior
> of all devices.  In particular, there is no special benefit
> to providing ImmediateData in low-cost local sub-lans.
>
> If you want to encourage it in a profile, fine, but demanding
> it as the default in the core standard is not appropriate.
>
> Note that the behavior of SCSI is traditionally managed
> entirely by the target.  As such, there has never before now
> been a requirement for the target to, as a default, accept
> any PDU except a command or task management function
> that was not explicitly solicited.  That is one of the mechanisms
> that assists SCSI in achieving a low-overhead zero copy
> capability while operating with a large number of initiators
> and with deep command queues.
>
> Bob Snively                        e-mail:    [email-masked]
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
>
> > -----Original Message-----
> > From: John Hufferd [mailto:[email-masked]]
> > Sent: Friday, September 28, 2001 1:33 AM
> > To: Julian Satran
> > Cc: [email-masked]
> > Subject: RE: iscsi : iscsi parameter default values
> >
> >
> >
> > I also agree with this.  It should be yes.
> >
> > .
> > .
> > .
> > John L. Hufferd
> > Senior Technical Staff Member (STSM)
> > IBM/SSG San Jose Ca
> > Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > Home Office (408) 997-6136
> > Internet address: [email-masked]
> >
> >
> > Julian Satran/Haifa/IBM@[email-masked] on 09/27/2001 09:50:21 AM
> >
> > Sent by:  [email-masked]
> >
> >
> > To:   [email-masked]
> > cc:
> > Subject:  RE: iscsi : iscsi parameter default values
> >
> >
> >
> >
> > The one that I have trouble living with is ImmediateData.
> > This is important
> > for low-end desktops and hardly matters for large boxes.
> > As such I would suggest it stays as yes.
> >
> > Julo
> >
> >
> >
> >                     "Eddy
> >                     Quicksall"            To:     "'Santosh Rao'"
> > <[email-masked]>,
> >                     <EQuicksall@med        <[email-masked]>
> >                     iaone.net>            cc:
> >                     Sent by:              Subject:     RE:
> > iscsi : iscsi
> > parameter default values
> >                     [email-masked]
> >                     mu.edu
> >
> >
> >                     27-09-01 17:22
> >                     Please respond
> >                     to "Eddy
> >                     Quicksall"
> >
> >
> >
> >
> >
> > I like your defaults below.
> >
> > But, section 5 says:
> >
> >  The initial Login request MUST include the InitiatorName and
> >  SessionType key=value pairs.
> >
> > Since SessionType is REQUIRED, naming a default would imply a
> > possible typo
> > in the spec.
> >
> > Eddy
> >
> > -----Original Message-----
> > From: Santosh Rao [mailto:[email-masked]]
> > Sent: Wednesday, September 26, 2001 10:29 PM
> > To: [email-masked]
> > Subject: iscsi : iscsi parameter default values
> >
> >
> > All,
> >
> > With the issue of mode page vs. login keys having [almost] drawn to
a
> > close, I would like to
> > raise the below issues again, on the subject of default
> > values for login
> > keys and other iscsi
> > parameters :
> >
> >
> >    * In keeping with traditional use of scsi mode pages, iscsi
should
> > not specify any default
> >      settings for any mode pages that continue to exist for iscsi.
> > "Default values" for mode
> >      pages are target specific and should not be bound to the
protocol
> > draft.
> >
> >    * MORE IMPORTANTLY, I read the default for EMDP as being set to 1
> > :-<  This implies that
> >      targets must be always prepared to deal with out of
> > order data and
> > initiators must be
> >      prepared to deal with out of order data, unless the initiator
> > performs a mode select to
> >      disable it. [which defeats all the previous advantages
> > gained thru
> > mandating use of login
> >      keys for other negotiations.]. A default, if it were to exist,
> > should be 0. (in-order, by
> >      default).
> >
> >    * Conservative specification of defaults for login keys along the
> > following lines :
> >                             MaxConnections = 1
> >                             FMarker = "no"
> >                             InitialR2T = "yes"
> >                             BidiInitialR2T = "yes"
> >                             ImmediateData = "no"
> >                             DataPDULength = 16
> >                             MaxOutstandingR2T = 1
> >                             DataPDUInOrder = "yes"
> >                             ErrorRecoveryLevel = 0
> >                             SessionType = "normal"
> >
> >    * Should the iscsi protocol require a "Lun Control Mode Page"?
IOW,
> > is an EnableCRN bit
> >      required at the transport layer ? If the device server
capability
> > is to be negotiated , I
> >      suggest this bit be moved to a SCSI ULP Mode Page such as the
> > "Control Mode Page", through a
> >      T10 change as a part of the SCSI changes being driven by iscsi.
> >
> > Comments ?
> >
> > Thanks,
> > Santosh
> >
> >
> > Santosh Rao wrote:
> >
> > > There are the separate issues of :
> > >
> > >    * iscsi's specification of defaults for its mode pages
> > which is not
> > in line with mode page
> > >      usage. This impacts the target's ability to enforce
> > values other
> > than the protocol
> > >      specified default, if the initiator were to not use mode
> > sense/select.
> > >
> > >    * default settings for login keys.
> > >
> > >    * Is there a need for the "LUN Control Mode Page" and whether
> > "Enable CRN" should be in a
> > >      transport specific mode page ?
> > >
> > > which need to be driven to closure as well.
> > >
> > > Regards,
> > > Santosh
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

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

---

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

John,

I don't think you are considering existing cache code that was written
around parallel SCSI. That is the basics for the arguments that everyone is
giving you.

Remember, we want iSCSI to be a hit and if people can't port easily, it will
be a problem.

As I said before, the default value is no big deal because one can always
"just say no" (or yes).

Eddy

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Sunday, September 30, 2001 4:42 PM
To: Sanjeev Bhagat (TRIPACE/Zoetermeer)
Cc: [email-masked]
Subject: RE: iscsi : iscsi parameter default values

Sanjeev,
On the contrary, Immediate Data is simple, it permits  important
performance improvements, and the memory arguments are all old
arguments.

Perhaps they were valid in the time that FC was being created, but the
memory arguments are not now valid.  (see my, and Julian's previous
notes
on this.)

Almost every one I know is able to easily code chained Buffer
management,
which permits the zero copy capability, and with that the rest of
Immediate
Data handling is very easy since you have the associated command with
the
data.  Using Immediate Data is the simple path, the conservative path.

ImmediateData=yes should be the default.  We should not be bound by the
limitations of previous memory technology.

.
.
.
John L. Hufferd

"Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]>@ece.cmu.edu
on
09/30/2001 12:50:59 PM

To:   "'Robert Snively'" <[email-masked]>, Julian
      Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: iscsi : iscsi parameter default values

All,

I guess this is a very important input from robert.

"In FCP, we found that immediate data caused
sufficient complexity, both in parsing command structures and
in performing error recovery, that we chose not to allow it
since there was no performance benefit anyway."

Considering this i have a question is immediate data really needed at
all?
and definitely the default value should be no in this case.

Sanjeev

-----Original Message-----
From: Robert Snively [mailto:[email-masked]]
Sent: Sunday, September 30, 2001 7:48 AM
To: 'Julian Satran'; [email-masked]
Subject: RE: iscsi : iscsi parameter default values

Julian,

Are not both immediate data and "unsolicited" data outside the
command PDU both governed by the first-burst size?  If so,
the problem remains the same.  If you have 50 initiators through
each of 10 ports to 50 logical units with 50 commands queued in
each with immediate data of 4K bytes, that adds up to a lot of
bytes which have to have buffers pre-reserved to allow normal
operation.  It is the buffer management that is invasive, not
the indexing of the buffer contents.  It is the dual-copy requirement
that is invasive, significantly increasing buffer utilization.

For these problems, immediate data and unsolicited data are
equivalent.  Frankly, I see no functional difference between
sending data in the same PDU and sending data in an immediately
following PDU.  In FCP, we found that immediate data caused
sufficient complexity, both in parsing command structures and
in performing error recovery, that we chose not to allow it
since there was no performance benefit anyway.

> Sent: Friday, September 28, 2001 10:29 PM
> To: [email-masked]
> Unlike FCP - iSCSI has two forms of unsolicited "immediate"
> and "separate
> unsolicited". They can be used separately or together.
> Immediate data is a single PDU comming together with the
> command while the
> separate unsolicited may come after.
>
> FCP has only the second type.
>
> With separate unsolicited the target has to have the buffers
> for the burst
> and find the "control blocks" by indexing based on ITT.
>
> With Immediate data the target has to deal with a single PDU (not the
> entire burst). Indexing is not done twice (it is done as a
> check for the
> Control block that is being built).
>
> This is why Immediate Data is considered far less  invasive
> than separate
> unsolicited (a single buffer, and no indexing) and give the
> performance
> boost it gives we are going to see it probably on every target.
>
> Julo
>
>
>
>
>                     Robert Snively
>
>                     <rsnively@broc       To:     Julian
> Satran/Haifa/IBM@IBMIL, [email-masked]
>                     ade.com>             cc:
>
>                                          Subject:     RE:
>                     29-09-01 01:31
>                     to Robert
>                     Snively
> Julian,
> For SCSI Write operations, ImmediateData = yes is
> the most demanding mode for the target.  If I understand
> it correctly, it essentially over-rides the R2T state,
> allowing the first burst to be included as immediate data.
> In SCSI, except for special cases like this, the target
> is the device in charge of data transfers.
>
> This mode requires the target to have a guaranteed collection of
> received buffer space adequate to receive all possible
> outbound queued operations from all possible initiators
> through all possible target sessions (which may sum to
> 1000s of output operations), regardless of what other
> buffer-intensive operations may be going on in the device.
>
> It then requires the device to provide association with each
> of those commands instead of just the commands it has elected
> to activate.  Without immediate data, the command buffer can be
> separated and separately managed from the data buffer,
> limiting buffer requirements.
>
> It then requires the device to operate in a non-zero-copy
> mode (which raises buffer utilization and increases latency)
> while the device analyzes the command to determine what should
> be done with the data.  It further requires the subsequent
> data (if there is more than one PDU to be transmitted) to
> be separately managed, and perhaps actually stored in a
> separate operation if the buffer must be cleared to make
> space available for it.  It further requires the target to
> analyze the data for completeness before going on to determine
> what to do with it.
>
> Sure, it is easy for the initiator, but so is everything else
> except out-of-order reads.
> It is the target you are stressing with this.
>
> For local sub-LANs, and depending on the actual buffering
> available in the target, the performance may actually be lower with
> ImmediateData allowed, because zero copy behavior of the
> target to non-volatile media is not available, which raises
> buffer utilization.
>
> Have I missed something that would change my mind?
>
> Bob
>
>
> > Sent: Friday, September 28, 2001 10:38 AM
> > To: [email-masked]
> > I disagree that Immediate is "the most demanding" mode.  That
> > is not my
> > experience and not what I heard from most of the developers.  On the
> > contrary immediate data do not require a separate indexing
> > operation on the
> > target (as non-immediate unsolicited do) and that was the
> base for the
> > consensus to have them negotiated separately.
> >
> > For the software initiator it is the most inexpensive way to
> > perform short
> > data transfers (4-8k) typical for major applications like
> > Database access
> > and so it is for lightweight target.
> >
> > Julo
> >
> >
> >
> >
> >
> >                     Robert Snively
> >
> >                     <rsnively@broc       To:     John
> > Hufferd/San Jose/IBM@IBMUS, Julian
> >                     ade.com>
> > Satran/Haifa/IBM@IBMIL
> >                                          cc:
> > [email-masked]
> >                     28-09-01 17:25       Subject:     RE:
> > iscsi : iscsi parameter default values
> >                     Please respond
> >
> >                     to Robert
> >
> >                     Snively
> >
> >
> >
> >
> >
> >
> >
> >
> > > With the issue of mode page vs. login keys having [almost]
> > drawn to a
> > > close, I would like to
> > >    * In keeping with traditional use of scsi mode pages,
> > iscsi should
> > > not specify any default
> > >      pages are target specific and should not be bound to
> > the protocol
> > > draft.
> > >
> > >    * Should the iscsi protocol require a "Lun Control Mode
> > Page"? IOW,
> > > is an EnableCRN bit

---

From: Dave Sheehy <[email-masked]>
Date: Mon, 01 Oct 2001 15:34:34 PDT

Robert,

> following PDU.  

I just want to point out that the data is NOT required to be in an 
immediately following PDU. There can be any number (up to MaxCmdSN) of
intervening non-data PDUs between the command and data.

Dave

---

From: Robert Snively <[email-masked]>
Date: Tue, 2 Oct 2001 09:40:01 -0700

John,

What I really wanted to point out is that the destination
of the data is NOT the buffer, nor is it a memory space
behind the buffer.  It is a non-volatile protected storage medium,
which may be either a set of disk drives with the proper degrees
of RAID redundancy or (at least temporarily) some kind of 
replicated non-volatile RAM.

It is that protected space which must be made available for received data.
If you tack the data into the command PDU, you must treat the
whole combination.  You may treat it as protected, or you may treat
it as recoverable, depending on how complex you want your PDU
retransmission algorithm to be, but in either case you will have
to post-process it to separate the command, interpret the command,
and move the data portion to the proper resting place, where it
can be available for subsequent accesses by other commands.

If you leave it separate, you can treat the command as a unit
which does not have to be separated out or analyzed until you get
around to it, placing the data in a pre-allocated portion of
the non-volatile storage for later tagging and referencing when
the command is interpreted.

Better yet, if you use R2T, you can request the data at the
proper time to have it delivered (in any convenient order of
course) directly to the proper destination disk drive or to a pre-tagged
portion of non-volatile storage.  It is this type of operation that
is truly "zero-copy" in the SCSI and storage sense.

> Sent: Sunday, September 30, 2001 2:29 AM
> To: Robert Snively
> Cc: [email-masked]
> You only have to perform moves, if you have not coded your 
> buffer manager
> to manage Chained Segments.  Since this is a very old and highly used
> technique in buffer management, especially involving 
> Telecommunications, I
> am surprised that you have not considered it.  Perhaps I am missing
> something in what you are trying to say but I have used it 
> often to avoid
> moving data and obtaining zero-copy.  It is also works well 
> with devices
> that support Scatter Gather, which is the usual case with Disk.
> 
> Immediate data is simple, perhaps the simplest of all our functions to
> code.  You are correct, that it means that there may have to 
> be reasonably
> sized buffers.  This argument was valid years ago, but it is 
> now just too
> hard not to have large buffers in a storage controller (in 
> fact now small
> cost more).
> 
> Yes, I know there are limits to what I said above, but that is why the
> ImmediateData=No can be used.  But your focus and arguments are old
> arguments, for devices that thought memory was too expensive 
> to use a great
> deal of it.
> 
> Example: since most uses of ImmediateData will probably 
> average less then
> 4k (example Database pages),  four thousand connections means 
> 16 Meg, I do
> not think you can even get a decent price on memories that 
> small.  If you
> have a device that supports 4 thousand host connections, I 
> suggest that 16
> meg is not an issue.  Why would we even discuss it?
> 
> 
> .
> .
> .
> John L. Hufferd
> Robert Snively <[email-masked]>@ece.cmu.edu on 
> 09/28/2001 04:31:12 PM
> 
> To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
> cc:

---

From: "John Hufferd" <[email-masked]>
Date: Tue, 2 Oct 2001 11:33:00 -0700

Eddy,
Only one correction below.

.
.
.
John L. Hufferd

"Eddy Quicksall" <[email-masked]> on 10/02/2001 09:08:17 AM

To:   "'Santosh Rao'" <[email-masked]>, John Hufferd/San
      Jose/IBM@IBMUS
cc:   <[email-masked]>
Subject:  RE: iscsi : iscsi parameter default values

Would all cases look like these? (If I made a mistake, please correct it).

Note that I am attempting to use the rule specified as:

 The negotiation MAY
 proceed only up to the point where both parties can unequivocally
 compute the result; continuing beyond this point is OPTIONAL.

And my interpretation of the rule is that when a responder gets a binary
value, it can compare that against the default and can therefore compute
the
result and therefore does not need to respond if the result is what he
wants.

Am I correct in my interpretation?

Eddy

Default ImmediateData="yes"
===========================
Initiator wants immediate data & target supports it.
---------------------------------------------------

I -> T : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

yes * yes = yes

Initiator does not want immediate data & target supports it.
-----------------------------------------------------------

I -> T : ImmediateData="no".
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

no * yes = no

Initiator wants immediate data & target does not support it.
-----------------------------------------------------------

I -> T : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

T -> I : ImmediateData="no".
         (CSG=Operational, NSG=FFP). T=1

yes * no = no

Initiator does not want immediate data & does not target support it.
-------------------------------------------------------------------

I -> T : ImmediateData="no".
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

no * yes = no

Default ImmediateData="no"
==========================
Initiator wants immediate data & target supports it.
-----------------------------------------------------------

I -> T : ImmediateData="yes"
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)

yes * no = no

[Huff] yes * no (but OK) = Yes
[/Huff]

Initiator does not want immediate data & target supports it.
--------------------------------------------------------------

I -> T : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent)
         (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)

no * no = no

Initiator wants immediate data & target does not support it.
-----------------------------------------------------------

I -> T : ImmediateData="yes".
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

yes * no = no

Initiator does not want immediate data & does not target support it.
-------------------------------------------------------------------

I -> T : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

no * no = no

Eddy

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Monday, October 01, 2001 7:16 PM
To: John Hufferd
Cc: [email-masked]
Subject: Re: iscsi : iscsi parameter default values

John Hufferd wrote:
>
> I think your logic reverses if the support wanted is yes and the
target is
> supporting yes.

How so ?

Here are the scenarios when initiator wants to use immediate data and
target supports it, first with default ImmediateData set to "yes" and
then, with default Immediatedata set to "no". In both cases, a single
login handshake occurs. The only difference being that when
ImmediateData defaults to "yes", the key need not be sent in either
direction, whereas when it defaults to no, the ImmediateData key travels
in both directions in the login payload.

(FFP = FullFeaturePhase).

Default ImmediateData="yes"
---------------------------
Initator wants immediate data & targets supports it.
----------------------------------------------------

I -> T : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

Default ImmediateData="no"
--------------------------
Initiator wants immediate data and target supports it.
-----------------------------------------------------------

I -> T : ImmediateData="yes"
         (CSG=Operational, NSG=FFP). T=1

T -> I : Immediatedata="yes"
         (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)

Same number of handshakes in both cases. The only difference is that the
key is not sent in the first case, and key is explicitly exchanged in
the 2nd case.

> If they say No they clearly do not care about extra handshakes sense
R2T is
> all they have and it requires extra handshakes.

Hmm.... The way I see it, an initiator that does not use ImmediateData
is a simple initiator and is more interested in seeing a simpler login
(completed in a single login req/rsp) than one that does support
ImmediateData.

Those implementations that can do the extra work of supporting
ImmediateData can well do the extra work of negotiating for its use.

Regards,
Santosh

---

From: "John Hufferd" <[email-masked]>
Date: Tue, 2 Oct 2001 11:53:23 -0700

Bob,
I really do understand your statements about the cache.  I just think that
they are over stated.

Ed,
First off let me also say to, that you points ( on another note regarding
Caches) are right on.  Especially your points with regards to having to do
something to match the new capabilities of iSCSI with old Cache Manager
designs. It is possible that not all are flexible enough to make a easy
adaption.  (But some/many are.)

Bob,
The Data parts of on immediate data are clearly identifiable in the PDU.
It is very reasonable to fork the input as it is coming in.  That is, put
the data into NVRAM cache memory as the data comes in, and place the CDB
etc, wherever you want it.  At that time, all the associations can be
marked as well.

I over stated the code path identity between Login handling and Write I/O
immediate Data.  But the receive code path is very similar, it is just that
the Data probably will not go to the NVRAM cache.  Instead it would be
forked into a Text parsing work area.  But the code is very close to the
same.  And my point is, to worry about the few line of code difference is
missing the key point and the value of Immediate Data.

.
.
.
John L. Hufferd

Robert Snively <[email-masked]> on 10/02/2001 09:40:01 AM

To:   John Hufferd/San Jose/IBM@IBMUS, Robert Snively
      <[email-masked]>
cc:   [email-masked]
Subject:  RE: iSCSI : iSCSI parameter default values

John,

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 3 Oct 2001 13:25:11 +0300

I think I sent them out to you in a private note. Julo

Santosh Rao <[email-masked]>
Sent by: [email-masked]
01-10-01 20:59
Please respond to Santosh Rao

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        Re: iscsi : iscsi parameter default values

Julian,
It would be more helpful to the discussion if you pointed out why you
think the examples are incorrect, rather than your terse comment below
:)

Specifically, my example is based on the following text from Section 5.1
of Rev 08 draft which states :

"An initiator that can operate without security and with all the
operational parameters taking the default values issues the Login with
the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG
set to FullFeaturePhase. If the target is also ready to forego security
and LoginOperationalNegotiation the Login response is empty and has T
bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to
FullFeaturePhase in the next stage."

I look forward to your clarification of the expected login handshakes in
the scenarios I raised.

Thanks,
Santosh

Julian Satran wrote:
> 
> ... the debate would be of some interest if the examples where
> correct.
> 
> But unfortunately they are not.
> 
> Julo
> 
>   Santosh Rao
>   <[email-masked]>                   To:        [email-masked]
>   Sent by: [email-masked]          cc:
>                                           Subject:        Re: iscsi :
>   01-10-01 18:18                  iscsi parameter default values
>   Please respond to Santosh Rao
> 
> 
> All,
> 
> As the one who started this thread, please allow me to raise one
> important consideration to this discussion.
> 
> This discussion has gone down the path of whether immediate data
> boosts
> performance and is implementable or whether it is so demanding that it
> is not feasible to implement.
> 
> I believe the decision on what the default value must assume for this
> parameter must be based on what is going to be the simplest for the
> login process and which setting minimizes the overheads involved for
> completion of login.
> 
> The reason for applying the above criteria is that it provides the
> benefit of completing login negotiation in a single handshake and in
> most cases, where initiator goes with the defaults, allows no
> negotiation to be required whatsoever. [in the case where no security
> is
> being negotiated.]. This has the significant benefit of boosting iscsi
> interoperability, since it has been seen that login is one of the most
> painful areas of iscsi.
> 
> With the above in mind, let us consider the 2 cases, Immediate data
> default to "yes" & "no" (assuming neither side is interested in
> security) :
> 
> In the first case (default immediate data="yes') :
> --------------------------------------------------
> - Initiator wishes to use immediate data. Target does not support it.
> 
> I -> T : (no key is sent. default assumed for immediate data).
>                  (CSG=Operational, NSG=FullFeaturePhase). T=1
> 
> T -> I : ImmediateData="no" (tgt does not support imm data.)
>                  (CSG=Operational,NSG=Operational). T=0
> 
> I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1
>         (no keys to negotiate.
>          negotiation completed at initiator.
>          only phase change taking place.)
> 
> T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1
>         (target completes phase change.
>          both sides move to FFP.)
> 
> Thus, in the above model, there's an extra dummy login handshake, when
> the default ImmediateData is "yes" but targets don't support it for
> the
> sole purpose of completing the login phase change.
> 
> Now, take the case of default ImmediateData set to "no" :
> ---------------------------------------------------------
> - Initiator wants to use immediate data. target does not support it.
> (same scenario as above).
> 
>         (CSG=Operational. NSG=FullFeaturePhase.). T=1
> 
> T -> I : ImmediateData="no"
>                  (CSG=Operational. NSG=FullFeaturePhase). T=1
> 
> - Initiator does not want to use immediate data.
> 
> I -> T : (no key is sent. defaults assumed).
>         (CSG=Operational. NSG=FullFeaturePhase). T=1
> 
> T -> I : (targets can accept all defaults since they
>                   are conservative.)
>                  (CSG=Operational, NSG=FullFeaturePhase). T=1
> 
> 
> Thus, as you can see from the above, the login process involves the
> least number of exchanges when the default for ImmediateData is chosen
> to be "no", as opposed to a default of "yes".
> 
> It DOES NOT matter whether some believe ImmediateData is useful and
> feasible or some believe it is useful but not feasible, or yet some
> others believe it is not useful.
> 
> What MUST govern this decision is which default allows for the
> simplest
> login operation.
> 
> >From the above, it seems to me like a default of "no" for
> ImmediateData
> allows login to be completed in a single handshake in the case where
> initiators wishes to use immediate data or not, and in the case where
> target supports immediate data or not.
> 
> Therefore, I request the group to please consider setting the
> ImmediateData default to "no" and vote for the setting of "no". This
> decision benefits BOTH the camp of immediate data users and non-users,
> since both benefit from minimized steps in the login process.
> 
> Thanks,
> Santosh
> 
> 
--------------------------------------------------------------------------
> Robert Snively wrote:
> > > target (as non-immediate unsolicited do) and that was the base for
> the

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 3 Oct 2001 15:08:32 +0300

Santosh,

I see now where you took your rules from. Those where meant to be only 
examples but I will reformulate the offending paragraph as:

An initiator that can operate without security and with all the 
operational parameters taking the default values issues the Login with the 
T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to 
FullFeaturePhase. If the target is also ready to forego security and can 
finish its LoginOperationalNegotiation the Login response  has T bit set 
to 1, the CSG set to LoginOperationalNegotiation and NSG set to 
FullFeaturePhase in the next stage.

Regards,
Julo

01-10-01 23:36

Julian,

The login section is somewhat contradictory b/n the wording you point
out below and the following wording :

Per the above wording, the target can :
- only set T bit to 1 and change phase from Operational to
FullFeaturePhase if it has no keys to send back.

Thus, when a target is unable to function with a default key setting, it
will need to originate a key, remain in operational phase and respond
with T=0.

From the above wording, it appears that while the key negotiation has
ended (per your wording below), the login remains in Operational Phase
due to the target having to return NSG=Operational (per the above
wording). Hence, the scenario/example I sent earlier is  valid, per the
above wordings in the draft rev 08.

I suggest the following that the above wording be re-phrased to allow
the target to change phase any time it is done with its keys and has no
more parameters to send. (i.e. it can set T=1 and still send back
parameters. Login response need not be empty.)

Regards,
Santosh

Julian Satran wrote:
> 
> Santosh,
> 
> I assume that you know by now but here is the key anyhow:
> 
> Robert,
> 
> The I and T are required to send enough messages so that every one of
> them will be able to evaluate the result with new data (stated
> explicitly  with an example in 2.2.4
> 
> In "numerical" negotiations, the offering and responding party state a
> For numerical negotiations, the responding party MUST respond with the
> required key.
> 
> compute the result; continuing beyond this point is OPTIONAL (e.g., if
> the function is AND and one of the parties says "no" then this may end
> the negotiation).
> 
> This is one of the reasons of selecting a computed value.
> 
> You introduce an exchange not needed.
> The behavior you want is supported but not mandated.
> I will introduce explicit wording in 09.
> 
> Julo
> 
>   Santosh Rao
>   <[email-masked]>                 To:        Julian
>   Sent by: [email-masked]  Satran/Haifa/IBM@IBMIL
>                                         cc:
>   01-10-01 19:08                        Subject:        Re: iscsi :
>   Please respond to Santosh Rao iscsi parameter default values
> 
> 
> 
> Julian,
> 
> Could you please comment on why the examples are incorrect and what
> are
> the login hand-shakes for the scenarios suggested.
> 
> Thanks,
> Santosh
> 
> Julian Satran wrote:
> >
> >                                           Subject:        Re: iscsi
> :

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 3 Oct 2001 17:15:40 +0300

According to 08 to change from yes to no you need one ONE-WAY message - 
i.e. you are guranteed to end in one roundtrip (the function is AND).
Going from no to yes you need 2-ONE WAY messages - i.e. if initiator 
starts the 2 are in one round trip if target starts there 2 round-trips.

With this a default of yes is easier to handle on all defaults.

Julo

"Eddy Quicksall" <[email-masked]>
Sent by: [email-masked]
02-10-01 15:48
Please respond to "Eddy Quicksall"

        To:     John Hufferd/San Jose/IBM@IBMUS, "'Dev - Platys'" <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: iscsi : iscsi parameter default values

First, realize I just want to give information as I see it from an 
objective
standpoint.

Regarding your reply below, login is not cached so the "immediate data"
techniques used there are quite different then the techniques used during
full feature phase in legacy cache.

In another mail, I explained why some legacy cache implementations would
have to be changed and cache is probably the last thing you would want to
change if you are in a "time to market" crunch. Remember, this is not in 
the
transport layer.

The thing we should probably be looking at is "what requires the least
number of round trips and are the round trips really significant".

Eddy

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Monday, October 01, 2001 6:33 PM
To: Dev - Platys
Cc: Eddy Quicksall; [email-masked]
Subject: RE: iscsi : iscsi parameter default values

You will need the same type of Immediate Data handling code to handle the
Login.  The Login Parameters are in the extended Data Section of the PDU.
So you have to have that code anyway.

Given that you have to have the code anyway, in both cases
ImmediateData=Yes and No -- Yes is the simplest, the best performing, and
the lowest overhead, so Yes should be the default.

.
.
.
John L. Hufferd

"Dev - Platys" <[email-masked]>@ece.cmu.edu on 10/01/2001 02:39:57 PM

To:   "Eddy Quicksall" <[email-masked]>, <[email-masked]>
cc:
Subject:  RE: iscsi : iscsi parameter default values

Thats a good point.

Deva
Adaptec

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Eddy Quicksall
Sent: Monday, October 01, 2001 2:11 PM
To: [email-masked]
Subject: RE: iscsi : iscsi parameter default values

Looking at this from another view point ...

Isn't support of R2T required anyway because the Expected Data Transfer
Length may exceed the FirstBurstSize?

So, wouldn't that make "no" the "lowest common denominator"? If so, I 
would
think that "no" would therefore be the default.

Just food for thought.

Eddy