Re: [storm] iSER - one last issue

[Tom Talpey <[e-mail]>]

Thanks for pointing out that sentence in RFC5046 7.3.4. I believe it is the only such stipulation.

I'm ok with stating the requirement as RFC5046-over-RFC5040 compliance. But this new draft opens the door to alternative behaviors, therefore it needs to be stated more clearly. What's the requirement when SendSE is not supported? And, how does the receiver know what to expect?

In other words, if it's proposed that the statement be:
                "When the RCaP layer is as specified in [RFC5040] and [RFC5041], the SendSE message MUST be used."

... then what MUST be used when the RCaP is not? That statement needs to be made, too.


From: Hemal Shah [mailto:[e-mail]]
Sent: Thursday, January 19, 2012 10:38 AM
To: Tom Talpey; [e-mail]; [e-mail]; [e-mail]
Subject: RE: iSER - one last issue

Tom,

RFC5046 is very clear about the use of Send Message Type for iSCSI control-type PDU. For specific iSCSI PDUs, Section 7 mandates the use of Send, SendSE, or SendSEInv. Section 7 of RFC5046 clearly specifies the use of specific Send Message Type for each iSCSI control-type PDUs (Login, Logout, Text request, Text response...). Section 7.3.4 mandates the use of plain-old Send also as needed. For example, see text below from 7.3.4.

For unsolicited data, if the F bit is set to 0 in a SCSI Data-out
PDU, the iSER layer at the initiator MUST use a Send Message to send
the SCSI Data-out PDU.

Regarding your comment in the second paragraph below, RFC5040 expectation is all the RDMAP messages specified in RFC5040 are supported (if that is not the case then we cannot count on any of the other RDMAP messages to be supported). So, an implementation that does not support SendSE at the sender is not compliant with RFC5040. So, your second point does not apply.

I hope that addresses your comments.

Hemal

