Re: [Seamoby] Minutes for Meeting at IETF 53

"Charles E. Perkins" <charliep@iprg.nokia.com> Thu, 18 April 2002 16:08 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12730 for <seamoby-archive@odin.ietf.org>; Thu, 18 Apr 2002 12:08:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08542; Thu, 18 Apr 2002 11:56:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08512 for <seamoby@optimus.ietf.org>; Thu, 18 Apr 2002 11:56:10 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11907 for <seamoby@ietf.org>; Thu, 18 Apr 2002 11:56:04 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA22114; Thu, 18 Apr 2002 08:55:37 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3IFtbH18759; Thu, 18 Apr 2002 08:55:37 -0700
X-mProtect: <200204181555> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCtwfZd; Thu, 18 Apr 2002 08:55:35 PDT
Message-ID: <3CBEEC77.3EDB171@iprg.nokia.com>
Date: Thu, 18 Apr 2002 08:55:35 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> <3CBEDF29.2050707@alcatel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hello Behcet,

Behcet Sarikaya wrote:
> 
> Karim et al.,
>   It seems to me that what Karim is arguing is MIPv4/v6 fast handover
> drafts do provide a solution to CARD.

That's not what I read, but I'll wait to see what Karim has to say.

>   And he is saying that these are MN centric solutions and bode well
> with Steve's arguments and the end-to-end arguments in system design
> first presented by Saltzer, Reed and Clark in as early as 1984.

I heard Steve's presentation.  I asked a question at the microphone
about whether he believed it precluded network-controlled operation.
He said it did not, but he wanted to restore mobile nodes to be
full citizens (paraphrasing, and it's been a few weeks now).
Subsequent discussion seems to be going to extremes, to the point
of ignoring obviously reasonable network-constrolled designs for
which [seamoby] ought to be responsive.

The paper you cite does not preclude such operation.  We can
view the mobile node as a client which is making use of available
service.  If the network provides the service, it is free to
establish parameters by which it provides the service, and if
it is beneficial to have a mobile node move to another point of
attachment, I see nothing wrong with notifying the node about
that, along with a good candidate for an access router.  I don't
see any reason why the network should be restricted from using
a CAR discovery protoocol to identify such a candidate.

>   Maybe the question is what business Seamoby has here?

My answer would be that [seamoby] ought to be making protocols
by which we can expedite smooth handovers.  That's a good piece
of work, and one for which we can exhibit existence proofs to
show that it is possible.  I think that so far that there has
been trouble to get agreement on "general" goals, but that there
are particular instances where the intended results should be
obvious.  I believe these particular instances include
network-controlled and mobile-controlled scenarios.

===================================================================

Somewhere else, it was stated that only the mobile node can
possibly know all of the CARs.  I would amend this to instead
say that the mobile node can always know about CARs that are
not visible to the network.  But, as it turns out, the network
can always know CARs that are not visible to the mobile node
also.  So, we have to allow the mobile node to make the choice,
but we should not prevent the mobile node from following
network-directives.  Thus, we should develop a model by which
CAR discovery is allowed to provide input to a network-controlled
handover scheme, which is nonetheless subject to possible rejection
by the mobile node.

Regards,
Charlie P.

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby