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

"Mike Eisler" <mre-ietf@eisler.com> Wed, 05 August 2009 07:12 UTC

Return-Path: <mre-ietf@eisler.com>
X-Original-To: btns@core3.amsl.com
Delivered-To: btns@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC3B3A716C for <btns@core3.amsl.com>; Wed, 5 Aug 2009 00:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.861
X-Spam-Level:
X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Grl7IxnH6p2P for <btns@core3.amsl.com>; Wed, 5 Aug 2009 00:12:38 -0700 (PDT)
Received: from webmail1.sd.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) by core3.amsl.com (Postfix) with ESMTP id 9D8DB28C4CE for <btns@ietf.org>; Wed, 5 Aug 2009 00:12:38 -0700 (PDT)
Received: from webmail.eisler.com (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with ESMTP id 54EB92C197; Wed, 5 Aug 2009 00:06:58 -0700 (PDT)
Received: from 202.3.112.9 (proxying for 202.3.112.9) (SquirrelMail authenticated user mre-ietf@eisler.com) by webmail.eisler.com with HTTP; Wed, 5 Aug 2009 00:06:58 -0700
Message-ID: <bce30b84d39f3c1868a8bc75a5458b3b.squirrel@webmail.eisler.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C22ACD07C@NALASEXMB04.na.qualcomm.com>
References: <e2cf27e98757db0c8561baadfb3ca335.squirrel@webmail.eisler.com> <20090726221331.GS1020@Sun.COM> <9481.1248714083@marajade.sandelman.ca> <a0459a6daa0f2f67ff64eb0b2e328a58.squirrel@webmail.eisler.com> <16755.1248953791@marajade.sandelman.ca> <BF345F63074F8040B58C00A186FCA57F1C22ACD07C@NALASEXMB04.na.qualcomm.com>
Date: Wed, 5 Aug 2009 00:06:58 -0700
From: "Mike Eisler" <mre-ietf@eisler.com>
To: "Laganier, Julien" <julienl@qualcomm.com>
User-Agent: SquirrelMail/1.4.19
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: "btns@ietf.org" <btns@ietf.org>
Subject: Re: [btns] Q: How to deal with connection latch breaks?
X-BeenThere: btns@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <btns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/btns>
List-Post: <mailto:btns@ietf.org>
List-Help: <mailto:btns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2009 07:12:39 -0000

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