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