Re: [hybi] Reliable message delivery (was Re: Technical feedback.)

Maciej Stachowiak <mjs@apple.com> Wed, 03 February 2010 01:44 UTC

Return-Path: <mjs@apple.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38E628C140 for <hybi@core3.amsl.com>; Tue, 2 Feb 2010 17:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.369
X-Spam-Level:
X-Spam-Status: No, score=-106.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 3dYpeLd2Ah+M for <hybi@core3.amsl.com>; Tue, 2 Feb 2010 17:44:39 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 44CDF28C13D for <hybi@ietf.org>; Tue, 2 Feb 2010 17:44:39 -0800 (PST)
Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id C438789DCA3D for <hybi@ietf.org>; Tue, 2 Feb 2010 17:45:19 -0800 (PST)
X-AuditID: 11807136-b7bafae000000e8d-46-4b68d52fa5d0
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id 0C.60.03725.F25D86B4; Tue, 2 Feb 2010 17:45:19 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.151.86.222] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX80049CSVISV60@gertie.apple.com> for hybi@ietf.org; Tue, 02 Feb 2010 17:45:19 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <20100203005423.GF32743@shareable.org>
Date: Tue, 02 Feb 2010 17:45:18 -0800
Message-id: <A41CD237-9AA7-4E30-9813-9EE8DB6338B8@apple.com>
References: <20100130144936.GD19124@shareable.org> <5c902b9e1001301552n6efb7969o34110373e3ab4945@mail.gmail.com> <4B672C9D.9010205@ericsson.com> <op.u7gy9bag64w2qv@annevk-t60> <96935605-E8B8-4718-B60F-570FD2C199E4@apple.com> <8B0A9FCBB9832F43971E38010638454F032E5065ED@SISPE7MB1.commscope.com> <20100202012534.GB32743@shareable.org> <8B0A9FCBB9832F43971E38010638454F032E50667D@SISPE7MB1.commscope.com> <D17188F8-4B5B-41B4-993F-7AF0DC0B4D47@apple.com> <5c902b9e1002020905x5f38c65epa82d8b25ff044d6b@mail.gmail.com> <20100203005423.GF32743@shareable.org>
To: Jamie Lokier <jamie@shareable.org>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: Hybi <hybi@ietf.org>, "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [hybi] Reliable message delivery (was Re: Technical feedback.)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2010 01:44:40 -0000

On Feb 2, 2010, at 4:54 PM, Jamie Lokier wrote:

> 
> In a nutshell, there are *two* distinct uses for signalling clean shutdown:
> 
>    1. To avoid the TCP reset hazard.
> 
>    2. To signal that it was a clean shutdown, so there is no protocol
>       uncertainty about what has been processed / what can be retried
>       on another connection.(**)(***)
> 
> shutdown() and lingering close does deal with 1, but it isn't reliable
> for 2 because of all the other things which can look like shutdown().

I think everyone agrees that we need to address #1. I also personally agree with #2.

Also, there's a potential third use:

3. Knowing the other endpoint has definitely received all of your messages sent prior to the close.

I'm not sure, but I think to achieve #3 may require at either a 3-way close handshake, or a close reply message distinct from close initiation. Consider the case both endpoints initiate close at the same time and their messages cross. Then one endpoint may think it is the close initiator, and when it sees the close from the other side, it may think the other side got all of its messages successfully. Another possibility is to make the close response message look different from the close initiation message. Then you can distinguish a close reply from simultaneous close. I haven't yet analyzed whether this is fully sufficient. We may need to explicitly identify the last message received by each side somehow.

Clearly there are subtle issues here, and we'll have to carefully analyze what can go wrong in any close protocol.

Regards,
Maciej