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

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

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: btns-bounces at ietf.org [mailto:btns-bounces at ietf.org] On Behalf Of
> Michael Richardson
> Sent: Thursday, July 30, 2009 4:37 AM
> To: Mike Eisler
> Cc: btns at ietf.org
> Subject: Re: [btns] Q: How to deal with connection latch breaks?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >>>>> "Mike" == Mike Eisler <mre-ietf at eisler.com> 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[
> ] mcr at sandelman.ottawa.on.ca 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
> btns at ietf.org
> https://www.ietf.org/mailman/listinfo/btns