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

Hui Deng <denghui02@gmail.com> Wed, 18 July 2012 06:32 UTC

Return-Path: <denghui02@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 BE3DA11E8149 for <mif@ietfa.amsl.com>; Tue, 17 Jul 2012 23:32:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level:
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4mHcmOqje986 for <mif@ietfa.amsl.com>; Tue, 17 Jul 2012 23:32:36 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2FB11E8143 for <mif@ietf.org>; Tue, 17 Jul 2012 23:32:36 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so2152295pbc.31 for <mif@ietf.org>; Tue, 17 Jul 2012 23:33:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q1Fr8Gh7oQ8/9Nt4+WvUw7crKIrLuqCd/rDMDcqYU7E=; b=tQXT3Zkrer+nW4v58tNspVjMOrx0lfTnou9SrsiNIKvrE1Srcc4kAzXWmepqZt1Tsj xvnudBW09spjsuNS3htzYLdvQpWXVI+KhGNWy0Pa6mS+Cmn2CJRmIMcPTBRM3d31Pt0D SUb04IByHb+8ghe1Nlu+hcbmk6VyqG8T7qAXStL0f4Z6njPjXIbGEWWgPjekITGG11eS gopWURhcuch9xvNO247vnTydi69lpovRzQCKoG3z+XCPjYQST2xvbB7L9ORGG1I8u/FH ean58Cjbwp2lxwkZWkTDjv5UtXoCtDDv/6t/Yn9eCZXhmNRlSAw1IZMfPPbADSv+DE4B 72xw==
MIME-Version: 1.0
Received: by 10.68.240.73 with SMTP id vy9mr4674855pbc.102.1342593205450; Tue, 17 Jul 2012 23:33:25 -0700 (PDT)
Received: by 10.142.237.3 with HTTP; Tue, 17 Jul 2012 23:33:25 -0700 (PDT)
In-Reply-To: <50056471.7070708@gmail.com>
References: <50056471.7070708@gmail.com>
Date: Wed, 18 Jul 2012 14:33:25 +0800
Message-ID: <CANF0JMBg4Ka06-tifNpkkNdPDWP5Rh0wQACKTs6B+JYvHVg_fQ@mail.gmail.com>
From: Hui Deng <denghui02@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b339f4d16b60904c514d7bb"
Cc: mif@ietf.org
Subject: Re: [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: Wed, 18 Jul 2012 06:32:36 -0000

Hi Brian

Thanks for your review this draft, inline please,

2012/7/17 Brian E Carpenter <brian.e.carpenter@gmail.com>

> 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.
>
There is small percentage of applications know about this
experimentation which lead
to some poor user experience.


>
> 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.
>
Application use MIF api to handel this is useful information for the
application.
and section 4 and 5 clarify detail how to help this. today many
OS/connection manager's
concrete API already provide such MIF API, if use those API, it really help
applications.

SCTP/MPTCP/shim6 are more adding additional intelligent to Mobile/OS, the
document
discussed here could work together with MIF/CM API by not tweaking the OS
stack


> 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.
>
this document doesn't talk about load balancer, because re-connect means a
create a new session
which load balance will treat this is a normal new session without need to
keep the state.

Thanks  again for the discussion

Best regards,

-Hui

> I think section 3 is just the tip of a very complicated iceberg.
>
> Regards
>    Brian
>
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>