Subject: Re: [Ips] New iSCSI key

From: Mike Ko <[email-masked]>
Date: Fri, 15 Oct 2004 10:57:46 -0700

John,

Would the following replacement text for the sentence "Solicited data are 
normally handled ..." better?
"The R2T mechanism is normally used to handle solicited data and the SCSI 
Data-out PDU should not be used for this purpose (see section 7.3.4)."

Mike
From:   John Hufferd on 10/15/2004 10:22 AM

To:     Mike Ko/Almaden/IBM
cc:     [email-masked] 
Subject:        Re: [Ips] New iSCSI key 

Mike,
I think you covered my concerns, but perhaps we should actually use words 
in the draft similar to what you have used here for the unsolicited 
Data-Out PDUs.  I just thought that the words you proposed for the draft 
were a little bit confusing, since we never have talk about how an iSCSI 
layer requests Data-Out PDUs, etc.  I think your words in this note were 
more to the point.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: [email-masked]

Mike Ko/Almaden/IBM
10/15/2004 10:01 AM

To
John Hufferd/San Jose/IBM@IBMUS
cc
[email-masked]
Subject
Re: [Ips] New iSCSI key

John,

My comments are embedded.

Mike
To:     Mike Ko <[email-masked]>
cc:     [email-masked] 
Subject:        Re: [Ips] New iSCSI key

Mike, 
First I think there is a Typo near the end of your note when you talk 
about NOP-Out PDU where you might have meant Nop-In.  That is, where you 
say "...Otherwise, a NOP-out PDU is 
considered "unexpected",...." perhaps you should say Nop-In.

[mk[
Good catch.  I will fix that.
]mk]

Second I think we need to discuss the unsolicited Data-Out PDU.  Please 
expand on the concept of the use of Data-Out PDU for solicited Data in 
iSER. 

[mk[
SCSI Data-out PDU should not be used for solicited data even though it is 
supported in the iSER draft.  Since this is not a typical usage, the 
burden is left to the iSER/iSCSI layer to keep track of the number of 
"unexpected" PDU that it can send.  What specifically do you want to 
expand on this topic?
]mk]

Third we need to discuss or expand on considering the Reject PDU an 
unsolicited PDU.   Perhaps you meant Rejects for PDUs that are not for the 
Command itself. 

[mk[
I will replace the phrase "A Reject PDU is considered "unexpected"" with 
the following:
For a task which has never been active before the Reject PDU is sent, the 
target should not send any further responses because the command itself is 
discarded (see section 6.3 of RFC3720).  Therefore, this type of Reject 
PDU is expecetd.  All other Reject PDUs are "unexpected".
]mk]
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: [email-masked] 

Mike Ko <[email-masked]>  
Sent by: [email-masked] 

10/14/2004 09:36 PM 

To
<[email-masked]> 
cc

Subject
[Ips] New iSCSI key

If we do decide on adding a new iSCSI key to limit the number of 
"unexpected"
or "unanticipated" PDUs, I offer the following text to be considered for 
adding
to section 6 of the iSER draft.

Currently the key is tentatively called "MaxOutstandingUnexpectedPDUs". 
Unless
there are other suggestions, this name will be used.

Use: LO (leading only), Declarative
Senders: Initiator and Target
Scope: SW (session-wide)
Irrelevant when: RDMAExtensions=No
MaxOutstandingUnexpectedPDUs=<numerical-value-from-0-to-(2**64-1) | None>
Default is None

This key is used by the initiator and the target to declare the maximum 
number
of outstanding "unexpected" control-type PDUs that it can receive.  It is
intended to allow the receiving side to determine the amount of buffer
resoruces needed beyond the normal flow control mechanism available in 
iSCSI.
An initiator or target that cannot function properly without any limit on
MaxOutstandingUnexpectedPDU (which is the default) should choose a value 
such
that it would not impose an unnecessary constraint on the iSCSI layer 
under
normal circumstances.  The proper value to use is implementation 
dependent.  If
the sending side fails to adhere to the declared limit as set by the 
receiving
side, it is up to the receiving side to determine ways of handling the 
overrun,
including dropping the connection.

For control-type PDUs sent by an initiator to a target, where the 
immediate
flag is not set, the command numbering mechanism regulates the maximum 
number
of PDUs that the target can expect.  The exceptions include the SNACK PDU, 

the
SCSI Data-out PDU, and any PDU with the immediate flag set.

1. The SNACK PDU is not needed in iSER (see section 7.3.11).  But if one 
is
requested for transmission by the iSCSI layer at the initiator, it will be 

