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@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