[mif] draft-deng-mif-api-session-continuity-guide-02

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 17 July 2012 13:10 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0E21F86AB for <mif@ietfa.amsl.com>; Tue, 17 Jul 2012 06:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.352
X-Spam-Level:
X-Spam-Status: No, score=-103.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq1lmmfFABzv for <mif@ietfa.amsl.com>; Tue, 17 Jul 2012 06:10:26 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0C8221F86CE for <mif@ietf.org>; Tue, 17 Jul 2012 06:10:25 -0700 (PDT)
Received: by eekc1 with SMTP id c1so175423eek.31 for <mif@ietf.org>; Tue, 17 Jul 2012 06:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=5+U+8g7xX2zmXjgeymBw+hPlNsAjo2ilnlzsdfddFdE=; b=r89oQ3avXn5NNhFsfbk/cxycj54l/So2Jf7FGKvHD9euXd7jm2U277yvdZfxZdx/d3 rX3GeMdyw7PPH5TfM7Jc8vll5aBRvrBN+aUxyVUxQYqTbX8aeGtY4nDDlaN6HQdNmh2j 4+dfnJ+jPrNzZkx0dFPNxqYbf/N2OrwOmddUcnCQe1Yvlgcwl69zL9+MCs5tJbRajqOL d/H5hBufMHOPO2K0nPMp8mN7Ns1MVeP9pRnpSkef0JN9FW6fswKRL7Gx/TI1C+Giq8W+ 72oeFQLqvp+7QBfLgvfhOk/+hhX1MgdOTgwMCfHKsys06JSlxQiE7CEkHY1mF2/hZ7NC hODQ==
Received: by 10.14.214.196 with SMTP id c44mr2932556eep.7.1342530672776; Tue, 17 Jul 2012 06:11:12 -0700 (PDT)
Received: from [128.232.110.167] (c167.al.cl.cam.ac.uk. [128.232.110.167]) by mx.google.com with ESMTPS id x46sm27529554eel.6.2012.07.17.06.11.11 (version=SSLv3 cipher=OTHER); Tue, 17 Jul 2012 06:11:11 -0700 (PDT)
Message-ID: <50056471.7070708@gmail.com>
Date: Tue, 17 Jul 2012 14:11:13 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: mif@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: [mif] draft-deng-mif-api-session-continuity-guide-02
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2012 13:10:31 -0000

Hi,

If the interface changes I can understand how this works from the
application's point of view: it discovers experimentally whether it has
a working path via the new interface. Nothing new there, really.

If the host's address changes too, I don't find the discussion in
section 3 very helpful. Saying that the application ought to be able
to handle this really says nothing. And of course there are other
approaches possible, by having either the transport layer or the
network layer handle it. We have at least three existence proofs for
such solutions (SCTP, MPTCP and shim6). They all need tweaking for the
case of a brand-new address being added, and 6renum needs that tweak
too.

A related point is that load balancers at the server end are part
of the problem too, if you want to preserve sessions across a
re-addressing event.

I think section 3 is just the tip of a very complicated iceberg.

Regards
   Brian