Subject: RE: [rddp] MPA issue (3): Rejected Connection bit

From: "Carrier, John" <[email-masked]>
Date: Tue, 6 Apr 2004 16:32:09 -0700

I guess I would like to hear a clarification for how the rejected bit would be used.  

In the startup scenarios described in the MPA draft, when the MPA Responder sends the MPA Reply Frame, the responder 'binds' DDP to MPA so that, after sending the reply frame, the MPA Responder will be ready to receive FPDUs and pass them to DDP.  If the Request Frame is invalid or if the private data is unacceptable, then the ULP should close the connection without sending a Reply Frame.  

Adding the rejected bit enables the ULP to send a Reply Frame without binding DDP to MPA.  The Reply Frame may also contain private data that further describes why the request was rejected.   

If that is the intent, then what should the state of MPA be after sending the Reply Frame with the rejected bit set?  Does it return to 'responder mode' so that the Initiator can resend the MPA Request Frame or does it transition to a new state where it drops any received data while it waits for the ULP to close the connection?

If this has already been discussed on the list, please point me to the thread.

thanks.

--jc

John Carrier
Adaptec

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Monday, March 29, 2004 5:21 PM
> To: [email-masked]
> Subject: [rddp] MPA issue (3): Rejected Connection bit
> 
> 
> Moving on to issue (3), the Seoul minutes say:
> 
>   (3) Rejected Connection bit. Dissension expressed, this leads to 
>   interoperability issues because it forces a ULP to 
> interpret private 
>   data to figure out that the connection setup failed, and requires
>   MPA to handle TCP close specially (more detail in mail to list).
>   Further discussion: 
> 
>   Q: If MPA does not do "teardown", why is the bit needed to 
>    free resources at MPA layer? 
>   A: Practically speaking, implementations will allocate and free 
>    resources in MPA (e.g. connection model in kernel), this enables 
>    layering and better control. 
>   A: The bit will prevent some timed-wait resource consumption issues,
>    if used properly (this is about cooperating systems, not malicious
>    resource consumption attacks).
> 
>   Rough consensus in room to include the bit. Take to list.
> 
> I suggest to the WG that the right thing to do is include this bit
> because it produces better behavior in an important error case for
> cooperative clients where something is misconfigured.  This bit
> allows the RDDP layers to immediately know that a connection setup
> has failed and release/reuse any resources committed to it without
> waiting for a ULP to look at the private data that came back.  It
> also ties the fact that the connection is closing with the
> associated private data unambiguously (both can be immediately
> logged at RDDP level).  Yes, this is optimizing an error case,
> but it seems to be common enough/of sufficient concern to be
> worth spending a bit on.  That was where the discussion among
> the subset of us who were in Seoul wound up.
> 
> Comments?  I intend to let the technical discussion run on this
> before trying to call consensus on the list.
> 
> Thanks,
> --David
> 
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> 

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 7 Apr 2004 00:33:12 -0500 (CDT)

Carrier, John said:
> In the startup scenarios described in the MPA draft, when the MPA
> Responder sends the MPA Reply Frame, the responder 'binds' DDP to MPA so
> that, after sending the reply frame, the MPA Responder will be ready to
> receive FPDUs and pass them to DDP.  If the Request Frame is invalid or if
> the private data is unacceptable, then the ULP should close the connection
> without sending a Reply Frame.
>
> Adding the rejected bit enables the ULP to send a Reply Frame without
> binding DDP to MPA.  The Reply Frame may also contain private data that
> further describes why the request was rejected.
>
Exactly.

The typical use is when the private data sent by the active side was
unacceptable to the passive side, or for some other ULP reason the
connection is not to proceed further.

This capability is assumed by RDMA-aware APIs such as uDAPL and
IT-API. Without this capability they must simulate the rejection bit
by sending options that they know will be rejected. An "honest"
reject bit is a far cleaner solution.

>
> If that is the intent, then what should the state of MPA be after sending
> the Reply Frame with the rejected bit set?  Does it return to 'responder
> mode' so that the Initiator can resend the MPA Request Frame or does it
> transition to a new state where it drops any received data while it waits
> for the ULP to close the connection?
>

To be technically precise, it means that the TCP connection does not
enter the MPA state. What, if anything, happens to the TCP connection
after that might not be in scope (unless someone has a strong reason
why something should be specified).

For both uDAPL and IT-API (so far) the connection should be torn down.
But in those contexts the LLP connection was created "under the covers"
by the API layer for the purpose of supporting an Endpoint.

There will likely be API extensions that expose the LLP connection,
allowing the applicication to request that this TCP connection be used
to initiate an MPA connection for this endpoint. In that case I suppose
it would be slightly preferable for a failure to leave the TCP connection
intact in case the application wishes to continue in non-MPA mode.

But if we were to decide that the reject bit mandated a TCP disconnect,
there would be numerous methods available to an "optional RDMA:"
application to determine the mode that will succeed *before* sending
MPA Start frames.

The intent of the bit is to optimize the large class of applications that
know they will be using RDMA from the start, and wish to engage in
a simple negotiation before proceeding or terminating the connection.