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

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 27 July 2009 18:13 UTC

Return-Path: <Nicolas.Williams@sun.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 1A65E3A6A30 for <btns@core3.amsl.com>; Mon, 27 Jul 2009 11:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.473
X-Spam-Level:
X-Spam-Status: No, score=-5.473 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 W8D5CfnGt1oW for <btns@core3.amsl.com>; Mon, 27 Jul 2009 11:13:10 -0700 (PDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id CF19F3A6974 for <btns@ietf.org>; Mon, 27 Jul 2009 11:13:09 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6RICZ9C013435 for <btns@ietf.org>; Mon, 27 Jul 2009 18:12:35 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n6RICZwH060257 for <btns@ietf.org>; Mon, 27 Jul 2009 12:12:35 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n6RHsdrl006863; Mon, 27 Jul 2009 12:54:39 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6RHsajI006862; Mon, 27 Jul 2009 12:54:36 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 27 Jul 2009 12:54:36 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Message-ID: <20090727175436.GA1020@Sun.COM>
References: <e2cf27e98757db0c8561baadfb3ca335.squirrel@webmail.eisler.com> <20090726221331.GS1020@Sun.COM> <9481.1248714083@marajade.sandelman.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9481.1248714083@marajade.sandelman.ca>
User-Agent: Mutt/1.5.7i
Cc: btns@ietf.org, Mike Eisler <mre-ietf@eisler.com>, 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 18:13:11 -0000

On Mon, Jul 27, 2009 at 01:01:23PM -0400, Michael Richardson wrote:
>     Nicolas> APIs are nice, but existing apps won't use them until
>     Nicolas> updated, and anyways, connection latching adds value even
>     Nicolas> without adding APIs, which means we need a default response
>     Nicolas> to latch breaks in the absence of new APIs (either because
>     Nicolas> not implemented or not used).
> 
>   So, errno value from write(2) is not a new API.
>   A new errno value should provide enough information, I think.

If an API's definition has a closed set of error codes, then no.  That
said, I believe that's not the case for write(2) and friends.  And, of
course, there may be implementors for whom it's not possible to add new
error codes for existing APIs, thus we must provide a recommendation or
requirement for such implementors.

>   However, an application might know what to do with ETIMEOUT, while it
> would not know what to do with EUNLATCHED or some such....

There's nothing unreasonable about returning ECONNRESET (an existing
error) when the latch breaks IF the application did not use any APIs to
indicate that it knows about latching.

If the errno set for I/O syscalls is not a closed set then there's also
nothing unreasonable about adding EUNLATCHED.

Note that if a latch never breaks then the connection should never
reset.  So EUNLATCHED would only distinguish latch breaks from peer
reboots -- not exactly Earth shaking for an application that is unaware
of latching in the first place.  But for apps that use new APIs
distinguishing latch breaks is important.

I think I/O syscalls return ETIMEDOUT when SO_KEEPALIVE is set and the
connection times out.  Again, distinguishing timeout from latch break in
the application-is-not-using-new-APIs case doesn't seem all that
important.

Nico
--