MPA issue (3): Rejected Connection bit - Rough Consensus

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 protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of [email protected]
> Sent: Monday, March 29, 2004 8:21 PM
> To: [email protected]
> 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 protected]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>