Subject: [rddp] MPA issue (3): Rejected Connection bit - Rough Consensus

From: [email-masked]
Date: Wed, 14 Apr 2004 18:58:22 -0400

Closing this issue out, based on the Seoul meeting and
subsequent list discussion, I believe that the rough consensus
of the RDDP WG is to include the rejected connection bit in MPA.

Any further dissension needs to be posted to the list.

Thanks,
--David (RDDP WG chair)
----------------------------------------------------
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
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Monday, March 29, 2004 8: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: Thu, 15 Apr 2004 00:31:08 -0500 (CDT)

> Any further dissension needs to be posted to the list.

I also believe the consensus is that the state of the TCP connection
after the rejection should be under ULP control, meaning it could
be automatically disconnected or returned to ULP control.

However, I believe it has also been shown that the option to return
the TCP connection to the ULP is mostly a theoretical nicety. There
is no identified *need* for such a feature. So if anyone put forward
a scenario where it was difficult to return the TCP connection then
it would probably be agreed to allow the MPA layer to simply
terminate the connection after the Reset bit.

>From both the perspective of an MPA provider and RDMA Consumer,
I prefer the automatic termination. But leaving that decidsion to
the ULP is indeed cleaner layering. And barring a real implementation
issue I suspect clean layering is the stronger argument.

--
Caitlin Bestler - [email-masked]
http://asomi.com/