Re: [hybi] NAT reset recovery? Was: Extensibility mechanisms?

"Thomson, Martin" <Martin.Thomson@andrew.com> Tue, 20 April 2010 06:16 UTC

Return-Path: <Martin.Thomson@andrew.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 4F5C83A6A72 for <hybi@core3.amsl.com>; Mon, 19 Apr 2010 23:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.914
X-Spam-Level:
X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599]
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 jKHpSa5Jx7Hg for <hybi@core3.amsl.com>; Mon, 19 Apr 2010 23:16:14 -0700 (PDT)
Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id BBC4D3A6AA0 for <hybi@ietf.org>; Mon, 19 Apr 2010 23:16:04 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:5495 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S18444775Ab0DTGPz (ORCPT <rfc822; hybi@ietf.org>); Tue, 20 Apr 2010 01:15:55 -0500
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 20 Apr 2010 01:15:55 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 20 Apr 2010 14:15:53 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Pieter Hintjens <ph@imatix.com>, Jamie Lokier <jamie@shareable.org>
Date: Tue, 20 Apr 2010 14:17:21 +0800
Thread-Topic: [hybi] NAT reset recovery? Was: Extensibility mechanisms?
Thread-Index: AcrgTvQnApmteXUaSny7rKTiU724LAAARuTA
Message-ID: <8B0A9FCBB9832F43971E38010638454F03E7D06A36@SISPE7MB1.commscope.com>
References: <20100419091736.GA28758@shareable.org> <B3F72E5548B10A4A8E6F4795430F841832040920C4@NOK-EUMSG-02.mgdnok.nokia.com> <20100419121000.GG28758@shareable.org> <87764B8E-5872-40EE-AA2F-D4E659B94F63@d2dx.com> <20100419140423.GC3631@shareable.org> <6959E9B3-B1AC-4AFB-A53D-AB3BA340208C@d2dx.com> <B3F72E5548B10A4A8E6F4795430F841832040F78C0@NOK-EUMSG-02.mgdnok.nokia.com> <w2q5821ea241004191309t7362de42p922788d380119dc4@mail.gmail.com> <B3F72E5548B10A4A8E6F4795430F841832040F78DB@NOK-EUMSG-02.mgdnok.nokia.com> <20100420013220.GC21899@shareable.org> <l2s5821ea241004192301u692d2344y8da146470a68ab75@mail.gmail.com>
In-Reply-To: <l2s5821ea241004192301u692d2344y8da146470a68ab75@mail.gmail.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: "hybi@ietf.org" <hybi@ietf.org>, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>
Subject: Re: [hybi] NAT reset recovery? Was: Extensibility mechanisms?
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: Tue, 20 Apr 2010 06:16:15 -0000

-Pieter:
> In AMQP each peer tells the other, during connection negotiation,
> "please send me KA's at this interval".  Peers that do not respect
> that (don't sent KAs) are disconnected.

That doesn't seem helpful.  Each peer knows what it wants and it can initiate keep-alives based on its own needs.  Forcing the other peer to acquiesce doesn't add value.

Furthermore, you don't need a response, TCP provides ACKs.  A one-way exchange of as little as a single byte should be enough to keep any bindings alive in (TCP) intermediaries.

If you want to step a layer up to WebSocket intermediaries the ping concept works there.  I'm not convinced that this is necessary.

--Martin