[btns] Q: How to deal with connection latch breaks?

[Mike Eisler]

Note: This is my first email to this list. The catalyst for this
email was that several documents that I'm authoring indirectly depend
on draft-ietf-btns-connection-latching moving forward ...

> The last DISCUSS on draft-ietf-btns-connection-latching-10
> concerns what the WG thinks is the best way for ULPs to
> handle connection latch transitions to the BROKEN state in
> the _absence_ of connection latching APIs for applications
> (or when apps are not aware of such APIs).

Isn't this DISCUSS specific to SCTP? Russ writes in the DISCUSS:

I am unsure that the SCTP section defines behavior which is consistent with
application expectations.  The last paragraph of 5.4 implies that the whole
connection terminates if one of the latches breaks.  This has an impact on
the
semantics of the application socket API.  While connection latching is
transparent when everything is working, there are new failures that ripple to
the application.  That is, the application will observe different behavior
on a
connection with and without latching.

My conclusion is that the API ought to provide information for the
application
about the connection latching, and it just does not seem to be there.  If you
can point me to a discussion of this topic on the WG mail list, then I'll
clear.  I'm not trying to alter consensus, but I do want to make sure that
this
topic was considered.

======================

The laat paragraph of section 5.4 says:

"When a connection latch transitions to the BROKEN state and the
   application requested (or system policy dictates it) that the
   connection be broken, then SCTP should inform the application, if
   there is a way to do so, or else it should wait, allowing SCTP path/
   endpoint failure detection (and/or application-layer keepalive
   strategy) to timeout the connection.  When a connection latch is
   administratively transitioned to the CLOSED state then SCTP should
   act as though an ABORT chunk has been received."

Note the inconsistency between what Russ wrote in his DISCUSS:

"The last paragraph of 5.4 implies that the whole
connection terminates if one of the latches breaks."

and this excerpt from the last paragraph of section 5.4:

"When a connection latch transitions to the BROKEN state and the
   application requested (or system policy dictates it) that the
   connection be broken,"

So actually the last paragraph is unequivocal: the connection
does terminate if two conditions are met:
- the latch goes to BROKEN
- the app or policy has previously dictated that a latch break produces
  a connection break.

Earlier in Section 5.4, two alternatives to mapping latches to multi-homed
SCTP connections:

"We can represent the multiplicity of SCTP association end-point
   addresses as a multiplicity of 5-tuples, each of which with its own a
   connection latch.  Alternatively we can extend the connection latch
   object to support a multiplicity of addresses for each end-point.
   The first approach is used throughout this document, therefore we
   will assume that representation."

Perhaps the second approach is what should be used for SCTP. However, as
the last sentence above notes, the first approach is used in the rest
of the document. I gather what Russ is saying is that approach might
not be appropriate for SCTP and he wants to know if the WG thoroughly
considered it.

In the event the WG did not thoroughly consider the implications
of multi-homed SCTP connections and latching, here is a pragmatic
suggestion:

- remove the SCTP discussion from the I-D. Most this means removing
  section 5.4, but there are a couple sentences that mention SCTP that
  would also need to be removed.

- if there is sufficient interest in SCTP and connection latching,
  channel binding, etc., then start a new work item to deal with
  the issue of connection latching with multi-homed connection-oriented
  transports.


-------------------------------------------------------

Nico wrote:

    * From: Nicolas Williams <Nicolas.Williams at sun.com>
    * To: btns at ietf.org
    * Date: Wed, 24 Jun 2009 15:17:07 -0500

The last DISCUSS on draft-ietf-btns-connection-latching-10 concerns what
the WG thinks is the best way for ULPs to handle connection latch
transitions to the BROKEN state in the _absence_ of connection latching
APIs for applications (or when apps are not aware of such APIs).

The two options are:

a) The ULP MAY/SHOULD/MUST pretend that the equivalent of a TCP reset
   occurred and the connection latch is transition to the CLOSED state
   (and destroyed/cleaned up);

b) The ULP MAY/SHOULD/MUST act as though bits aren't moving and let ULP
   and/or application-layer timeout processing decide if and when to
   close the connection (and underlying connection latch).

(b) means potentially hanging forever, but that's generally true now
with existing ULPs.

The I-D says (b), with "SHOULD".

I'd be just as happy with (a), SHOULD, (b) MAY.  I would not be happy
with (a), MUST, nor with (b), MUST.

Comments?

Nico
-- 


-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/




-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/



_______________________________________________
btns mailing list
btns at ietf.org
https://www.ietf.org/mailman/listinfo/btns

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE