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

[Nicolas Williams <[e-mail]>]

On Wed, Jul 01, 2009 at 05:37:10PM -0700, Mike Eisler wrote:
> Isn't this DISCUSS specific to SCTP? Russ writes in the DISCUSS:

Sortof.

Russ wrote, at one point:

| This is the point.  I do not think that hangs until killed or
| restarted should be on this menu.

with respect to the default handling of latch breaks when no additional
APIs are available (or used by the application).

IMO it's a generic issue.

My earlier opinion was that pretending that bits aren't moving is the
right thing to do because applications ought to have timeout handling,
if not even ULPs (think of SO_KEEPALIVE).  After all, latch break is not
fatal -- state transitions from BROKEN to ESTABLISHED are allowed.

But reasonable people can disagree about that.  A latch break is likely
to be permanent in practice, and in any case, acting as though the
connection has been reset (as in valid RST received) is no more or less
harmful than acting as though bits aren't moving.

Also, a latch break may be indicative of an attack, and so resetting the
connection may be a better action[*].

To a reply along those likes Russ wrote back:

| I'm happy with a SHOULD statement that the WG agrees is appropriate
| to handle the situation gracefully.

This thread is all about obtaining WG consensus on this issue, so we can
clear this DISCUSS.  All we need is consensus.

I'll be happy with either possible default behavior on the face of latch
breaks: act as if the connection was reset, or act as if bits aren't
moving.

I'd also be happy to require that implementors pick and implement one of
those two, without us giving a recommendation.  After all, neither
default affects interoperability, so why should we recommend or require
one or the other?

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

Surely SCTP, and any connection-oriented ULP, must have a way to reset
connections, just like TCP does.  A latch break causing a connection
reset would not be new behavior as far as applications go.

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

APIs are nice, but existing apps won't use them until updated, and
anyways, connection latching adds value even without adding APIs, which
means we need a default response to latch breaks in the absence of new
APIs (either because not implemented or not used).

[*] Or not -- if the app is not doing authentication at all and the user
    is not doing leap-of-faith, then resetting the connection would be
    bad.  But then, the user can always interrupt the application and try
    again.

Nico
--