Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt

"James Kempf" <kempf@docomolabs-usa.com> Wed, 10 July 2002 22:19 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 SAA21994 for <seamoby-archive@odin.ietf.org>; Wed, 10 Jul 2002 18:19:41 -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 SAA13483; Wed, 10 Jul 2002 18:16:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13382 for <seamoby@optimus.ietf.org>; Wed, 10 Jul 2002 18:16:47 -0400 (EDT)
Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21926; Wed, 10 Jul 2002 18:15:51 -0400 (EDT)
Message-ID: <018a01c2285f$392d00d0$4f6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>, Rajeev Koodli <rajeev@iprg.nokia.com>, Hemant.Chaskar@nokia.com
Cc: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org
References: <35DBB8B7AC89D4118E98009027B1009B08AD5554@IL27EXM10.cig.mot.com>
Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
Date: Wed, 10 Jul 2002 15:14:55 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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

I guess I didn't make my point clear.

The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is
unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed.

I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be
some changes in the QoS specific context definition).

Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes
required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others.

            jak

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "'James Kempf'" <kempf@docomolabs-usa.com>; "Rajeev Koodli" <rajeev@iprg.nokia.com>; <Hemant.Chaskar@nokia.com>
Cc: <gkenward@nortelnetworks.com>; <seamoby@ietf.org>; <nsis@ietf.org>
Sent: Wednesday, July 10, 2002 11:58 AM
Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt


> James,
>
> As much as I like to see a clean interaction between CT and NSIS,
> I don't see any reason why CT needs to play the role of NSIS optimization,
> not to forget the NSIS didn't even exist back then.
>
> CT is simply a tool you need in your seamless mobility toolbox, it
> eventually
> involved into a container carrying any context you like (even non-IP
> context, as
> long as it is feasible). The profile types, that Rajeev mentioned is aligned
> with
> this line of thinking.
>
> I seriously advise against going back and change CT
> requirements for the sake of optimizing NSIS, which at this point we don't
> know
> what it is. A couple of months from now, we have to revise CT because of a
> security
> related protocol, later for something else.....
>
>
> The later we wait for CT standardization, the more home brewed versions are
> going to pop up, just like Behcet mentioned.
>
> My 1.5 cents (lower dollars)
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Monday, July 08, 2002 4:37 PM
> To: Rajeev Koodli; Hemant.Chaskar@nokia.com
> Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00.txt
>
>
> > CT is an optimization to avoid signaling and the associated overheads, and
> maintain
> > desirable transport (RTP/TCP)performance. A historical note: CT was not
> designed
> > to be an optimization for NSIS.
> >
>
> Do you mean that the requirements weren't so designed? Because, to my
> knowledge, the WG has not yet settled on a design. We are
> currently awaiting IESG feedback on our requirements. The problem statement
> was just approved by the IESG.
>
>             jak
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>


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