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

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 4 Aug 2009 08:12:38 -0700

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.

Is this satisfactory? If yes let's document that in a more implementation agnostic way and try to move forward the draft to Approved state.

--julien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Richardson
> Sent: Thursday, July 30, 2009 4:37 AM
> To: Mike Eisler
> Cc: [email-masked]
> Subject: Re: [btns] Q: How to deal with connection latch breaks?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >>>>> "Mike" == Mike Eisler <[email-masked]> writes:
>     >> So, errno value from write(2) is not a new API.  A new errno
>     >> value should provide enough information, I think.
>     >>
>     >> However, an application might know what to do with ETIMEOUT,
>     >> while it would not know what to do with EUNLATCHED or some
>     >> such....
> 
>     Mike> Isn't the application the entity that decided to enable
>     Mike> latching?  If so, the application (or its author) needs to be
>     Mike> prepared to deal with new error indication.
> 
>   It may be enabled by system-policy, in particularly for the passive
> open
> side ("bind()/accept()" side). It could also be enabled by the "inetd"
> equivalent, and then pass that descriptor on.
> 
> - --
> ]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |
> firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] [email-masked] http://www.sandelman.ottawa.on.ca/ |device
> driver[
> ]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby
> guy");  [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQEVAwUBSnGFvYCLcPvd0N1lAQJXagf/eo91+crzqoWgKGDNbStD5nd1xiDkAH4h
> 3bgr4VqkFoxHD7WZExSAM3TNVGPo3209Yerd8fCRrb6EDlXdSxa4ksqksxmdhLl/
> 7sTlbQREvG/x11rE6u0sEZNSUqpQteyDwxG1L5z3lJM3dR5BBKHb/x9uUWD68dla
> 8wJdt4RioUDT4hFos+FilNhUef14ITWBTMIs5B9M5prLXKrmXkiRffSJ0JqIorIX
> vYZfdfr7V6cSKxhDNLXFYp62K5h3vXU2z+1Tp2aE6187zQQX/paIsGa1DCedexbG
> 6RlhXgenQTRnMZbRHDeTNDX+fqY/Pyfk6nDCdFt4hN5BJXMh/Ltj8g==
> =rlxH
> -----END PGP SIGNATURE-----
> _______________________________________________
> btns mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/btns

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 5 Aug 2009 00:06:58 -0700

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:
>
> 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?

>
> Is this satisfactory? If yes let's document that in a more implementation
> agnostic way and try to move forward the draft to Approved state.
>
> --julien
>
>

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

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 5 Aug 2009 03:47:15 -0700

> From: Mike Eisler [mailto:[email-masked]]
> 

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2009 10:54:59 -0400

>>>>> "Julien" == Julien Laganier <Laganier> writes:
    Julien> Sorry I messed up. It should read:

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

I concur.
Let's write:
      ETIMEOUT SHOULD be returned to applications when a broken connection
      latch causes communications to fail.  This is consistent with what
      would happen if a cable was unplugged, etc.

      Applications which have used a BTNS API to request a latched
      connection MAY receive a more detailed error to indicate if 
      the communication failure is a result of a connection latch
      being broken.  The details of this process are defined in an API
      document.

(I am hoping that we can find a way to avoid a direct reference to the
API document, as that would hold things up further)

-- 
]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby  guy");  [