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

"Laganier, Julien" <julienl@qualcomm.com> Tue, 04 August 2009 15:13 UTC

Return-Path: <julienl@qualcomm.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 4FF1028C3C1 for <btns@core3.amsl.com>; Tue, 4 Aug 2009 08:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.299
X-Spam-Level:
X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Iswmi2IhFqFS for <btns@core3.amsl.com>; Tue, 4 Aug 2009 08:13:20 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id EDB0828C3E7 for <btns@ietf.org>; Tue, 4 Aug 2009 08:13:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1249398803; x=1280934803; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Michael=20Richardson=20<mcr@sandelman.ottawa.on.ca >,=0D=0A=20=20=20=20=20=20=20=20Mike=20Eisler=0D=0A=09<mr e-ietf@eisler.com>|CC:=20"btns@ietf.org"=20<btns@ietf.org >|Date:=20Tue,=204=20Aug=202009=2008:12:38=20-0700 |Subject:=20RE:=20[btns]=20Q:=20How=20to=20deal=20with=20 connection=20latch=20breaks?|Thread-Topic:=20[btns]=20Q: =20How=20to=20deal=20with=20connection=20latch=20breaks? |Thread-Index:=20AcoRCgFkruNT/c1ES+uYz4ZY5mecEAEC660Q |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C22ACD07 C@NALASEXMB04.na.qualcomm.com>|References:=20<e2cf27e9875 7db0c8561baadfb3ca335.squirrel@webmail.eisler.com>=0D=0A =09<20090726221331.GS1020@Sun.COM>=09<9481.1248714083@mar ajade.sandelman.ca>=0D=0A=09<a0459a6daa0f2f67ff64eb0b2e32 8a58.squirrel@webmail.eisler.com>=0D=0A=20=20<16755.12489 53791@marajade.sandelman.ca>|In-Reply-To:=20<16755.124895 3791@marajade.sandelman.ca>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5697"=3B=20a=3D"21641610"; bh=65NOYeUjCCm+sQp6rcbta2IlcFUfYudV45FLR9/X3Nk=; b=A5XIfBlNA02+XglxIJzPFHJfKhcdT0k1HolLn+3B2WGKAm/0ZOWbWohU UzJsPZav0HosdR7is6FVqv8vb/D2K9SQNximL8j4286nmRPno00TGuiMS um4A6cRsnte+nK4Odf4Vm57BMBfpTkgkgbUYQtADKvVjzDcTZshfGRlS1 8=;
X-IronPort-AV: E=McAfee;i="5300,2777,5697"; a="21641610"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Aug 2009 08:12:45 -0700
Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n74FCj22032179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Aug 2009 08:12:45 -0700
Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n74FCeUJ010860 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Aug 2009 08:12:40 -0700
Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 4 Aug 2009 08:12:39 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Tue, 4 Aug 2009 08:12:40 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>, Mike Eisler <mre-ietf@eisler.com>
Date: Tue, 4 Aug 2009 08:12:38 -0700
Thread-Topic: [btns] Q: How to deal with connection latch breaks?
Thread-Index: AcoRCgFkruNT/c1ES+uYz4ZY5mecEAEC660Q
Message-ID: <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>
In-Reply-To: <16755.1248953791@marajade.sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 04 Aug 2009 15:13:21 -0000

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@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