MPA issue (3): Rejected Connection bit

[email protected]
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
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
----------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.