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

["Laganier, Julien" <julienl at qualcomm.com>]

> From: Mike Eisler [mailto:mre-ietf at eisler.com]
> 
> On Tue, August 4, 2009 8:12 am, Laganier, Julien wrote:
> > Folks,
> >
> > We really need to get to closure on this, as I've been told that NFS
> v4.1
> > has been on hold for 26 weeks because of this, so let's do our best
> to
> > move forward.
> >
> > I understand the remaining issue is how is an application informed
> that a
> > connection latch transitioned to BROKEN as per:
> >
> >    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.
> >
> > It was discussed whether ETIMEOUT or ELATCHBROKEN shall be returned
> to the
> > app, and I proposed that ETIMEOUT be returned to the application that
> > didn't used a BTNS API to request the connection be broken when the
> latch
> > transition to BROKEN, and ETIMEOUT otherwise.
> 
> Julien,
> 
> Your above text suggests returning ETIMEOUT for both cases.
> Is that what you intended, or is ELATCHBROKEN to be returned for one
> of those cases, and if so, which one?

Sorry I messed up. It should read:

ETIMEOUT be returned to the application that didn't used a BTNS API to request the connection be broken when the latch transition to BROKEN, and ELATCHBROKEN otherwise (i.e., the application did use the BTNS API and thus knows what a BROKEN latch and ELACTHBROKEN are, and what to do.)

--julien