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

["Mike Eisler" <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?

>
> 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
> _______________________________________________
> btns mailing list
> btns at ietf.org
> https://www.ietf.org/mailman/listinfo/btns
>


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