RE: draft-carrier-rddp-rnic-interop-00.txt

 

Commenting to 5), the reason why both CreateQP and ModifyQP is needed is
because some protocols (notably ISER) don't want to negotiate RDMA
capability unless they know that resources are available for RDMA.  So I
would expect this class of protocols to first do a CreateQP before
exchanging keys. At this time, you don't know what the version number
will be negotiated to (assuming the interoperability protocol suggested
in the draft), thus only after reception of a REQ/REP frame do you set
the version number, which must be done using a ModifyQP.

 

On 4), possibly the wording could be improved. It really comes down to
RDMAC versions which wish to interoperate with IETF versions. Those that
don't try, won't :-)

 

Mike, with the exceptions of the concerns on changes to MPA/DDP/RDMAP to
give the right level of "escape hatch", does the approach appear sound?
Note that the ambiguity in some of them has to work the other way - make
it more ambiguous - i.e. if you are able to talk with version 0, allow
you to do so (current text prohibits it).

 

 

 

Jim

 

 

 

________________________________

From: [email protected] [mailto:[email protected]] On Behalf Of
Michael Krause
Sent: Monday, November 29, 2004 11:11 AM
To: [email protected]
Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt

 

At 06:40 PM 11/23/2004, Jim Pinkerton wrote:





Feedback is appreciated on this draft. This was a result of an informal
group working over beers after the RDDP work group meeting gave us
direction to try to solve interoperability as an informative appendix to
the MPA specification. 

John and I tried to be very specific about the exact recommended text
changes for the various drafts, to hopefully expedite the review process
with something concrete to shoot at.


Initial comments.

Mike

(1) It is not clear to me where there is ambiguity within the
specifications.  The RDMAP specification (draft-ietf-rddp-rdmap-02.txt)
section 6.1 states that the RDMA version MUST be 01b.  The table in
section 6.8 states that a remote operation error is generated for a
RDMAP version error.  The RDMAC RDMAP specification contains the same
language but states the version MUST be 00b.  As such, it clear what the
version must be and the error that should be returned if there is a
version mismatch which contradicts the assertions made in section 3 of
the interop draft.

(2) The DDP specification (draft-ietf-rddp-ddp-03.txt) section 4.1
states the DV bits must be set to 1.  Section 7.2 states that an invalid
version must be returned upon detecting a mismatch and section 7.1
states that upon error detection, DDP  must stop placing segments and
return an error to the ULP.  In this case, it would be to surface an
error to RDMA.  The RDMAC DDP specification contains the same language
but states the version MUST be 00b.  Again, this contradicts the
assertions made in section 3 of the interop draft.

(3) I agree that there are three cases of implementations that can
exist.  However, it seems that the specifications are relatively clear
on what the versions must be for each set of specifications.  It is also
clear what the expected behavior should be as well, i.e. the generation
/ surfacing of an error.  As such, a RDMAC implementation would require
the version to be 0 to be compliant while the IETF implementations would
require the version to be 1.  The only way to achieve interoperability
is to set the appropriate version number prior to a connection
transition to RDMA / DDP mode.  

(4) A RDMAC-only implementation would not negotiate MPA since this is
not part of the RDMAC specifications.  The draft implies that any RDMAC
compliant implementation would be augmented to provide MPA negotiation.
I don't see how this can be required - at best, it is an option to
implement and may or may not be present on a given endnode.  If this is
not implemented, the two sides will simply fail the RDMA stream
establishment.  In general, the tables showing the negotiation at the
MPA level look reasonable.

(5) It is not clear that new verbs extensions are required for
interoperability.  The verbs specification section 9.3 already states
how a version mismatch (DDP or RDMA) should be surfaced.  There is value
in being able to configure a RNIC (on a per session basis) as to what
version to support.  This should be done once and cause all layers to
use a consistent version for a given QP.  The value should be set at QP
creation and then updated upon session establishment if the RNIC can
support both RDMAC and IETF specifications.  I also see value in having
the query what the current version is.  I don't see why a ModifyQP is
required as one knows up front what is desired and the implementation if
permissive, would negotiate accordingly.  Therefore all that is needed
is to understand the result.

_______________________________________________
rddp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rddp