[Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)
Marcus Brunner <brunner@ccrle.nec.de> Mon, 08 July 2002 09:06 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 FAA08520 for <seamoby-archive@odin.ietf.org>; Mon, 8 Jul 2002 05:06:59 -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 FAA03657; Mon, 8 Jul 2002 05:03:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03602 for <seamoby@optimus.ietf.org>; Mon, 8 Jul 2002 05:03:07 -0400 (EDT)
Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08447; Mon, 8 Jul 2002 05:02:13 -0400 (EDT)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g688RwI96995; Mon, 8 Jul 2002 10:27:58 +0200 (CEST) (envelope-from brunner@ccrle.nec.de)
Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA19353; Mon, 8 Jul 2002 10:28:16 +0200
Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AFE0651C48; Mon, 8 Jul 2002 10:27:56 +0200 (CEST)
Date: Mon, 08 Jul 2002 10:28:15 +0200
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: Gary Kenward <gkenward@nortelnetworks.com>, "'Hancock, Robert'" <robert.hancock@roke.co.uk>, john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se
Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" <seamoby@ietf.org>
Message-ID: <1534506.1026124095@[192.168.102.207]>
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com>
References: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com >
X-Mailer: Mulberry/2.2.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)
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
> In my view, if CT is in place, then NSIS should not be invoked as a > result of a handover. A pretty simple relationship. The only exception > that I can imagine is if there is some impact on a service that is not > provided at an ANR (i.e. an AR or an internal router), then NSIS may be > required to maintain that service. However, I could not name this service > at this point. I don't see how CT can work without NSIS in the general case. If all your AR are connected to the swame next hop router, it may work. Generally, you might need to signal to the far end after handover. Marcus > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: July 5, 2002 10:59 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; > john.loughney@nokia.com; cedric@iprg.nokia.com; > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > hi gary, > > my comments are purely on draft-westphal-nsis-qos-mobileip and associated > email discussions (since that's been the only input I have seen recently > which explicitly discusses the relationship between CT and NSIS, and > which I had worries about). in particular, any comments I make about > MN-AR signalling are really to emphasise the difference between the cases > of a) not having CT signalling that carries QoS information MN-AR (if > there is or isn't other CT signalling I don't really care), and b) > having CT signalling that does carry QoS information MN-AR, which seems > to be the assumption of the mentioned draft. > our recent framework activities assumed (a). if you're saying that the > seamoby w.g. requirements also impose (a), that's fine by me. i also > don't want to re-open old discussions (certainly not on the nsis list, > anyway). > i suspect we're basically in agreement about NSIS/CT relationships: after > a handover, if CT happened, it should be possible to have less NSIS > signalling on the on-path segment which goes over the air. > cheers, > > robert h. > > PS referring to a previous email, i think the view that NSIS is "likely > to be of limited use in mobility situations" is rather pessimistic. i > would rather say that if you want the resources signalled for by NSIS to > be available seamlessly over handovers, you'll need something else as > well, which could be CT. the basic point seems to be that NSIS shouldn't > try to solve the cross-path context/state transfer problem - any more > than CT should try to solve the along-path context/state establishment > problem. [gwk] I agree. I was not trying to be as much pessimistic, as I > was pushing back against this concept that NSIS + LMM => Seamless > Mobility. To be more precise, if it takes longer then a few 10s of ms to > set up the new, conditioned path, then the handover will likely not be > seamless in 3G. Signalling, particularly over the air (again, 3G), takes > relatively significant amount of time to complete. 10s of ms is a rough > approximation, but if you are running voice frames, more then, say 20ms > of additional handover delay will start impinging on the service > requirements for the voice - i.e. either frames have to be dropped or > delayed beyond the performance constraint. It is difficult to pin down > these numbers, particularly in an IETF email list, but any delay budget > analysis that I have seen usually yields numbers in the stated range > (keep in mind that delay/drop allowances have to be budgeted for other > components of the access network and for the link layer handover). > > NSIS + LMM (or some variant of MIP) might be one approach to mobility. > Fine, but given what I understand about what NSIS is, and is not, it can > never be any where near as seamless as a solution that incorporates CT. > Is CT simply an "optimization" - well, that depends on how much service > disruption the user can tolerate. Usually, there is a threshold where > the service is simply considered unusable. > Cheers, > Gary > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby
- [Seamoby] RE: what is edge signalling? (was: RE: … Gary Kenward
- [Seamoby] RE: what is edge signalling? (was: RE: … Hancock, Robert
- [Seamoby] RE: what is edge signalling? (was: RE: … Gary Kenward
- [Seamoby] RE: what is edge signalling? (was: RE: … Marcus Brunner
- Re: [Seamoby] RE: what is edge signalling? (was: … Charlie Perkins
- [Seamoby] RE: what is edge signalling? (was: RE: … Gary Kenward