From: Tom Talpey [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Thursday, January 19, 2012 5:51 AM
To: Hemal Shah; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: iSER - one last issue

If using SendSE is so important here, when MUST a plain-old Send be used? There is no mention of any distinction in RFC5046 section 1.4.2 nor in this draft's section 2.4.2.

Even with a MUST on the SendSE, the behavior is indeterminate, since it would still be contingent on support for SendSE at the *sender*. This critical exception voids any normative requirement, even over iWARP. The strongest statement that can be made is SHOULD.

Tom.

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Hemal Shah
Sent: Wednesday, January 18, 2012 6:56 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [storm] iSER - one last issue

David and Mike,

I believe that the requirements should not be weakened and we should stick to the requirement in RFC5046.

RFC5046 required the use of specific Send Message Type for valid reasons.

In the case of requiring SendSE message use, the intent was to give a hint to the remote side to generate an event upon processing of SendSE message. For example, the SendSE is specifically carrying SCSI information that needs attention on the remote side e.g. SCSI command, Logout...

In the case of requiring SendInvSE Message, the intent was to invalidate the STag used in the data transfer as well as inform the remote side to generate an event. For example, mandating the use of SendInvSE for the SCSI response PDU for a SCSI Read limits the exposure of STag used in SCSI Read data transfer and avoids the explicit invalidation of the STag at the initiator. Plus, it allows the target to generate an event on the initiator upon the completion of SCSI Read command.

By relaxing RFC5046 requirements in the latest iSER draft, we will not only impact all iWARP based iSER implementations that rely on the use of specific Send Message Type for SCSI data transfers but also change the intended behavior of initiators and targets.

For iWARP, I strongly suggest that the iSER draft does not relax the requirements specified in RFC5046.

I hope that helps.

Hemal

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Wednesday, January 18, 2012 3:10 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [storm] iSER - one last issue

Mike,

Thank you for the explanation, but I don't believe you've correctly stated
the intent of RFC 5046.  Here are some examples from RFC 5046's text:

1.5.  SCSI Read Overview

   The iSER Message is transferred to the target using a SendSE Message.

   The iSER layer at the target uses a SendInvSE Message to transfer the
   SCSI Response PDU back to the iSER layer at the initiator.

Similar language occurs in 1.6 SCSI Write Overview.

5.2.1.  Normal Connection Termination at the Initiator

   The iSER layer at the initiator MUST
   use a SendSE Message to send the Logout Request PDU to the target.

Similar language occurs in 5.2.2 for target side normal connection termination,
and more importantly in 7.3.1 SCSI Command:

   The iSER layer at the initiator MUST send the SCSI command in a
   SendSE Message to the target.

None of the quoted text permits use of Send instead of SendSE or SendInv
instead of SendInvSE.

What you propose to do effectively changes "MUST" to "should" (lower case,
weaker than "SHOULD"), and that sure looks like a change to RFC 5046.

Are there good implementation-based reasons to weaken these requirements now?

Does anyone else have a viewpoint on this topic?

Thanks,
--David

From: Michael Ko [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Wednesday, January 18, 2012 2:22 PM
To: Black, David; [e-mail]<mailto:[e-mail]>
Subject: Re: iSER - one last issue

David,

Here is my rationale for using the lower case "should".

The intent of RFC5046 is that the Send Message type must be used instead of RDMA Reads or Writes.  The Solicited Event feature of the Send Message is provided as a convenience.  The receiver must still do the right thing in handling the Send Message regardless of whether the SE feature is used.  In other words, the sender is responsible for using the right format for the message (Send vs RDMA) but the receiver must not rely on the sender to determine how to handle the received message.  The same rationale goes for the Invalidate feature.

Mike
----- Original Message -----
From: [e-mail]<mailto:[e-mail]>
To: [e-mail]<mailto:[e-mail]> ; [e-mail]<mailto:[e-mail]>
Sent: Monday, January 16, 2012 2:06 PM
Subject: iSER - one last issue

Mike,

Thanks for getting the -08 version of the iSER draft posted.  I think that
draft addresses all of the open issues, but I have a question for the WG
about how to express the SendSE and SendInvSE requirements from RFC 5046.

The -08 version of the iSER draft expresses requirements for the SendSE
and SendInvSE messages (this is primarily for iSER over RDDP/iWARP) as:

The SendSE Message should be used if
supported by the RCaP layer (e.g., iWARP).

My reading of RFC 5046 is that its requirements are tighter - to accurately
reflect RFC 5046, I would replace "should" with "MUST" in the above text,
at least for iWARP.

In the alternative, if the "should"s remain, an explanatory item
needs to be added to the Appendix A list of changes from RFC 5046.

What do others think the right course of action is here, use "MUST" or
explain weakening of requirement to "should" ?

Thanks,
--David

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Michael Ko
Sent: Sunday, January 15, 2012 8:43 AM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-08.txt

This version contains all the updates as discussed in the latest exchanges with Hemal Shah and David Black.

Mike
----- Original Message -----
From: [e-mail]<mailto:[e-mail]>
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Sent: Sunday, January 15, 2012 5:40 AM
Subject: [storm] I-D Action: draft-ietf-storm-iser-08.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the STORage Maintenance Working Group of the IETF.

Title           : iSCSI Extensions for RDMA Specification
Author(s)       : Michael Ko
                          Alexander Nezhinsky
Filename        : draft-ietf-storm-iser-08.txt
Pages           : 95
Date            : 2012-01-15

   iSCSI Extensions for RDMA provides the RDMA data transfer capability
   to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol.  An
   RDMA-Capable Protocol provides RDMA Read and Write services, which
   enable data to be transferred directly into SCSI I/O Buffers without
   intermediate data copies.  This document describes the extensions to
   the iSCSI protocol to support RDMA services as provided by an RDMA-
   Capable Protocol.

   This document obsoletes RFC 5046.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-storm-iser-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-storm-iser-08.txt

_______________________________________________
storm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/storm