sent
by the iSER layer as a control-type PDU.  Since it is "unexpected", the 
number
that can be sent by the initiator falls under the 
MaxOutstandingUnexpectedPDU
declared by the target.  The PDU is outstanding until the target responds 
with
a control-type PDU with ExpCmdSN set to X + 1 where X is the CmdSN of the
referenced command.

2. For unsolicited SCSI Data-out PDU, the target can use FirstBurstLength 
to
determine the amount of buffering required.  Solicited data are normally
handled using the R2T mechanism (see section 7.3.4).  However, if a SCSI
Data-out PDU containing solicited data is requested for transmission by 
the
iSCSI layer at the initiator, the iSER layer may send it as unsolciited 
data.
Since it is "unexpected", the number that can be sent by the initiator 
falls
under the MaxOutstandingUnexpectedPDU declared by the target.  The PDU is
outstanding until the target responds with a control-type PDU with 
ExpCmdSN set
to X + 1 where X is the CmdSN of the referenced command.

3. A PDU with the immediate flag set is considered "unexpected", and the 
number
that can be sent by the initiator falls under the 
MaxOutstandingUnexpectedPDU
declared by the target.  The PDU is outstanding until the target responds 
with
a control-type PDU with ExpCmdSN set to X + 1 where X is the CmdSN of the 
PDU
with the immediate flag set.

Control-type PDUs sent by a target as a response to a request from an 
initiator
are expected by the initiator and buffer resources required can be 
provisioned.
The exceptions include the SCSI Data-in PDU, the R2T PDU, the Asynchronous
Message PDU, the Reject PDU, and the NOP-in PDU.

1. A SCSI Data-in PDU is a data-type PDU and is transformed into RDMA 
Write
operations (see section 7.3.5).

2. An R2T PDU is a data-type PDU and is transformed into RDMA Read 
operations
(see section 7.3.6).

3. An Asynchronous Message PDU is considered "unexpected", and the number 
that
can be sent by the target falls under the MaxOutstandingUnexpectedPDU 
declared
by the initiator.  The PDU is outstanding until the initiator sends a
control-type PDU with ExpStatSN set to X + 1 where X is the StatSN of the
Asychronous Message PDU.

4. A Reject PDU is considered "unexpected", and the number that can be 
sent by
the target falls under the MaxOutstandingUnexpectedPDU declared by the
initiator.  The PDU is outstanding until the initiator sends a 
control-type PDU
with ExpStatSN set to X + 1 where X is the StatSN of the Reject PDU.

5. A NOP-in PDU sent as a response by the target to a NOP-out PDU from the
initiator is expected by the initiator.  Otherwise, a NOP-out PDU is 
considered
"unexpected", and the number that can be sent by the target falls under 
the
MaxOutstandingUnexpectedPDU declared by the initiator.  The PDU is 
outstanding
until the initiator sends a control-type PDU with ExpStatSN set to X + 1 
where
X is the StatSN of the NOP-in PDU.

Mike

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Mike Ko <[email-masked]>
Date: Fri, 15 Oct 2004 13:23:36 -0700

John,
Here is the replacement paragraph for the SCSI Data-out PDU:

2. Unsolicited data in a SCSI write operation are sent by the iSCSI layer 
at
the initiator using SCSI Data-out PDUs.  The iSER layer at the target can 
use
FirstBurstLength to determine the amount of buffering required.  For 
solicited
data, an R2T PDU sent by the iSCSI layer at the target is transformed by 
the
iSER layer at the target into an RDMA Read operation (see section 7.3.6).
Therefore the iSCSI layer at the initiator should not be issuing SCSI 
Data-out
PDUs for solicited data.  If a SCSI Data-out PDU containing solicited data 
is
requested for transmission by the iSCSI layer at the initiator anyway, the 
iSER
layer may send it as a control-type PDU (see section 7.3.4).  Since it is
"unexpected", the number that can be sent by the initiator falls under the
MaxOutstandingUnexpectedPDU declared by the target.  The PDU is 
outstanding
until the target responds with a control-type PDU with ExpCmdSN set to X + 
1
where X is the CmdSN of the referenced command.

Mike
Sent by:        [email-masked]
To:     John Hufferd/San Jose/IBM@IBMUS
cc:     [email-masked] 
Subject:        Re: [Ips] New iSCSI key

John,

Mike

To:     Mike Ko/Almaden/IBM
cc:     [email-masked]

Mike,

Mike Ko/Almaden/IBM
10/15/2004 10:01 AM

To

John,

Mike

Mike,

[mk[

[mk[

[mk[

10/14/2004 09:36 PM

To
<[email-masked]>
cc

Subject
[Ips] New iSCSI key

the

sent

Mike