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

"Laganier, Julien" <julienl@qualcomm.com> Wed, 05 August 2009 10:47 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 B202328C544 for <btns@core3.amsl.com>; Wed, 5 Aug 2009 03:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.653
X-Spam-Level:
X-Spam-Status: No, score=-105.653 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_00=-2.599, 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 iaBpKn7+ULMw for <btns@core3.amsl.com>; Wed, 5 Aug 2009 03:47:22 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 99F533A71A1 for <btns@ietf.org>; Wed, 5 Aug 2009 03:47:22 -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=1249469245; x=1281005245; 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:=20Mike=20Eisler=20<mre-ietf@eisler.com>|CC:=20Michae l=20Richardson=20<mcr@sandelman.ottawa.on.ca>,=0D=0A=20 =20=20=20=20=20=20=20"btns@ietf.org"=0D=0A=09<btns@ietf.o rg>|Date:=20Wed,=205=20Aug=202009=2003:47:15=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:=20AcoVm2MrSB04RvwzSR680B1xkbgcigAHl91Q |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C22ACD10 7@NALASEXMB04.na.qualcomm.com>|References:=20<e2cf27e9875 7db0c8561baadfb3ca335.squirrel@webmail.eisler.com>=0D=0A =20=20=20=20<20090726221331.GS1020@Sun.COM>=20<9481.12487 14083@marajade.sandelman.ca>=0D=0A=20=20=20=20<a0459a6daa 0f2f67ff64eb0b2e328a58.squirrel@webmail.eisler.com>=0D=0A =20=20=20=20<16755.1248953791@marajade.sandelman.ca>=0D =0A=20=20=20=20<BF345F63074F8040B58C00A186FCA57F1C22ACD07 C@NALASEXMB04.na.qualcomm.com>=0D=0A=20<bce30b84d39f3c186 8a8bc75a5458b3b.squirrel@webmail.eisler.com>|In-Reply-To: =20<bce30b84d39f3c1868a8bc75a5458b3b.squirrel@webmail.eis ler.com>|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"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5698"=3B=20a=3D"21688608"; bh=y76blsycmFGc4ivx5OS352j9Z4mUwsmxZjfFpOCoLm0=; b=JEz10QrqJJbNPuPu49fMpeBkhz4izdpR08wotGZYEmz60SmWqcI9muhm R/E4CjGTGp5bPohUeYg8GotY/WuQ/KVIb8COMlEOZjHCAeyl3Gk8w5HT8 FW+44fpwBZ6owgtzDwvh3/4JS54E57NmCygif13S7roCwYCvbzM6cKCLw o=;
X-IronPort-AV: E=McAfee;i="5300,2777,5698"; a="21688608"
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; 05 Aug 2009 03:47:22 -0700
Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n75AlMt1026801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Aug 2009 03:47:23 -0700
Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n75AlIrY026954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Aug 2009 03:47:18 -0700
Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 5 Aug 2009 03:47:18 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Wed, 5 Aug 2009 03:47:17 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Mike Eisler <mre-ietf@eisler.com>
Date: Wed, 5 Aug 2009 03:47:15 -0700
Thread-Topic: [btns] Q: How to deal with connection latch breaks?
Thread-Index: AcoVm2MrSB04RvwzSR680B1xkbgcigAHl91Q
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C22ACD107@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> <bce30b84d39f3c1868a8bc75a5458b3b.squirrel@webmail.eisler.com>
In-Reply-To: <bce30b84d39f3c1868a8bc75a5458b3b.squirrel@webmail.eisler.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
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: Wed, 05 Aug 2009 10:47:23 -0000

> From: Mike Eisler [mailto:mre-ietf@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?

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