[rddp] MPA Reject frame

["Talpey, Thomas" <[e-mail]>]

I have a comment on an issue posted to the mailing list and
replied to in <http://www.ietf.org/internet-drafts/draft-culley-mpa-issueresponses-00.txt>
(Pasted below for reference) The proposal was for an
explicit MPA reject frame, and the response argues that
this is not necessary.

This document, in effect, counters that "reject" is to be
an upper layer issue, that is, private data should carry the
rejection, followed by a connection close. This does not
address the proposal.

The desire is to provide a ULP *independent* mechanism to
support rejection of incoming MPA/RDDP connection requests.
Implementing explicit rejection in MPA requires only a single
bit in the MPA Request/Response header.

It's not at all practical to use a connection closure to indicate
reject, even after an MPA frame. MPA initiators cannot be
expected to wait for a connection closure during startup, nor
could they discern between MPA frames received prior to it,
should it occur.

To leave reject out of the MPA connection, and leave the
issue to upper layers, would invoke many ULP changes, and
wire-level incompatibilities. Incorporation of reject into MPA
is by far the better, and more interoperable, choice.

Tom.


>4  Adding a "rejected connection" bit
>
>   Arkady Kanevsky submitted a comment to the reflector, quoted
>   below:
>
>        The MPA draft now defines very nicely an Initiator/Responder
>        sequence. But it looks deficient for a broad set of ULPs.
>        Most of the client-server ULP uses two type of Responses:
>        "accept" and "reject". The MPA draft does not provide a way
>        to differentiate between these 2 responses.
>
>        Here is one example of an application use. One of the common
>        way the private data is used is to negotiate RDMA Read
>        credits for a connection to be used by RDDP. An Initiator
>        passes in private data a requested RDMA credits. Responder
>        either accepts a connection or rejects a request specifying
>        how many RDMA Read credits it can support.
>
>        Currently the Responder has 2 legal choices.
>        One it can terminate a connection.
>        This does not convey any information to the Initiator.
>
>        The second choice is to generate Responder Frame even though
>        RDMA Read credits requested can not be satisfied.
>        This will establish connection but it can not be used as
>        intended by the Initiator. Initiator can either tear down the
>        established stream mode connection or use connection with
>        Responder RDMA credits supported.
>
>        This is de-facto ULP protocol since Responder Frame will
>        include the RDMA Read credits it can support. On top of that
>        both sides have to agree on the action they will take.
>
>        While ULP can use a protocol over private data to
>        differentiate between accept and reject, given a commonality
>        of this semantic for ULPs we can use one bit from the
>        Reserved area of MPA frame for the Responder frame to
>        differentiate between accept and reject responses.
>
>        Proposal:
>
>        for Responder MPA frame the 1st Reserved bit to be used as
>        accept/reject bit. 0 for accept, 1 for reject.
>
>        The bit will be called Type (T) in figure 7 {of the MPA
>        draft}.
>
>
>   Arkady is mostly correct in his analysis, but he may have missed
>   one point; that is that the initiator has the opportunity and
>   right to examine the private data in the MPA Response Frame before
>   binding DDP to MPA.  It may either complete the connection setup
>   by binding DDP (for an "accepted" connection), or tear the
>   connection down (for a "rejected" connection).  It is also legal
>   for the responder to tear the connection down immediately after
>   sending a "rejected" MPA Response Frame.  In either case, no DDP
>   connection is actually established until both sides have seen the
>   private data in the MPA Response Frame.  In both cases the
>   initiator can get a "reason" for a rejected connection.  The
>   choice is up to the ULP and can be encoded into the response
>   private data just as easily as in a specific bit.
>
>        Note: it is also legal for the responder to tear down the TCP
>        connection before sending a response frame, although this
>        offers no opportunity to send a "rejected reason".  Again the
>        choice is up to the ULP.
>
>   Putting the accept/reject bit in a standard place would be useful
>   if MPA or another standard layer needed to examine that bit for
>   its own uses.  As currently defined, however, MPA must send
>   private data to the ULP for examination, and depends on the ULP
>   for the next step (continue or teardown).  So MPA could not do
>   anything with that bit other than pass it on to the ULP.
>
>   The author believes that defining an "accept/reject" bit is not
>   necessary, that the response private data allows all the room for
>   such information necessary (including more detailed reasons if the
>   ULP needs them).  Adding such a bit would also require adding
>   another input and output command parameter to the MPA ULP
>   interface which may be insufficient for many applications anyway.