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

Michael Richardson <mcr@sandelman.ottawa.on.ca> Mon, 27 July 2009 16:59 UTC

Return-Path: <mcr@marajade.sandelman.ca>
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 3250E3A681D for <btns@core3.amsl.com>; Mon, 27 Jul 2009 09:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.354
X-Spam-Level:
X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, 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 CZ6eVOlU8dUn for <btns@core3.amsl.com>; Mon, 27 Jul 2009 09:59:19 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 699D728C31A for <btns@ietf.org>; Mon, 27 Jul 2009 09:59:02 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 0229334263; Mon, 27 Jul 2009 16:59:02 +0000 (UTC)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id B85333EC5; Mon, 27 Jul 2009 12:59:01 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: "Mike Eisler" <mre-ietf@eisler.com>
In-Reply-To: <9c45826044715435bb0be450d87679e7.squirrel@webmail.eisler.com>
References: <e2cf27e98757db0c8561baadfb3ca335.squirrel@webmail.eisler.com> <26232.1247424864@marajade.sandelman.ca> <560cfa55891f0b72ce284f1454fa5d50.squirrel@webmail.eisler.com> <7ad6d6db0907201203y12cc245al767b1cc9114ea618@mail.gmail.com> <9c45826044715435bb0be450d87679e7.squirrel@webmail.eisler.com>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 Jul 2009 12:59:01 -0400
Message-ID: <9303.1248713941@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
Cc: btns@ietf.org, lars.eggert@nokia.com
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: Mon, 27 Jul 2009 16:59:20 -0000

>>>>> "Mike" == Mike Eisler <mre-ietf@eisler.com> writes:

    Mike> So how about text (specific places to add this and wording,
    Mike> pending if/when we have consensus) that says:

    Mike> For UDP and TCP, the implementation SHOULD provide an
    Mike> unambiguous indication that the connection drop was due to
    Mike> "unlatching" the connection.

    Mike> For SCTP, the implementation MUST provide an unambiguous
    Mike> indication that the connection drop was due to "unlatching"
    Mike> the connection. Rationale: SCTP is a transport that is
    Mike> "multi-homed"; connection drops should thus be rare, and
    Mike> applications using SCTP will be better able to cope with a
    Mike> drop across all end-points with an unambiguous error
    Mike> indicating an unlatch.

  So, if my stack said EUNLATCHED instead of ETIMEOUT, you'd be happy?

  (Of course, if you unplug all the "cables" to any ULP, and there is some
kind of make-dead process in the ULP, then you get ETIMEOUT eventually,
regardless of any wizardry that SCTP provides...)

-- 
]     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");  [