From mobopts-bounces@irtf.org Tue Jun 06 19:32:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnl2H-0004iC-8L; Tue, 06 Jun 2006 19:32:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnl2G-0004i4-0m; Tue, 06 Jun 2006 19:32:32 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnl2C-0001yF-Hd; Tue, 06 Jun 2006 19:32:31 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k56NWP3L029253; Wed, 7 Jun 2006 02:32:27 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 02:32:26 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 02:32:25 +0300 Message-ID: <44861086.3090300@iprg.nokia.com> Date: Tue, 06 Jun 2006 16:32:22 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org, mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2006 23:32:25.0994 (UTC) FILETIME=[77E6B6A0:01C689C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Mobopts] MIP and Upper Layer Protocol interaction X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello folks, we have problem dealing with change of HoA with a CN. If a MN wishes to change its HoA with a CN (e.g., use a different pseudo-hoa for privacy purposes), it has no _reliable_ way of knowing whether it has existing sessions with that CN. Any thoughts on how to handle this MIP - ULP interaction? -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 06 19:43:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlDA-0002xg-QL; Tue, 06 Jun 2006 19:43:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlD9-0002xW-En for mobopts@irtf.org; Tue, 06 Jun 2006 19:43:47 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnlD8-0003Ve-5h for mobopts@irtf.org; Tue, 06 Jun 2006 19:43:47 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id EA9ED8000B4; Wed, 7 Jun 2006 02:43:44 +0300 (EEST) Date: Wed, 7 Jun 2006 02:43:44 +0300 (EEST) From: Wassim Haddad To: Rajeev Koodli Subject: Re: [Mobopts] MIP and Upper Layer Protocol interaction In-Reply-To: <44861086.3090300@iprg.nokia.com> Message-ID: References: <44861086.3090300@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, On Tue, 6 Jun 2006, Rajeev Koodli wrote: > we have problem dealing with change of HoA with a CN. > > If a MN wishes to change its HoA with a CN (e.g., use a different > pseudo-hoa for privacy purposes), it has no _reliable_ way of > knowing whether it has existing sessions with that CN. => Can you please elaborate more on this? Is there any particular draft you're referring to? What type of pseudo-HoA you're considering? Regards, Wassim H. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 06 20:12:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnleq-0000UJ-MM; Tue, 06 Jun 2006 20:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnlep-0000U1-Ub; Tue, 06 Jun 2006 20:12:23 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnleo-0006TO-G3; Tue, 06 Jun 2006 20:12:23 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k570CKgF028384; Wed, 7 Jun 2006 03:12:21 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 03:12:20 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 03:12:20 +0300 Message-ID: <448619E2.9000905@iprg.nokia.com> Date: Tue, 06 Jun 2006 17:12:18 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wassim Haddad Subject: Re: [Mip6] Re: [Mobopts] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 00:12:20.0383 (UTC) FILETIME=[0B117AF0:01C689C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Wassim, Wassim Haddad wrote: >>we have problem dealing with change of HoA with a CN. >> >>If a MN wishes to change its HoA with a CN (e.g., use a different >>pseudo-hoa for privacy purposes), it has no _reliable_ way of >>knowing whether it has existing sessions with that CN. >> >> > >=> Can you please elaborate more on this? Is there any particular >draft you're referring to? What type of pseudo-HoA you're considering? > > > No particular draft as such. The problem is if the MN wishes to change its HoA for whatever reasons (3041 style privacy included), it has no reliable means of determining whether there is an existing connection/session or not. -Rajeev >Regards, > >Wassim H. > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 06 20:27:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnlth-0008QK-Lb; Tue, 06 Jun 2006 20:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnltL-0008Q8-P7 for mobopts@irtf.org; Tue, 06 Jun 2006 20:27:23 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnltK-0008W9-BS for mobopts@irtf.org; Tue, 06 Jun 2006 20:27:23 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k570RK06015950 for ; Wed, 7 Jun 2006 03:27:21 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 03:26:21 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 03:26:21 +0300 Message-ID: <44861D2C.2010900@iprg.nokia.com> Date: Tue, 06 Jun 2006 17:26:20 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 00:26:21.0847 (UTC) FILETIME=[009EB270:01C689C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Mobopts] Performance and Policy X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Folks, with IP mobility plumbing behind us (some might disagree), it's inevitable that we look at performance of Upper Layer Protocols such as TCP and RTP under mobility. o What's the performance of TCP under handovers (both intra and inter technology)? o What _should_ be its performance? o What's good for the "wireless link as a whole"? o How to regulate fair sharing of the link during mobility? o Others? Any thoughts? Another topic that comes to mind is policy. Inter-technology mobility is subject to policy controls when crossing provider boundaries. Yet, I am not sure we are paying enough attention to policy when designing for performance.. Perhaps I am wrong here, but I would like to hear counter-arguments. Regards, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 06 20:35:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnm1J-0004At-65; Tue, 06 Jun 2006 20:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnm1H-0004Al-NZ; Tue, 06 Jun 2006 20:35:35 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnm1F-0003U0-9W; Tue, 06 Jun 2006 20:35:35 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k56Nw8A21399; Tue, 6 Jun 2006 16:58:08 -0700 X-mProtect: <200606062358> Nokia Silicon Valley Messaging Protection Received: from danira-pool052146.americas.nokia.com (10.241.52.146, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdDCMyKl; Tue, 06 Jun 2006 16:58:06 PDT Message-ID: <44861F45.3010307@iprg.nokia.com> Date: Tue, 06 Jun 2006 17:35:17 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> In-Reply-To: <44861086.3090300@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello Rajeev, It could be that there isn't really a problem. Suppose that the mobile node keeps track of whether or not the correspondent node has a binding. Then, it can notify the correspondent if it changes home address, in addition to sending notifications about each new care-of address. If the correspondent node has no binding, then we can imagine that there hasn't been any traffic recently and that there are no TCP sessions. In that case, if the correspondent node wants to send data to the mobile node, it would have to re-resolve the mobile's host name. This could possibly require that the old home address first would fail. Presumably, this isn't exactly a mobility problem. I guess the motivation is to allow a device to operate with a new home agent in a new network but still maintain its existing "identity" from the point of view of some correspondent nodes. If I missed out on previous discussion about this point, please excuse my lack of context! Otherwise, can you say what use scenarios you had in mind? Regards, Charlie P. Rajeev Koodli wrote: > > Hello folks, > > we have problem dealing with change of HoA with a CN. > > If a MN wishes to change its HoA with a CN (e.g., use a different > pseudo-hoa for > privacy purposes), it has no _reliable_ way of knowing whether it has > existing sessions with that CN. > > Any thoughts on how to handle this MIP - ULP interaction? > > -Rajeev > > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 06 20:36:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnm2b-0004Jc-3K; Tue, 06 Jun 2006 20:36:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnm2a-0004JX-Cj for mobopts@irtf.org; Tue, 06 Jun 2006 20:36:56 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnm2X-0003k7-4P for mobopts@irtf.org; Tue, 06 Jun 2006 20:36:56 -0400 Received: from [192.4.8.161] (adutta-laptop.research.telcordia.com [192.4.8.161]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id k570aTfG027146; Tue, 6 Jun 2006 20:36:29 -0400 (EDT) Message-ID: <44861F8B.3080409@research.telcordia.com> Date: Tue, 06 Jun 2006 20:36:27 -0400 From: Ashutosh Dutta User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] Performance and Policy References: <44861D2C.2010900@iprg.nokia.com> In-Reply-To: <44861D2C.2010900@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Rajeev, sounds interesting. Going along with the same philosophy we can probably study some of the optimization research problems associated with some upper layer mobility protocols such as HIP and SIP as well. Thanks Ashutosh Rajeev Koodli wrote: > > Folks, > > with IP mobility plumbing behind us (some might disagree), it's > inevitable that we look at > performance of Upper Layer Protocols such as TCP and RTP under mobility. > > o What's the performance of TCP under handovers (both intra and inter > technology)? > o What _should_ be its performance? > o What's good for the "wireless link as a whole"? > o How to regulate fair sharing of the link during mobility? > o Others? > > Any thoughts? > > Another topic that comes to mind is policy. Inter-technology mobility > is subject > to policy controls when crossing provider boundaries. Yet, I am not > sure we are paying enough attention to policy when designing for > performance.. Perhaps > I am wrong here, but I would like to hear counter-arguments. > > Regards, > > -Rajeev > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 06 21:18:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnmgy-00083i-57; Tue, 06 Jun 2006 21:18:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnmgx-00083a-02; Tue, 06 Jun 2006 21:18:39 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnmgv-00070i-GS; Tue, 06 Jun 2006 21:18:38 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k571IZMV005269; Wed, 7 Jun 2006 04:18:36 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 04:18:35 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 04:18:35 +0300 Message-ID: <44862969.6050809@iprg.nokia.com> Date: Tue, 06 Jun 2006 18:18:33 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [Mobopts] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44861F45.3010307@iprg.nokia.com> In-Reply-To: <44861F45.3010307@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 01:18:35.0937 (UTC) FILETIME=[4CAEE110:01C689D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Charlie, Charles E. Perkins wrote: > > Hello Rajeev, > > It could be that there isn't really a problem. > That would be good. :-) > Suppose that the mobile node keeps track of whether or not > the correspondent node has a binding. Then, it can notify > the correspondent if it changes home address, in addition > to sending notifications about each new care-of address. > > If the correspondent node has no binding, then we can > imagine that there hasn't been any traffic recently and that > there are no TCP sessions. > The CN (and the MN) can have a binding and not have a TCP connection. So, the emphasis here is on "reliably" in "being able to detect an existing connection". The BCE lifetime is not correlated to the lifetime of a TCP connection. (You _could_ have a CN teardown a binding and have it later send a BRR for a new connection. But this won't work easily with multiple connections). > In that case, if the correspondent node wants to send > data to the mobile node, it would have to re-resolve the > mobile's host name. This could possibly require that > the old home address first would fail. Presumably, this > isn't exactly a mobility problem. I guess the motivation > is to allow a device to operate with a new home agent > in a new network but still maintain its existing "identity" > from the point of view of some correspondent nodes. > I tend to agree that this may not be strictly a mobility problem. Typically, you need to resolve a user identifier to device identifier before starting a connection, and you can construct the mapping in such a way as to support dynamic HoAs. > If I missed out on previous discussion about this point, > please excuse my lack of context! Otherwise, can you > say what use scenarios you had in mind? > Well, a MN may use RFC 3041 style HoA or some other form to thwart compromises in location privacy and profiling. Regards, -Rajeev > Regards, > Charlie P. > > > > > Rajeev Koodli wrote: > >> >> Hello folks, >> >> we have problem dealing with change of HoA with a CN. >> >> If a MN wishes to change its HoA with a CN (e.g., use a different >> pseudo-hoa for >> privacy purposes), it has no _reliable_ way of knowing whether it has >> existing sessions with that CN. >> >> Any thoughts on how to handle this MIP - ULP interaction? >> >> -Rajeev >> >> >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 03:10:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnsBc-0005BL-3J; Wed, 07 Jun 2006 03:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnsBa-0005BG-LM for mobopts@irtf.org; Wed, 07 Jun 2006 03:10:38 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnsBX-0006Ej-5Q for mobopts@irtf.org; Wed, 07 Jun 2006 03:10:38 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 09:10:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobopts] Performance and Policy Date: Wed, 7 Jun 2006 09:10:31 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03F1DCEC@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] Performance and Policy Thread-Index: AcaJyTnzqxqnqqNzSWO3avn8ukGorwAN3HGg From: To: , X-OriginalArrivalTime: 07 Jun 2006 07:10:31.0476 (UTC) FILETIME=[76866F40:01C68A01] X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Rajeev, I find this an interesting topic.. including the policy area. During the past few IRTF meetings there has actually been a couple presentations and drafts scratching the surface of policies when crossing the provider boundary. Cheers, Jouni > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]=20 > Sent: 7. kes=E4kuuta 2006 3:26 > To: mobopts@irtf.org > Subject: [Mobopts] Performance and Policy >=20 >=20 > Folks, >=20 > with IP mobility plumbing behind us (some might disagree), it's=20 > inevitable that we look at > performance of Upper Layer Protocols such as TCP and RTP=20 > under mobility. >=20 > o What's the performance of TCP under handovers (both intra and inter > technology)? > o What _should_ be its performance? > o What's good for the "wireless link as a whole"? > o How to regulate fair sharing of the link during mobility? > o Others? >=20 > Any thoughts? >=20 > Another topic that comes to mind is policy. Inter-technology=20 > mobility is=20 > subject > to policy controls when crossing provider boundaries. Yet, I am not > sure we are paying enough attention to policy when designing for=20 > performance.. Perhaps > I am wrong here, but I would like to hear counter-arguments. >=20 > Regards, >=20 > -Rajeev >=20 >=20 >=20 >=20 > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts >=20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 05:45:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnubB-0005BH-0k; Wed, 07 Jun 2006 05:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnub9-00058y-Fi for mobopts@irtf.org; Wed, 07 Jun 2006 05:45:11 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnub6-00085N-Ty for mobopts@irtf.org; Wed, 07 Jun 2006 05:45:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7C343200908D; Wed, 7 Jun 2006 11:45:27 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24615-03; Wed, 7 Jun 2006 11:45:27 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 26A6F200908C; Wed, 7 Jun 2006 11:45:27 +0200 (CEST) X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C68A17.0FB37B88" Date: Wed, 7 Jun 2006 11:45:00 +0200 Message-ID: <6D28EBC684A4D94096217AD2FE4008737529AB@venus.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt Thread-Index: AcaFvwCjLyPg7NxXR2yqaMhwRUPAXAEV7gyQ From: "Simon Schuetz" To: , , X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: Subject: [Mobopts] FW: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C68A17.0FB37B88 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We've published a new draft on minor extensions to TCP to operate more efficiently and fair to competing traffic in the presence of mobility and transient connectivity disruptions. The approach makes use of "connectivity-change indications" that can be provided by lower layers, but does not discuss details of such indications themselves (such investigations on-going in other documents). Feedback from the working groups is highly appreciated. Although sending this announcement to multiple working groups, we would like to have the actual discussion on the TCPM mailing list. For some reason it took some time, but the draft is now reachable at=20 http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-00.txt Best regards, Simon=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Posted At: Thursday, June 01, 2006 9:50 PM > Posted To: announce-IDs > Conversation: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt=20 > Subject: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt=20 >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : TCP Response to Lower-Layer=20 > Connectivity-Change Indications > Author(s) : S. Schuetz, et al. > Filename : draft-schuetz-tcpm-tcp-rlci-00.txt > Pages : 23 > Date : 2006-6-1 > =09 > When connectivity characteristics between two hosts change abruptly, > TCP can experience significant delays before resuming transmission in > an efficient manner or TCP can behave unfairly to competing traffic. > This document describes TCP extensions that improve transmission > behavior in response to advisory, lower-layer connectivity-change > indications. The proposed TCP extensions modify the local behavior > of TCP and introduce a new TCP option to signal local connectivity- > change indications to remote peers. Performance gains result from a > more efficient transmission behavior and are not due to an increased > aggressiveness. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rl > ci-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. =20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-schuetz-tcpm-tcp-rlci-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-schuetz-tcpm-tcp-rlci-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 ------_=_NextPart_001_01C68A17.0FB37B88 Content-Type: application/octet-stream; name="ATT1728791.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT1728791.TXT Content-Disposition: attachment; filename="ATT1728791.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi02LTExNDMyNDAuSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2NodWV0ei10Y3BtLXRjcC1y bGNpLTAwLnR4dA0K ------_=_NextPart_001_01C68A17.0FB37B88 Content-Type: application/octet-stream; name="draft-schuetz-tcpm-tcp-rlci-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-schuetz-tcpm-tcp-rlci-00.URL Content-Disposition: attachment; filename="draft-schuetz-tcpm-tcp-rlci-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zY2h1ZXR6LXRjcG0tdGNwLXJsY2ktMDAudHh0DQo= ------_=_NextPart_001_01C68A17.0FB37B88 Content-Type: text/plain; name="ATT1728792.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1728792.txt Content-Disposition: attachment; filename="ATT1728792.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C68A17.0FB37B88 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts ------_=_NextPart_001_01C68A17.0FB37B88-- From mobopts-bounces@irtf.org Wed Jun 07 05:47:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnudO-0007JA-Nc; Wed, 07 Jun 2006 05:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnudO-0007J5-7e for mobopts@irtf.org; Wed, 07 Jun 2006 05:47:30 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnudM-0008RT-PX for mobopts@irtf.org; Wed, 07 Jun 2006 05:47:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7A023200908C; Wed, 7 Jun 2006 11:47:47 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24615-10; Wed, 7 Jun 2006 11:47:47 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 66EDB2009082; Wed, 7 Jun 2006 11:47:47 +0200 (CEST) Received: from [10.1.1.115] ([10.1.1.115]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 11:47:28 +0200 Message-ID: <4486A0AF.7080406@netlab.nec.de> Date: Wed, 07 Jun 2006 11:47:27 +0200 From: Telemaco Melia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44861F45.3010307@iprg.nokia.com> <44862969.6050809@iprg.nokia.com> In-Reply-To: <44862969.6050809@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 09:47:28.0157 (UTC) FILETIME=[634DECD0:01C68A17] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Rajeev, >> > I tend to agree that this may not be strictly a mobility problem. > Typically, you need to resolve a user identifier to device identifier > before > starting a connection, and you can construct the mapping in such > a way as to support dynamic HoAs. > Indeed it could be a mobility problem, if for instance you design the mobility support in a way that a user can request at the same time as many HoAs as he wants. You could use different HoAs for different services, thus providing privacy and unlikability. (We have some work done available on request). Could we think about this issue in a more broader way? What is your opinion? regards, telemaco >> If I missed out on previous discussion about this point, >> please excuse my lack of context! Otherwise, can you >> say what use scenarios you had in mind? >> > Well, a MN may use RFC 3041 style HoA or some other form to > thwart compromises in location privacy and profiling. > > Regards, > > -Rajeev > >> Regards, >> Charlie P. >> >> >> >> >> Rajeev Koodli wrote: >> >>> >>> Hello folks, >>> >>> we have problem dealing with change of HoA with a CN. >>> >>> If a MN wishes to change its HoA with a CN (e.g., use a different >>> pseudo-hoa for >>> privacy purposes), it has no _reliable_ way of knowing whether it has >>> existing sessions with that CN. >>> >>> Any thoughts on how to handle this MIP - ULP interaction? >>> >>> -Rajeev >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Mobopts mailing list >>> Mobopts@irtf.org >>> https://www1.ietf.org/mailman/listinfo/mobopts >> >> >> >> > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts -- Telemaco Melia telemaco.melia@netlab.nec.de Research Staff Member Tel: +49 (0) 6221 4342- 142 Network Laboratories Fax: +49 (0) 6221 4342- 155 NEC Europe Ltd. Web: http://netlab.nec.de Kurfrsten-Anlage 36 D-69115 Heidelberg Germany _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 05:58:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnuo6-0003er-ES; Wed, 07 Jun 2006 05:58:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnuo5-0003em-V1 for mobopts@irtf.org; Wed, 07 Jun 2006 05:58:33 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnuo3-00022W-CJ for mobopts@irtf.org; Wed, 07 Jun 2006 05:58:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 22E9B2009082; Wed, 7 Jun 2006 11:58:50 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25030-05; Wed, 7 Jun 2006 11:58:50 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 02CA420001B8; Wed, 7 Jun 2006 11:58:50 +0200 (CEST) Received: from [10.1.1.115] ([10.1.1.115]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 11:58:30 +0200 Message-ID: <4486A345.4090502@netlab.nec.de> Date: Wed, 07 Jun 2006 11:58:29 +0200 From: Telemaco Melia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com, rajeev@iprg.nokia.com Subject: Re: [Mobopts] Performance and Policy References: <5D25AEFB114D034FBDC8B156FCA78E03F1DCEC@SEHAN021MB.tcad.telia.se> In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03F1DCEC@SEHAN021MB.tcad.telia.se> X-OriginalArrivalTime: 07 Jun 2006 09:58:30.0758 (UTC) FILETIME=[EE3ED060:01C68A18] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: Julien Abeille , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0589808412==" Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --===============0589808412== Content-Type: multipart/alternative; boundary="------------010002000502030108010706" This is a multi-part message in MIME format. --------------010002000502030108010706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Rajeev, Jouni, If folks are interested we can try to come up with a presentation (do=20 not think we can make it with a document). We are currently investigating how upper (applications, context=20 awareness software, operator/user policies) layers and lower layers=20 (pure network conditions) should communicate and where actually the=20 final decision is taken. There is still a lot of confusion and not yet a=20 clear/clean solution. Let us know. regards, telemaco jouni.korhonen@teliasonera.com wrote: > Rajeev, > > I find this an interesting topic.. including the policy area. > During the past few IRTF meetings there has actually been > a couple presentations and drafts scratching the surface > of policies when crossing the provider boundary. > > Cheers, > Jouni > > =20 >> -----Original Message----- >> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]=20 >> Sent: 7. kes=E4kuuta 2006 3:26 >> To: mobopts@irtf.org >> Subject: [Mobopts] Performance and Policy >> >> >> Folks, >> >> with IP mobility plumbing behind us (some might disagree), it's=20 >> inevitable that we look at >> performance of Upper Layer Protocols such as TCP and RTP=20 >> under mobility. >> >> o What's the performance of TCP under handovers (both intra and inter >> technology)? >> o What _should_ be its performance? >> o What's good for the "wireless link as a whole"? >> o How to regulate fair sharing of the link during mobility? >> o Others? >> >> Any thoughts? >> >> Another topic that comes to mind is policy. Inter-technology=20 >> mobility is=20 >> subject >> to policy controls when crossing provider boundaries. Yet, I am not >> sure we are paying enough attention to policy when designing for=20 >> performance.. Perhaps >> I am wrong here, but I would like to hear counter-arguments. >> >> Regards, >> >> -Rajeev >> >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts >> >> =20 > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > =20 --=20 Telemaco Melia telemaco.melia@netlab.nec.de Research Staff Member Tel: +49 (0) 6221 4342- 142 Network Laboratories Fax: +49 (0) 6221 4342- 155 NEC Europe Ltd. Web: http://netlab.nec.de Kurfrsten-Anlage 36 D-69115 Heidelberg Germany --------------010002000502030108010706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Rajeev, Jouni,

If folks are interested we can try to come up with a presentation (do not think we can make it with a document).
We are currently investigating how upper (applications, context awareness software, operator/user policies) layers and lower layers (pure network conditions) should communicate and where actually the final decision is taken. There is still a lot of confusion and not yet a clear/clean solution. Let us know.

regards,
telemaco

jouni.korhonen@teliasonera.com wrote: 
Rajeev,

I find this an interesting topic.. including the policy area.
During the past few IRTF meetings there has actually been
a couple presentations and drafts scratching the surface
of policies when crossing the provider boundary.

Cheers,
	Jouni

  
-----Original Message-----
From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] 
Sent: 7. kesäkuuta 2006 3:26
To: mobopts@irtf.org
Subject: [Mobopts] Performance and Policy


Folks,

with IP mobility plumbing behind us (some might disagree), it's 
inevitable that we look at
performance of Upper Layer Protocols such as TCP and RTP 
under mobility.

o What's the performance of TCP under handovers (both intra and inter
technology)?
o What _should_ be its performance?
o What's good for the "wireless link as a whole"?
o How to regulate fair sharing of the link during mobility?
o Others?

Any thoughts?

Another topic that comes to mind is policy. Inter-technology 
mobility is 
subject
to policy controls when crossing provider boundaries. Yet, I am not
sure we are paying enough attention to policy when designing for 
performance.. Perhaps
I am wrong here, but I would like to hear counter-arguments.

Regards,

-Rajeev




_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts

    

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts
  


-- 
Telemaco Melia          	telemaco.melia@netlab.nec.de
Research Staff Member		Tel: +49 (0) 6221 4342- 142
Network Laboratories    	Fax: +49 (0) 6221 4342- 155
NEC Europe Ltd.         	Web: http://netlab.nec.de
Kurfrsten-Anlage 36
D-69115 Heidelberg
Germany
--------------010002000502030108010706-- --===============0589808412== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0589808412==-- From mobopts-bounces@irtf.org Wed Jun 07 11:15:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnzl3-0006su-CB; Wed, 07 Jun 2006 11:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnzl2-0006sV-1J for mobopts@irtf.org; Wed, 07 Jun 2006 11:15:44 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnzl0-0006sm-Km for mobopts@irtf.org; Wed, 07 Jun 2006 11:15:44 -0400 Message-ID: <00e701c68a45$4bd25590$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Rajeev Koodli" , References: <44861D2C.2010900@iprg.nokia.com> Subject: Re: [Mobopts] Performance and Policy Date: Wed, 7 Jun 2006 08:16:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Rajeev, There is an extensive academic literature about TCP performance during handover. See for example Andre Gurtov's thesis. I think it might help to have someone do a literature survey, similar to the one Bernard did about link hints in his IAB draft, and write it up for a draft (unfortunately, I can't volunteer as I have too much else to do right now). Regarding your point about policy, I have always thought that this is likely to be a particular issue with inter-technology handover. Another issue is that most of the architectures that seem likely to be deployed have a variety of boxes between the two types of wireless links (PDG, UMA gateway, etc.). jak ----- Original Message ----- From: "Rajeev Koodli" To: Sent: Tuesday, June 06, 2006 5:26 PM Subject: [Mobopts] Performance and Policy > > Folks, > > with IP mobility plumbing behind us (some might disagree), it's inevitable > that we look at > performance of Upper Layer Protocols such as TCP and RTP under mobility. > > o What's the performance of TCP under handovers (both intra and inter > technology)? > o What _should_ be its performance? > o What's good for the "wireless link as a whole"? > o How to regulate fair sharing of the link during mobility? > o Others? > > Any thoughts? > > Another topic that comes to mind is policy. Inter-technology mobility is > subject > to policy controls when crossing provider boundaries. Yet, I am not > sure we are paying enough attention to policy when designing for > performance.. Perhaps > I am wrong here, but I would like to hear counter-arguments. > > Regards, > > -Rajeev > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 11:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnzob-0000KV-R8; Wed, 07 Jun 2006 11:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnzoa-0000KH-H4 for mobopts@irtf.org; Wed, 07 Jun 2006 11:19:24 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzoZ-0006zH-3L for mobopts@irtf.org; Wed, 07 Jun 2006 11:19:24 -0400 Message-ID: <00ec01c68a45$cfdde480$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Charles E. Perkins" , "Rajeev Koodli" References: <44861086.3090300@iprg.nokia.com> <44861F45.3010307@iprg.nokia.com> Subject: Re: [Mobopts] MIP and Upper Layer Protocol interaction Date: Wed, 7 Jun 2006 08:19:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Charlie, Let's see if I understand. Are you saying that if the mobile node wants to change home address, it should change existing sessions by treating the change as route optimization? That is, it would send a route optimization binding update (with appropriate security) with the new home address as a care of address? Presumably new sessions would be started with the new home address. jak ----- Original Message ----- From: "Charles E. Perkins" To: "Rajeev Koodli" Cc: ; Sent: Tuesday, June 06, 2006 5:35 PM Subject: Re: [Mobopts] MIP and Upper Layer Protocol interaction > > Hello Rajeev, > > It could be that there isn't really a problem. > > Suppose that the mobile node keeps track of whether or not > the correspondent node has a binding. Then, it can notify > the correspondent if it changes home address, in addition > to sending notifications about each new care-of address. > > If the correspondent node has no binding, then we can > imagine that there hasn't been any traffic recently and that > there are no TCP sessions. > > In that case, if the correspondent node wants to send > data to the mobile node, it would have to re-resolve the > mobile's host name. This could possibly require that > the old home address first would fail. Presumably, this > isn't exactly a mobility problem. I guess the motivation > is to allow a device to operate with a new home agent > in a new network but still maintain its existing "identity" > from the point of view of some correspondent nodes. > > If I missed out on previous discussion about this point, > please excuse my lack of context! Otherwise, can you > say what use scenarios you had in mind? > > Regards, > Charlie P. > > > > > Rajeev Koodli wrote: > >> >> Hello folks, >> >> we have problem dealing with change of HoA with a CN. >> >> If a MN wishes to change its HoA with a CN (e.g., use a different >> pseudo-hoa for >> privacy purposes), it has no _reliable_ way of knowing whether it has >> existing sessions with that CN. >> >> Any thoughts on how to handle this MIP - ULP interaction? >> >> -Rajeev >> >> >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 13:13:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1bQ-0001Ht-Nn; Wed, 07 Jun 2006 13:13:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1bP-0001Hl-FD; Wed, 07 Jun 2006 13:13:55 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1bN-0004NV-W7; Wed, 07 Jun 2006 13:13:55 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57HDldj027053; Wed, 7 Jun 2006 20:13:50 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 20:13:44 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 20:13:45 +0300 Message-ID: <44870922.3040408@iprg.nokia.com> Date: Wed, 07 Jun 2006 10:13:06 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> In-Reply-To: <44862A89.5030201@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 17:13:45.0354 (UTC) FILETIME=[BBC1EEA0:01C68A55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Vijay Devarapalli wrote: > Rajeev Koodli wrote: > >> If a MN wishes to change its HoA with a CN (e.g., use a different >> pseudo-hoa for >> privacy purposes), it has no _reliable_ way of knowing whether it has >> existing sessions with that CN. > > > I read this paragraph three times, but couldn't get > the context. > > if in the privacy context, I assume there is still > a *real* HoA. the pseudo HoA appears in the route > optimized traffic to the CN *instead* of the real > HoA. the CN knows the real HoA and the pseudo HoA. > the mapping from the real HoA to the pseudo HoA is > done using the binding update list at the MN and > the binding cache entry at the CN. > This is a way to do it. Nevertheless, keeping the privacy issue aside.. > if not for privacy, perhaps the mobile node shouldn't > change its HoA abruptly, but let existing sessions > continue with the existing HoA and use the new HoA > for new sessions. the mobile node would also have > to update the DNS entry if it wants its FQDN to > resolve to the new HoA. > The problem here is how does the MN know to "let the existing sessions continue with the existing HoA"? If there is no CN's address in BUL, surely the MN can choose a suitable HoA. For a CN with which it has a binding, it has no reliable way of knowing whether there are any ULP sessions. -Rajeev > hope this helps. > > Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 13:22:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1jT-0003wS-H7; Wed, 07 Jun 2006 13:22:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1jR-0003v7-U1 for mobopts@irtf.org; Wed, 07 Jun 2006 13:22:13 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1jQ-0005Ce-Du for mobopts@irtf.org; Wed, 07 Jun 2006 13:22:13 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57HM2cM012341; Wed, 7 Jun 2006 20:22:07 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 20:21:44 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 20:21:44 +0300 Message-ID: <44870B17.9010106@iprg.nokia.com> Date: Wed, 07 Jun 2006 10:21:27 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobopts] Performance and Policy References: <44861D2C.2010900@iprg.nokia.com> <00e701c68a45$4bd25590$026115ac@dcml.docomolabsusa.com> In-Reply-To: <00e701c68a45$4bd25590$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 17:21:44.0901 (UTC) FILETIME=[D996FF50:01C68A56] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org James Kempf wrote: > Rajeev, > > There is an extensive academic literature about TCP performance > during handover. See for example Andre Gurtov's thesis. I think it > might help to have someone do a literature survey, similar to the one > Bernard did about link hints in his IAB draft, and write it up for a > draft (unfortunately, I can't volunteer as I have too much else to do > right now). > Thanks for the pointer. I also think there is work on end-to-end basis (e.g., using TCP options), but I have not come across IP layer mechanisms. I would be glad to find out more. Yes, the idea is to first get hold of what exists and then see how ULP performance blends in with Fast IP routing. > Regarding your point about policy, I have always thought that this is > likely to be a particular issue with inter-technology handover. > Another issue is that most of the architectures that seem likely to be > deployed have a variety of boxes between the two types of wireless > links (PDG, UMA gateway, etc.). > Yes, there are complexities. Why don't we recognize them up front and say "here are the issues for the designers" ? :-) The challenge is in formalizing these issues I believe.. Take for instance pre-auth. I think it is worthwhile. I also think it would be tricky to do across provider boundaries; perhaps that's not the focus now. We did discuss it at MobOpts several times.. -Rajeev > jak > > ----- Original Message ----- From: "Rajeev Koodli" > > To: > Sent: Tuesday, June 06, 2006 5:26 PM > Subject: [Mobopts] Performance and Policy > > >> >> Folks, >> >> with IP mobility plumbing behind us (some might disagree), it's >> inevitable that we look at >> performance of Upper Layer Protocols such as TCP and RTP under mobility. >> >> o What's the performance of TCP under handovers (both intra and inter >> technology)? >> o What _should_ be its performance? >> o What's good for the "wireless link as a whole"? >> o How to regulate fair sharing of the link during mobility? >> o Others? >> >> Any thoughts? >> >> Another topic that comes to mind is policy. Inter-technology mobility >> is subject >> to policy controls when crossing provider boundaries. Yet, I am not >> sure we are paying enough attention to policy when designing for >> performance.. Perhaps >> I am wrong here, but I would like to hear counter-arguments. >> >> Regards, >> >> -Rajeev >> >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts >> > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 13:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1km-0004Bd-4S; Wed, 07 Jun 2006 13:23:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1kk-0004BY-7E for mobopts@irtf.org; Wed, 07 Jun 2006 13:23:34 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1ki-0005FS-Q8 for mobopts@irtf.org; Wed, 07 Jun 2006 13:23:34 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57HNSBl013336; Wed, 7 Jun 2006 20:23:31 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 20:23:31 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 20:23:31 +0300 Message-ID: <44870B8F.70602@iprg.nokia.com> Date: Wed, 07 Jun 2006 10:23:27 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Telemaco Melia Subject: Re: [Mobopts] Performance and Policy References: <5D25AEFB114D034FBDC8B156FCA78E03F1DCEC@SEHAN021MB.tcad.telia.se> <4486A345.4090502@netlab.nec.de> In-Reply-To: <4486A345.4090502@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 17:23:31.0260 (UTC) FILETIME=[18FC17C0:01C68A57] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Julien Abeille , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Telemaco Melia wrote: > Rajeev, Jouni, > > If folks are interested we can try to come up with a presentation (do > not think we can make it with a document). > We are currently investigating how upper (applications, context > awareness software, operator/user policies) layers and lower layers > (pure network conditions) should communicate and where actually the > final decision is taken. There is still a lot of confusion and not yet > a clear/clean solution. Let us know. > Sure. It would be more interesting to see what are the problems (of course solutions are implied) you are encountering. -Rajeev > regards, > telemaco > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 13:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1oD-0001YC-8N; Wed, 07 Jun 2006 13:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1oC-0001Y6-4X for mobopts@irtf.org; Wed, 07 Jun 2006 13:27:08 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1oA-0005RD-O0 for mobopts@irtf.org; Wed, 07 Jun 2006 13:27:08 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57HR5wr005387; Wed, 7 Jun 2006 20:27:05 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 20:26:48 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 20:26:48 +0300 Message-ID: <44870C53.7090205@iprg.nokia.com> Date: Wed, 07 Jun 2006 10:26:43 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [Mobopts] Performance and Policy References: <5D25AEFB114D034FBDC8B156FCA78E03F1DCEC@SEHAN021MB.tcad.telia.se> In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03F1DCEC@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 17:26:48.0823 (UTC) FILETIME=[8EBDD070:01C68A57] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org jouni.korhonen@teliasonera.com wrote: >Rajeev, > >I find this an interesting topic.. including the policy area. >During the past few IRTF meetings there has actually been >a couple presentations and drafts scratching the surface >of policies when crossing the provider boundary. > > > Ya, sure. I would like to dig deeper. I know there has been some discussion along the lines of network-initiated handovers. I am wondering if we could come up with a document outlining the provider boundary issues.. Any takers? -Rajeev >Cheers, > Jouni > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 13:31:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1sP-0002qy-Sn; Wed, 07 Jun 2006 13:31:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1sO-0002qn-AK; Wed, 07 Jun 2006 13:31:28 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1sM-0005sd-Rs; Wed, 07 Jun 2006 13:31:28 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57HVPQM006938; Wed, 7 Jun 2006 20:31:25 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 20:31:25 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 20:31:25 +0300 Message-ID: <44870D68.4020909@iprg.nokia.com> Date: Wed, 07 Jun 2006 10:31:20 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Schuetz Subject: Re: [Mobopts] FW: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt References: <6D28EBC684A4D94096217AD2FE4008737529AB@venus.office> In-Reply-To: <6D28EBC684A4D94096217AD2FE4008737529AB@venus.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 17:31:25.0276 (UTC) FILETIME=[338531C0:01C68A58] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tcpm@ietf.org, tsvwg@ietf.org, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Simon, thanks for the pointer. Simon Schuetz wrote: >Feedback from the working groups is highly appreciated. Although sending >this announcement to multiple working groups, we would like to have the >actual discussion on the TCPM mailing list. > > > As a practical matter, if you think this is also of interest to MobOpts, you are welcome to discuss it here. -Rajeev >For some reason it took some time, but the draft is now reachable at >http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-00.txt > >Best regards, >Simon > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 13:58:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2Ik-0002jM-Qi; Wed, 07 Jun 2006 13:58:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2Ij-0002jH-Ff for mobopts@irtf.org; Wed, 07 Jun 2006 13:58:41 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2Ii-0002Fv-0n for mobopts@irtf.org; Wed, 07 Jun 2006 13:58:41 -0400 Message-ID: <01fa01c68a5c$0ffbc3a0$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Rajeev Koodli" References: <44861D2C.2010900@iprg.nokia.com> <00e701c68a45$4bd25590$026115ac@dcml.docomolabsusa.com> <44870B17.9010106@iprg.nokia.com> Subject: Re: [Mobopts] Performance and Policy Date: Wed, 7 Jun 2006 10:59:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org > Yes, there are complexities. Why don't we recognize them up front and say > "here are > the issues for the designers" ? :-) The challenge is in formalizing these > issues I believe.. > Take for instance pre-auth. I think it is worthwhile. > I also think it would be tricky to do across provider boundaries; perhaps > that's not the > focus now. We did discuss it at MobOpts several times.. > Perhaps a problem statement? Also, defining how fast handover interacts with 802.11r preauth sounds worthwhile. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 16:02:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4EW-0007Ad-I3; Wed, 07 Jun 2006 16:02:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo42r-0002Sx-Q0 for mobopts@irtf.org; Wed, 07 Jun 2006 15:50:26 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo42q-0007dP-Cv for mobopts@irtf.org; Wed, 07 Jun 2006 15:50:25 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57JoHtX004262; Wed, 7 Jun 2006 22:50:20 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 22:50:11 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 22:50:10 +0300 Message-ID: <44872DE2.9070000@iprg.nokia.com> Date: Wed, 07 Jun 2006 12:49:54 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobopts] Performance and Policy References: <44861D2C.2010900@iprg.nokia.com> <00e701c68a45$4bd25590$026115ac@dcml.docomolabsusa.com> <44870B17.9010106@iprg.nokia.com> <01fa01c68a5c$0ffbc3a0$026115ac@dcml.docomolabsusa.com> In-Reply-To: <01fa01c68a5c$0ffbc3a0$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 19:50:10.0985 (UTC) FILETIME=[96079190:01C68A6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org James Kempf wrote: >> Yes, there are complexities. Why don't we recognize them up front and >> say "here are >> the issues for the designers" ? :-) The challenge is in formalizing >> these issues I believe.. >> Take for instance pre-auth. I think it is worthwhile. >> I also think it would be tricky to do across provider boundaries; >> perhaps that's not the >> focus now. We did discuss it at MobOpts several times.. >> > > Perhaps a problem statement? > Sure. That would be good. > Also, defining how fast handover interacts with 802.11r preauth sounds > worthwhile. > Yes. Perhaps we should have a good session on this at Montreal. -Rajeev > jak > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 19:03:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo73p-0001CS-Kl; Wed, 07 Jun 2006 19:03:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo73o-0001CN-Rp for mobopts@irtf.org; Wed, 07 Jun 2006 19:03:36 -0400 Received: from wx-out-0102.google.com ([66.249.82.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo73n-0002El-LL for mobopts@irtf.org; Wed, 07 Jun 2006 19:03:36 -0400 Received: by wx-out-0102.google.com with SMTP id h30so211884wxd for ; Wed, 07 Jun 2006 16:03:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Gi5SNTHSC6giNsUL2Pbh+mHjUPw+5g/J956nDEmurAvAvpSEbL1Xljz0GFnKtLvLY7qZBFw9ZEDncHtMdmYbqX5hNWS3j3+8dPurKGM0vQ5WDmpknE8WitG5pQ/9eNBXQtz7/b5/dYrUDlhLtGiskGhr8lNrbA+O4g4thb/iuN8= Received: by 10.70.74.14 with SMTP id w14mr1338351wxa; Wed, 07 Jun 2006 16:03:34 -0700 (PDT) Received: by 10.70.84.19 with HTTP; Wed, 7 Jun 2006 16:03:34 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 16:03:34 -0700 From: "Vijay Devarapallli" To: "Rajeev Koodli" Subject: Re: [Mobopts] Performance and Policy In-Reply-To: <44861D2C.2010900@iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44861D2C.2010900@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org On 6/6/06, Rajeev Koodli wrote: > Another topic that comes to mind is policy. Inter-technology mobility is > subject > to policy controls when crossing provider boundaries. Yet, I am not > sure we are paying enough attention to policy when designing for > performance. I am very interested in this topic. I have been working on this recently. let me know if you need someone to write up a problem statement. Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 07 20:45:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8eL-0004Gy-5c; Wed, 07 Jun 2006 20:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8eJ-0004Gq-7B; Wed, 07 Jun 2006 20:45:23 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo8eH-0006NW-Pz; Wed, 07 Jun 2006 20:45:23 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k580j9TS019677; Thu, 8 Jun 2006 03:45:09 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 03:44:42 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jun 2006 03:44:42 +0300 Message-ID: <448772F6.9060009@iprg.nokia.com> Date: Wed, 07 Jun 2006 17:44:38 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> In-Reply-To: <44872034.9010906@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2006 00:44:42.0515 (UTC) FILETIME=[BB150E30:01C68A94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Vijay, Vijay Devarapalli wrote: > we could easily say its implementation specific since its > internal to the mobile node. :) > that's okay. I am trying to see what we can use.. > there are many ways this can be achieved inside a mobile > node. > > 1. the mobile node keeps track of number of packets sent > using a particular binding update list entry. it can > record this information in the binding update list entry > itself. > > 2. the mobile node records the timestamp of the last packet > sent using a particular binding update list entry in the > binding update list entry itself. > > 3. the mobile node keeps track of all the sockets that > were opened with a particular home address. > This might work. (1 and 2 above don't really relate to whether a session/connection is alive or not). I am referring to such interaction. How do we formalize it (if not standardize it)? > 4. etc.... > > you would see this issue in a non-Mobile IPv6 host too > when you have multiple IPv6 addresses and the host wants > to stop using a particular IPv6 address and start using > another IPv6 address. > Yes, but you don't expect session persistence in that case. -Rajeev > let me know if I am completely off track. > > Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 08 02:22:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDuy-00048b-6q; Thu, 08 Jun 2006 02:22:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDux-00048O-17 for mobopts@irtf.org; Thu, 08 Jun 2006 02:22:55 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoDut-0003Ul-Mh for mobopts@irtf.org; Thu, 08 Jun 2006 02:22:54 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J0J00JZU31RUI@mailout2.samsung.com> for mobopts@irtf.org; Thu, 08 Jun 2006 15:22:39 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J0J00CMP31RBL@mmp1.samsung.com> for mobopts@irtf.org; Thu, 08 Jun 2006 15:22:39 +0900 (KST) Date: Thu, 08 Jun 2006 15:22:46 +0900 From: Soohong Daniel Park Subject: Re: [Mobopts] FW: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt To: Simon Schuetz , tcpm@ietf.org, tsvwg@ietf.org, mobopts@irtf.org Message-id: <019e01c68ac3$f5694310$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <6D28EBC684A4D94096217AD2FE4008737529AB@venus.office> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Simon, I am very much interested in this issue. Also I had a couple of times for relevant discussion within MobOpts in terms of MIP option for connectivity-change indication. Now, I am trying to revise it based on recent feedbacks from IETF. http://www.watersprings.org/pub/id/draft-daniel-mip-link-characteristic-02.txt Anyway, one concern occurs in my mind regarding TCP option for connectivity-change indication. In case host changes its point of attachment (typically called handover), TCP operations will happen after all IP/MIP operation are completed. It seems a bit serious than MIP option from the service disruption. By enabling simple interface between MIP and Trnasport laer (TCP), indication included in MIP option can be used for TCP module. In case we do not consider handover (for example: wireless interference, etc), TCP option seems a bit useful than MIP approach. I am not sure MIP option can be applied for the case above. Regards. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 08 02:43:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoEF4-0007oB-H0; Thu, 08 Jun 2006 02:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoEF2-0007ns-IK for mobopts@irtf.org; Thu, 08 Jun 2006 02:43:40 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoEF1-0005pd-29 for mobopts@irtf.org; Thu, 08 Jun 2006 02:43:40 -0400 Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J0J00IFI402DG@mailout3.samsung.com> for mobopts@irtf.org; Thu, 08 Jun 2006 15:43:14 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J0J00C9M402BL@mmp1.samsung.com> for mobopts@irtf.org; Thu, 08 Jun 2006 15:43:14 +0900 (KST) Date: Thu, 08 Jun 2006 15:43:21 +0900 From: Soohong Daniel Park Subject: Re: [Mobopts] Performance and Policy To: Rajeev Koodli , mobopts@irtf.org Message-id: <01c101c68ac6$d583a510$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <44861D2C.2010900@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Rajeev, > with IP mobility plumbing behind us (some might disagree), it's > inevitable that we look at performance of Upper Layer Protocols > such as TCP and RTP under mobility. Perhaps, you said RTP as one of UDP implication. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. RTP is augmented by a RTCP to monitor data delivery and network statistics. So, RTCP can be a facility in order to optimizing its service disruption unver handover. Although, RTCP resolves many of the problems in UDP network, such as lost packets, jitter, and out of sequence packets, it that reports conditions of session periodically may have difficulty to guarantee quality-of-service immediately. especially, Mobile environments with many participants and low bandwidth may cause the long interval of RTCP transmission (for example, 5-6 seconds or more). RTP and/or RTCP header options can be available approachs though...There is more immediate RTCP feedback defined in "Extended RTP profile for RTCP-based Feedback", RTCP feedback message is heavy to be used for mobility environment. Regards. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 08 20:33:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoUvq-0003o2-Jq; Thu, 08 Jun 2006 20:32:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoUvo-0003nl-QI for mobopts@irtf.org; Thu, 08 Jun 2006 20:32:56 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoUvl-00036D-CD for mobopts@irtf.org; Thu, 08 Jun 2006 20:32:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k590WmrG020447; Fri, 9 Jun 2006 03:32:51 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 03:32:51 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jun 2006 03:32:50 +0300 Message-ID: <4488C1AE.2040505@iprg.nokia.com> Date: Thu, 08 Jun 2006 17:32:46 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapallli Subject: Re: [Mobopts] Performance and Policy References: <44861D2C.2010900@iprg.nokia.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 00:32:50.0390 (UTC) FILETIME=[3D092760:01C68B5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Vijay Devarapallli wrote: > On 6/6/06, Rajeev Koodli wrote: > >> Another topic that comes to mind is policy. Inter-technology mobility is >> subject >> to policy controls when crossing provider boundaries. Yet, I am not >> sure we are paying enough attention to policy when designing for >> performance. > > > I am very interested in this topic. I have been working on this recently. > let me know if you need someone to write up a problem statement. > I like the idea of putting together a document. We should dedicate some time in Montreal for this topic. In the meanwhile, what are the issues? Let's discuss on the ML. -Rajeev > Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jun 09 05:53:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FodgV-0002Oz-Gf; Fri, 09 Jun 2006 05:53:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FodgU-0002Oq-O7; Fri, 09 Jun 2006 05:53:42 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FodgS-0004kj-AH; Fri, 09 Jun 2006 05:53:42 -0400 Received: from pc236.centersystems.at (guest-rocq-135223.inria.fr [128.93.135.223]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k599rUvI015370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jun 2006 11:53:30 +0200 Date: Fri, 9 Jun 2006 11:53:31 +0200 From: Thierry Ernst To: mip6@ietf.org, ml-ietf-mobopts Message-Id: <20060609115331.1d81e007.thierry.ernst@inria.fr> In-Reply-To: <44872034.9010906@azairenet.com> References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-j-chkmail-Score: MSGID : 4489451A.000 on nez-perce : j-chkmail score : XX : 5/20 0 X-Miltered: at nez-perce with ID 4489451A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nico-w Subject: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Several comments: - doesn't this thread initiated Rajeev belong to Shim6 ? - if it doesn't, it would be more appropriate to discuss it on the Monami6 ML, although we excluded to produce an output on the matter where the MN (i.e. either a host or a router) has multiple HoAs. But, still, Monami6 see is the right ML to discuss it when node multihoming comes to mobility. Thierry. On Wed, 07 Jun 2006 11:51:32 -0700 Vijay Devarapalli wrote: > Rajeev Koodli wrote: > > >> if not for privacy, perhaps the mobile node shouldn't > >> change its HoA abruptly, but let existing sessions > >> continue with the existing HoA and use the new HoA > >> for new sessions. the mobile node would also have > >> to update the DNS entry if it wants its FQDN to > >> resolve to the new HoA. > >> > > The problem here is how does the MN know to "let the > > existing sessions continue with the existing HoA"? If there is no CN's > > address in BUL, surely the MN can choose a suitable HoA. For > > a CN with which it has a binding, it has no reliable way of knowing > > whether there are any ULP sessions. > > we could easily say its implementation specific since its > internal to the mobile node. :) > > there are many ways this can be achieved inside a mobile > node. > > 1. the mobile node keeps track of number of packets sent > using a particular binding update list entry. it can > record this information in the binding update list entry > itself. > > 2. the mobile node records the timestamp of the last packet > sent using a particular binding update list entry in the > binding update list entry itself. > > 3. the mobile node keeps track of all the sockets that > were opened with a particular home address. > > 4. etc.... > > you would see this issue in a non-Mobile IPv6 host too > when you have multiple IPv6 addresses and the host wants > to stop using a particular IPv6 address and start using > another IPv6 address. > > let me know if I am completely off track. > > Vijay > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > -- Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39 63 59 30 (office) _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jun 09 12:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fok8x-0004Hf-MV; Fri, 09 Jun 2006 12:47:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fok8w-0004Cv-8I for mobopts@irtf.org; Fri, 09 Jun 2006 12:47:30 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fok8u-00066C-Qz for mobopts@irtf.org; Fri, 09 Jun 2006 12:47:30 -0400 Received: from [10.1.210.4] ([10.1.210.4]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 09:47:24 -0700 Message-ID: <4489A617.3070809@azairenet.com> Date: Fri, 09 Jun 2006 09:47:19 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> <20060609115331.1d81e007.thierry.ernst@inria.fr> In-Reply-To: <20060609115331.1d81e007.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 16:47:24.0621 (UTC) FILETIME=[6264B7D0:01C68BE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip6@ietf.org, nico-w , ml-ietf-mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Thierry, I think this belongs in mobopts (or MIP6 if the problem is sufficiently well understood). its more about stopping the use of one HoA and starting the use of another HoA rather than using multiple home addresses. Vijay Thierry Ernst wrote: > Several comments: > - doesn't this thread initiated Rajeev belong to Shim6 ? > > - if it doesn't, it would be more appropriate to discuss it on the > Monami6 ML, although we excluded to produce an output on the matter > where the MN (i.e. either a host or a router) has multiple HoAs. But, > still, Monami6 see is the right ML to discuss it when node multihoming > comes to mobility. > > Thierry. > > > > > > On Wed, 07 Jun 2006 11:51:32 -0700 > Vijay Devarapalli wrote: > >> Rajeev Koodli wrote: >> >>>> if not for privacy, perhaps the mobile node shouldn't >>>> change its HoA abruptly, but let existing sessions >>>> continue with the existing HoA and use the new HoA >>>> for new sessions. the mobile node would also have >>>> to update the DNS entry if it wants its FQDN to >>>> resolve to the new HoA. >>>> >>> The problem here is how does the MN know to "let the >>> existing sessions continue with the existing HoA"? If there is no CN's >>> address in BUL, surely the MN can choose a suitable HoA. For >>> a CN with which it has a binding, it has no reliable way of knowing >>> whether there are any ULP sessions. >> we could easily say its implementation specific since its >> internal to the mobile node. :) >> >> there are many ways this can be achieved inside a mobile >> node. >> >> 1. the mobile node keeps track of number of packets sent >> using a particular binding update list entry. it can >> record this information in the binding update list entry >> itself. >> >> 2. the mobile node records the timestamp of the last packet >> sent using a particular binding update list entry in the >> binding update list entry itself. >> >> 3. the mobile node keeps track of all the sockets that >> were opened with a particular home address. >> >> 4. etc.... >> >> you would see this issue in a non-Mobile IPv6 host too >> when you have multiple IPv6 addresses and the host wants >> to stop using a particular IPv6 address and start using >> another IPv6 address. >> >> let me know if I am completely off track. >> >> Vijay >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jun 09 12:55:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokH2-0004D2-Rd; Fri, 09 Jun 2006 12:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokH1-0004Ct-IC; Fri, 09 Jun 2006 12:55:51 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FokH0-000743-4y; Fri, 09 Jun 2006 12:55:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k59GtkEZ013738; Fri, 9 Jun 2006 19:55:46 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 19:55:46 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jun 2006 19:55:45 +0300 Message-ID: <4489A80F.3060608@iprg.nokia.com> Date: Fri, 09 Jun 2006 09:55:43 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> <448772F6.9060009@iprg.nokia.com> <44886786.1010106@azairenet.com> In-Reply-To: <44886786.1010106@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 16:55:45.0610 (UTC) FILETIME=[8D0192A0:01C68BE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Vijay Devarapalli wrote: >>> Yes, but you don't expect session persistence in that case. >> > > hmmm.... you still need the sessions using the old IPv6 > address to continue right? > I meant for non-MIP case.. If you are not using MIP, you don't expect the session to survive if you change the address. -Rajeev > Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jun 09 22:31:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FotGE-0007Ao-Qq; Fri, 09 Jun 2006 22:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FotGD-0007Aj-BP for mobopts@irtf.org; Fri, 09 Jun 2006 22:31:37 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FotGB-0002wn-PS for mobopts@irtf.org; Fri, 09 Jun 2006 22:31:37 -0400 Received: from ep_ms7_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J0M00I50HOLQT@mailout3.samsung.com> for mobopts@irtf.org; Sat, 10 Jun 2006 11:31:33 +0900 (KST) Received: from ep_spt02 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J0M00EUWHOL7J@ms7.samsung.com> for mobopts@irtf.org; Sat, 10 Jun 2006 11:31:33 +0900 (KST) Content-return: prohibited Date: Sat, 10 Jun 2006 02:30:09 +0000 (GMT) From: Daniel Park To: "mobopts@irtf.org" Message-id: <1209207.94001149906689936.JavaMail.weblogic@ep_ml04> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20060610023129933@soohong.park X-MTR: 20060610023129933@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Mobopts] New I-D: draft-korhonen-mobopts-link-characteristics-ps-01 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0183823173==" Errors-To: mobopts-bounces@irtf.org --===============0183823173== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 RllJLi4uDQoNCg0KVGl0bGUJOiBMaW5rIENoYXJhY3RlcmlzdGljIEluZm9ybWF0aW9uIGZvciBJ UCBNb2JpbGl0eSBQcm9ibGVtIFN0YXRlbWVudA0KQXV0aG9yKHMpCTogSi4gS29yaG9uZW4sIGV0 IGFsLg0KRmlsZW5hbWUJOiBkcmFmdC1rb3Job25lbi1tb2JvcHRzLWxpbmstY2hhcmFjdGVyaXN0 aWNzLXBzLTAxLnR4dA0KUGFnZXMJOiAyMA0KRGF0ZQk6IDIwMDYtNi05DQoJDQpUaGlzIGRvY3Vt ZW50IGRpc2N1c3NlcyB0aGUgcHJvYmxlbSBzcGFjZSByZWxhdGVkIHRvIGZyZXF1ZW50IGNoYW5n ZXMNCmluIHRoZSBsb2NhbCBsaW5rIG9yIHN1Yi1wYXRoIGNoYXJhY3RlcmlzdGljcyBvZiBhIG1v YmlsZSBub2RlIGR1ZSB0bw0KdmFyaW91cyByZWFzb25zIHN1Y2ggYXMgdmVydGljYWwgaGFuZG92 ZXJzIGFuZCB0aGUgZGVsaXZlcnkgb2YgdGhlDQpzdWItcGF0aCBjaGFyYWN0ZXJpc3RpYyBpbmZv cm1hdGlvbiBmcm9tIGEgbW9iaWxlIG5vZGUgdG8gaXRzIHBlZXINCm5vZGVzLiAgVGhlIHB1cnBv c2Ugb2YgdGhpcyBkb2N1bWVudCBpcyB0byBkZWZpbmUgdGhlIHNjb3BlIGFuZA0KcmVxdWlyZW1l bnRzIGZvciBwb3NzaWJsZSBmdXR1cmUgd29yayBvbiBhIGdlbmVyaWMgc3ViLXBhdGgNCmNoYXJh Y3RlcmlzdGljIGluZm9ybWF0aW9uIGRlbGl2ZXJ5IG1lY2hhbmlzbSBmb3Igb3B0aW1pemluZyBJ UA0KbW9iaWxpdHkgIHBlcmZvcm1hbmNlIGFuZCByZWR1Y2luZyB0aGUgaW1wbGljYXRpb25zIHRo YXQgc2lnbmlmaWNhbnQNCmNoYW5nZXMgaW4gdGhlIGxvY2FsIGxpbmsgb3Igc3ViLXBhdGggY2hh cmFjdGVyaXN0aWNzIHRlbmQgdG8gY3JlYXRlDQp0byB0aGUgdHJhbnNwb3J0IGFuZCBhcHBsaWNh dGlvbiBwcm90b2NvbCBiZWhhdmlvdXIgYnkgYWx0ZXJpbmcgdGhlDQplbmQtdG8tZW5kIHBhdGgg cHJvcGVydGllcy4NCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rb3Job25lbi1tb2JvcHRzLWxpbmst Y2hhcmFjdGVyaXN0aWNzLXBzLTAxLnR4dA0KDQoNCiANCiANCkRhbmllbCAoU29vaG9uZyBEYW5p ZWwgUGFyaykNCk1vYmlsZSBDb252ZXJnZW5jZSBMYWJvcmF0b3J5LiBTQU1TVU5HIEVsZWN0cm9u aWNzDQogDQogDQogDQog --===============0183823173== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0183823173==-- From mobopts-bounces@irtf.org Mon Jun 12 11:46:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpocD-00040n-Sm; Mon, 12 Jun 2006 11:46:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpocD-00040i-15 for mobopts@irtf.org; Mon, 12 Jun 2006 11:46:09 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpocB-0006ik-E0 for mobopts@irtf.org; Mon, 12 Jun 2006 11:46:09 -0400 Message-ID: <031501c68e37$67f6c990$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Mon, 12 Jun 2006 08:46:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [Mobopts] Ternli BOF X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org In case folks haven't seen this. It seems to address the discussion last week. jak ----------------------------- Transport-Enhancing Refinements to the Network Layer Interface (TERNLI) (pronounce: "turn-ly") BOF Chairs: Sponsoring Area Directors: Lars Eggert Magnus Westerlund Jari Arkko Mailing List: General Discussion: ternli@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ternli Archive: http://www.ietf.org/mail-archive/web/ternli/index.html BACKGROUND The communication abstraction provided by IP at the network layer delivers packets in an unordered, unreliable manner and does not protect against duplication. The users of this abstraction, i.e., the transport protocols, have made additional assumptions about this abstraction. Many of these assumptions are critical to the effective operation of important transport mechanisms, such as congestion control, flow control or reliability. These assumptions include, for example, that hosts remain at network locations identified by an IP address on timescales that are orders of magnitude larger than the duration of a communication instance. Another such assumption is that packets flowing from a source to a destination mostly follow the same path and that changes to that path occur on timescales that are several orders of magnitude larger than the RTT between the two hosts. Similarly, transport mechanisms have assumed that the characteristics of such paths, such as bandwidth, delay, reordering and loss probabilities, also change on timescales much larger than the RTT. In the current Internet, many of these assumptions are no longer generally true, because it has become much more dynamic in recent years. Mobile hosts and whole subnetworks have started to move between network locations on relatively short timescales. A growing number of hosts is multi-homed, connected through multiple links with possibly very different properties at the same time. The Internet has incorporated new link technologies with characteristics that are much more dynamic than in the past, due to functionality such as link- layer retransmissions, adaptive coding or support for link-local mobility. Several extensions to the internal functionality of the network layer, such as Mobile IP, NEMO, HIP or SHIM6, support communication in such dynamic environments. These extensions maintain the traditional interface between network and transport layers, isolating the transports from some of the dynamic effects present at and below the network layer, similar to how transports remain unaware of routing changes or packet fragmentation. They consequently allow existing transport protocols to continue to operate without modifications. This isolation, however, comes at a cost, because the traditional communication abstraction maintained by these new network-layer extensions hides information that transport-layer protocols should act on. Many common transport mechanisms, such as congestion window estimation, RTT measurements or path MTU discovery, are not agile enough to properly handle the significant instantaneous changes to path characteristics that these network-layer extensions introduce. This can, in turn, decrease the effectiveness of important transport mechanisms, such as congestion control. Consequently, although existing transports can operate on top of these network-layer extensions to some degree, their performance and efficiency decreases. SCOPE This BOF brings together the INT and TSV communities to discuss how this inter-area problem space can be successfully approached within the IETF and IRTF. Consequently, detailed presentations of specific technical proposals are out-of-scope for this BOF. The BOF will also *not* lead to the formation of a working group. The goal is to give interested parties a venue for discussing how this problem space might be sliced. The simple, general purpose interface between the network and transport layers is one of the key features that has guaranteed the evolvability of the Internet architecture, because it maintains the independence of transport layers from functionality located below it, and vice versa. Approaches for extending this core component must therefore be broadly applicable and be of general usefulness. Point solutions that optimize for specific deployment scenarios or technologies are thus not relevant to this discussion. DISCUSSION MATERIAL A possible approach might be to identify a generic, technology- independent set of well-defined network- and lower-layer information that has the potential to improve performance and operation of a large number of different transport mechanisms and protocols and can be provided in different ways by different specific underlying mechanisms and technologies. This information must be optional, i.e., it might improve transport operation if present, but transports must not depend on its presence. One existing example of an extension that follows this general approach is Explicit Congestion Notification (ECN). The ECN signal is well-defined and can be provided in different ways by network-layer mechanisms; transport protocols act on the signal independently of where and how it was generated. Another example of such an extension in this spirit is Quick-Start, were routers in the network explicitly signal source hosts the available capacity along the path to their destinations. Transport protocols can utilize this generic, technology-independent, network-layer information in different ways to improve operation and performance. One approach forward may be to integrate these existing or proposed mechanisms with additional, similar extensions that result in a uniform extension to the current network-layer interface. The BOF organizers are interested in soliciting additional approaches that attempt to address this problem space. FURTHER READING L. Eggert and W. Eddy. Towards More Expressive Transport-Layer Interfaces. Under Submission, June 2006. http://larseggert.de/papers/2006-ccr-transport-interfaces.pdf B. Aboba (ed.) Architectural Implications of Link Indications. Internet Draft draft-iab-link-indications-04, Work in Progress, December 2005. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-iab- link-indications-04.txt K. Ramakrishnan, S. Floyd and D. Black. The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168, September 2001. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=3168 A. Jain, S. Floyd, M. Allman and P. Sarolahti. Quick-Start for TCP and IP. Internet Draft draft-ietf-tsvwg-quickstart-03, Work in Progress, April 2006. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=&draft=draft- ietf-tsvwg-quickstart-03 S. Schuetz, L. Eggert, W. Eddy, Y. Swami and K. Le. TCP Response to Lower-Layer Connectivity-Change Indications. Internet Draft draft- schuetz-tcpm-tcp-rlci-00, Work in Progress, May 2006. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=&draft=draft- schuetz-tcpm-tcp-rlci-00 -- Lars Eggert NEC Network Laboratories _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jun 12 13:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqFR-0001vm-Cb; Mon, 12 Jun 2006 13:30:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FplU2-00035I-2d; Mon, 12 Jun 2006 08:25:30 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FplTy-0000Im-RA; Mon, 12 Jun 2006 08:25:30 -0400 Received: from c-24-16-73-85.hsd1.wa.comcast.net ([24.16.73.85] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1FplTy-000GOR-2d; Mon, 12 Jun 2006 08:25:26 -0400 Received: by internaut.com (Postfix, from userid 1000) id D974B4F5E5; Mon, 12 Jun 2006 05:25:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id CCB5E4F5E4; Mon, 12 Jun 2006 05:25:24 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.73.85 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Mon, 12 Jun 2006 05:25:24 -0700 (PDT) From: Bernard Aboba To: ternli@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Mon, 12 Jun 2006 13:30:43 -0400 Cc: mobopts@irtf.org, int-area@ietf.org, ietf@ietf.org, tsvwg@ietf.org Subject: [Mobopts] Re: [Int-area] BOF: Transport-Enhancing Refinements to the Network Layer Interface (TERNLI) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org > This isolation, however, comes at a cost, because the traditional > communication abstraction maintained by these new network-layer extensions > hides information that transport-layer protocols should act on. The information is hidden only for the purposes of connection management, not for parameter estimation. > Many common > transport mechanisms, such as congestion window estimation, RTT measurements > or path MTU discovery, are not agile enough to properly handle the significant > instantaneous changes to path characteristics that these network-layer > extensions introduce. I might say that "Many current transport algorithms for...", so that it is not implied that there are no algorithms that would work. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jun 12 13:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqFR-0001vZ-4c; Mon, 12 Jun 2006 13:30:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpgvO-0001bN-Uy for mobopts@irtf.org; Mon, 12 Jun 2006 03:33:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpgvO-0006hZ-RV for mobopts@irtf.org; Mon, 12 Jun 2006 03:33:26 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FpgvL-0001mg-GS for mobopts@irtf.org; Mon, 12 Jun 2006 03:33:26 -0400 Received: from lars.local (unknown [192.100.124.156]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6A2661BAC4D; Mon, 12 Jun 2006 09:22:34 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 1FCC010CDD1; Mon, 12 Jun 2006 10:33:16 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v750) Message-Id: From: Lars Eggert Date: Mon, 12 Jun 2006 10:33:14 +0300 To: ietf@ietf.org, tsvwg@ietf.org, int-area@ietf.org, mobopts@irtf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: -2.6 (--) X-Scan-Signature: 850245b51c39701e2700a112f3032caa X-Mailman-Approved-At: Mon, 12 Jun 2006 13:30:44 -0400 Cc: Magnus Westerlund , Jari Arkko Subject: [Mobopts] BOF: Transport-Enhancing Refinements to the Network Layer Interface (TERNLI) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ternli@ietf.org List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1170577033==" Errors-To: mobopts-bounces@irtf.org --===============1170577033== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--8296813; protocol="application/pkcs7-signature" --Apple-Mail-4--8296813 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, please note that the TSV and INT are sponsoring the following non-WG- forming BOF in Montreal. We'd welcome any input you may have on the scope or content of this BOF. This discussion should take place on the BOF mailing list. Thanks, Lars ------------------------------------------------------------------------ -- Transport-Enhancing Refinements to the Network Layer Interface (TERNLI) (pronounce: "turn-ly") BOF Chairs: Sponsoring Area Directors: Lars Eggert Magnus Westerlund Jari Arkko Mailing List: General Discussion: ternli@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ternli Archive: http://www.ietf.org/mail-archive/web/ternli/index.html BACKGROUND The communication abstraction provided by IP at the network layer delivers packets in an unordered, unreliable manner and does not protect against duplication. The users of this abstraction, i.e., the transport protocols, have made additional assumptions about this abstraction. Many of these assumptions are critical to the effective operation of important transport mechanisms, such as congestion control, flow control or reliability. These assumptions include, for example, that hosts remain at network locations identified by an IP address on timescales that are orders of magnitude larger than the duration of a communication instance. Another such assumption is that packets flowing from a source to a destination mostly follow the same path and that changes to that path occur on timescales that are several orders of magnitude larger than the RTT between the two hosts. Similarly, transport mechanisms have assumed that the characteristics of such paths, such as bandwidth, delay, reordering and loss probabilities, also change on timescales much larger than the RTT. In the current Internet, many of these assumptions are no longer generally true, because it has become much more dynamic in recent years. Mobile hosts and whole subnetworks have started to move between network locations on relatively short timescales. A growing number of hosts is multi-homed, connected through multiple links with possibly very different properties at the same time. The Internet has incorporated new link technologies with characteristics that are much more dynamic than in the past, due to functionality such as link- layer retransmissions, adaptive coding or support for link-local mobility. Several extensions to the internal functionality of the network layer, such as Mobile IP, NEMO, HIP or SHIM6, support communication in such dynamic environments. These extensions maintain the traditional interface between network and transport layers, isolating the transports from some of the dynamic effects present at and below the network layer, similar to how transports remain unaware of routing changes or packet fragmentation. They consequently allow existing transport protocols to continue to operate without modifications. This isolation, however, comes at a cost, because the traditional communication abstraction maintained by these new network-layer extensions hides information that transport-layer protocols should act on. Many common transport mechanisms, such as congestion window estimation, RTT measurements or path MTU discovery, are not agile enough to properly handle the significant instantaneous changes to path characteristics that these network-layer extensions introduce. This can, in turn, decrease the effectiveness of important transport mechanisms, such as congestion control. Consequently, although existing transports can operate on top of these network-layer extensions to some degree, their performance and efficiency decreases. SCOPE This BOF brings together the INT and TSV communities to discuss how this inter-area problem space can be successfully approached within the IETF and IRTF. Consequently, detailed presentations of specific technical proposals are out-of-scope for this BOF. The BOF will also *not* lead to the formation of a working group. The goal is to give interested parties a venue for discussing how this problem space might be sliced. The simple, general purpose interface between the network and transport layers is one of the key features that has guaranteed the evolvability of the Internet architecture, because it maintains the independence of transport layers from functionality located below it, and vice versa. Approaches for extending this core component must therefore be broadly applicable and be of general usefulness. Point solutions that optimize for specific deployment scenarios or technologies are thus not relevant to this discussion. DISCUSSION MATERIAL A possible approach might be to identify a generic, technology- independent set of well-defined network- and lower-layer information that has the potential to improve performance and operation of a large number of different transport mechanisms and protocols and can be provided in different ways by different specific underlying mechanisms and technologies. This information must be optional, i.e., it might improve transport operation if present, but transports must not depend on its presence. One existing example of an extension that follows this general approach is Explicit Congestion Notification (ECN). The ECN signal is well-defined and can be provided in different ways by network-layer mechanisms; transport protocols act on the signal independently of where and how it was generated. Another example of such an extension in this spirit is Quick-Start, were routers in the network explicitly signal source hosts the available capacity along the path to their destinations. Transport protocols can utilize this generic, technology-independent, network-layer information in different ways to improve operation and performance. One approach forward may be to integrate these existing or proposed mechanisms with additional, similar extensions that result in a uniform extension to the current network-layer interface. The BOF organizers are interested in soliciting additional approaches that attempt to address this problem space. FURTHER READING L. Eggert and W. Eddy. Towards More Expressive Transport-Layer Interfaces. Under Submission, June 2006. http://larseggert.de/papers/2006-ccr-transport-interfaces.pdf B. Aboba (ed.) Architectural Implications of Link Indications. Internet Draft draft-iab-link-indications-04, Work in Progress, December 2005. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-iab- link-indications-04.txt K. Ramakrishnan, S. Floyd and D. Black. The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168, September 2001. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=3168 A. Jain, S. Floyd, M. Allman and P. Sarolahti. Quick-Start for TCP and IP. Internet Draft draft-ietf-tsvwg-quickstart-03, Work in Progress, April 2006. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=&draft=draft- ietf-tsvwg-quickstart-03 S. Schuetz, L. Eggert, W. Eddy, Y. Swami and K. Le. TCP Response to Lower-Layer Connectivity-Change Indications. Internet Draft draft- schuetz-tcpm-tcp-rlci-00, Work in Progress, May 2006. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=&draft=draft- schuetz-tcpm-tcp-rlci-00 -- Lars Eggert NEC Network Laboratories --Apple-Mail-4--8296813 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNjEyMDczMzE1WjAjBgkqhkiG9w0BCQQxFgQUxKbKVSew55b5Nfl7uETT OVyuI9AwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAAb39pa9/Wa41qY4DMbCHM+H2mYNaKF1WcOqY5V26mH7gUWhki1DRKd1N7VI/12YONyRb45w 20avN0Nfss796SxlFW1/59/uLio2wJqklZUEeOf3RMzuJ+B8fLg0ZDoNr5zpSbW76FAQvkl6ebm1 tFGOHdNWTTh+46I4WcYYcd8p8wAvrpB/Gl1nuVf5f0BWYXVR1YNHDJwDPTP+g7rMfyqts4uFj/lw 3/qhA9FrfTchL5oxdP1+xmrORLHWN/UMrJI/XqZj6lCDCl2I4YiD+jgMcxEKP4M7EUgrb5Bh9fhS oBpYOhBDCCl7uvKSc7nGg6NBDbTA1k0c63BVAyBfGioAAAAAAAA= --Apple-Mail-4--8296813-- --===============1170577033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============1170577033==-- From mobopts-bounces@irtf.org Mon Jun 12 13:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqFR-0001vm-Cb; Mon, 12 Jun 2006 13:30:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FplU2-00035I-2d; Mon, 12 Jun 2006 08:25:30 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FplTy-0000Im-RA; Mon, 12 Jun 2006 08:25:30 -0400 Received: from c-24-16-73-85.hsd1.wa.comcast.net ([24.16.73.85] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1FplTy-000GOR-2d; Mon, 12 Jun 2006 08:25:26 -0400 Received: by internaut.com (Postfix, from userid 1000) id D974B4F5E5; Mon, 12 Jun 2006 05:25:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id CCB5E4F5E4; Mon, 12 Jun 2006 05:25:24 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.73.85 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Mon, 12 Jun 2006 05:25:24 -0700 (PDT) From: Bernard Aboba To: ternli@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Mon, 12 Jun 2006 13:30:43 -0400 Cc: mobopts@irtf.org, int-area@ietf.org, ietf@ietf.org, tsvwg@ietf.org Subject: [Mobopts] Re: [Int-area] BOF: Transport-Enhancing Refinements to the Network Layer Interface (TERNLI) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org > This isolation, however, comes at a cost, because the traditional > communication abstraction maintained by these new network-layer extensions > hides information that transport-layer protocols should act on. The information is hidden only for the purposes of connection management, not for parameter estimation. > Many common > transport mechanisms, such as congestion window estimation, RTT measurements > or path MTU discovery, are not agile enough to properly handle the significant > instantaneous changes to path characteristics that these network-layer > extensions introduce. I might say that "Many current transport algorithms for...", so that it is not implied that there are no algorithms that would work. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jun 12 13:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqFR-0001vZ-4c; Mon, 12 Jun 2006 13:30:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpgvO-0001bN-Uy for mobopts@irtf.org; Mon, 12 Jun 2006 03:33:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpgvO-0006hZ-RV for mobopts@irtf.org; Mon, 12 Jun 2006 03:33:26 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FpgvL-0001mg-GS for mobopts@irtf.org; Mon, 12 Jun 2006 03:33:26 -0400 Received: from lars.local (unknown [192.100.124.156]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6A2661BAC4D; Mon, 12 Jun 2006 09:22:34 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 1FCC010CDD1; Mon, 12 Jun 2006 10:33:16 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v750) Message-Id: From: Lars Eggert Date: Mon, 12 Jun 2006 10:33:14 +0300 To: ietf@ietf.org, tsvwg@ietf.org, int-area@ietf.org, mobopts@irtf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: -2.6 (--) X-Scan-Signature: 850245b51c39701e2700a112f3032caa X-Mailman-Approved-At: Mon, 12 Jun 2006 13:30:44 -0400 Cc: Magnus Westerlund , Jari Arkko Subject: [Mobopts] BOF: Transport-Enhancing Refinements to the Network Layer Interface (TERNLI) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ternli@ietf.org List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1170577033==" Errors-To: mobopts-bounces@irtf.org --===============1170577033== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--8296813; protocol="application/pkcs7-signature" --Apple-Mail-4--8296813 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, please note that the TSV and INT are sponsoring the following non-WG- forming BOF in Montreal. We'd welcome any input you may have on the scope or content of this BOF. This discussion should take place on the BOF mailing list. Thanks, Lars ------------------------------------------------------------------------ -- Transport-Enhancing Refinements to the Network Layer Interface (TERNLI) (pronounce: "turn-ly") BOF Chairs: Sponsoring Area Directors: Lars Eggert Magnus Westerlund Jari Arkko Mailing List: General Discussion: ternli@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ternli Archive: http://www.ietf.org/mail-archive/web/ternli/index.html BACKGROUND The communication abstraction provided by IP at the network layer delivers packets in an unordered, unreliable manner and does not protect against duplication. The users of this abstraction, i.e., the transport protocols, have made additional assumptions about this abstraction. Many of these assumptions are critical to the effective operation of important transport mechanisms, such as congestion control, flow control or reliability. These assumptions include, for example, that hosts remain at network locations identified by an IP address on timescales that are orders of magnitude larger than the duration of a communication instance. Another such assumption is that packets flowing from a source to a destination mostly follow the same path and that changes to that path occur on timescales that are several orders of magnitude larger than the RTT between the two hosts. Similarly, transport mechanisms have assumed that the characteristics of such paths, such as bandwidth, delay, reordering and loss probabilities, also change on timescales much larger than the RTT. In the current Internet, many of these assumptions are no longer generally true, because it has become much more dynamic in recent years. Mobile hosts and whole subnetworks have started to move between network locations on relatively short timescales. A growing number of hosts is multi-homed, connected through multiple links with possibly very different properties at the same time. The Internet has incorporated new link technologies with characteristics that are much more dynamic than in the past, due to functionality such as link- layer retransmissions, adaptive coding or support for link-local mobility. Several extensions to the internal functionality of the network layer, such as Mobile IP, NEMO, HIP or SHIM6, support communication in such dynamic environments. These extensions maintain the traditional interface between network and transport layers, isolating the transports from some of the dynamic effects present at and below the network layer, similar to how transports remain unaware of routing changes or packet fragmentation. They consequently allow existing transport protocols to continue to operate without modifications. This isolation, however, comes at a cost, because the traditional communication abstraction maintained by these new network-layer extensions hides information that transport-layer protocols should act on. Many common transport mechanisms, such as congestion window estimation, RTT measurements or path MTU discovery, are not agile enough to properly handle the significant instantaneous changes to path characteristics that these network-layer extensions introduce. This can, in turn, decrease the effectiveness of important transport mechanisms, such as congestion control. Consequently, although existing transports can operate on top of these network-layer extensions to some degree, their performance and efficiency decreases. SCOPE This BOF brings together the INT and TSV communities to discuss how this inter-area problem space can be successfully approached within the IETF and IRTF. Consequently, detailed presentations of specific technical proposals are out-of-scope for this BOF. The BOF will also *not* lead to the formation of a working group. The goal is to give interested parties a venue for discussing how this problem space might be sliced. The simple, general purpose interface between the network and transport layers is one of the key features that has guaranteed the evolvability of the Internet architecture, because it maintains the independence of transport layers from functionality located below it, and vice versa. Approaches for extending this core component must therefore be broadly applicable and be of general usefulness. Point solutions that optimize for specific deployment scenarios or technologies are thus not relevant to this discussion. DISCUSSION MATERIAL A possible approach might be to identify a generic, technology- independent set of well-defined network- and lower-layer information that has the potential to improve performance and operation of a large number of different transport mechanisms and protocols and can be provided in different ways by different specific underlying mechanisms and technologies. This information must be optional, i.e., it might improve transport operation if present, but transports must not depend on its presence. One existing example of an extension that follows this general approach is Explicit Congestion Notification (ECN). The ECN signal is well-defined and can be provided in different ways by network-layer mechanisms; transport protocols act on the signal independently of where and how it was generated. Another example of such an extension in this spirit is Quick-Start, were routers in the network explicitly signal source hosts the available capacity along the path to their destinations. Transport protocols can utilize this generic, technology-independent, network-layer information in different ways to improve operation and performance. One approach forward may be to integrate these existing or proposed mechanisms with additional, similar extensions that result in a uniform extension to the current network-layer interface. The BOF organizers are interested in soliciting additional approaches that attempt to address this problem space. FURTHER READING L. Eggert and W. Eddy. Towards More Expressive Transport-Layer Interfaces. Under Submission, June 2006. http://larseggert.de/papers/2006-ccr-transport-interfaces.pdf B. Aboba (ed.) Architectural Implications of Link Indications. Internet Draft draft-iab-link-indications-04, Work in Progress, December 2005. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-iab- link-indications-04.txt K. Ramakrishnan, S. Floyd and D. Black. The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168, September 2001. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=3168 A. Jain, S. Floyd, M. Allman and P. Sarolahti. Quick-Start for TCP and IP. Internet Draft draft-ietf-tsvwg-quickstart-03, Work in Progress, April 2006. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=&draft=draft- ietf-tsvwg-quickstart-03 S. Schuetz, L. Eggert, W. Eddy, Y. Swami and K. Le. TCP Response to Lower-Layer Connectivity-Change Indications. Internet Draft draft- schuetz-tcpm-tcp-rlci-00, Work in Progress, May 2006. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=&draft=draft- schuetz-tcpm-tcp-rlci-00 -- Lars Eggert NEC Network Laboratories --Apple-Mail-4--8296813 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNjEyMDczMzE1WjAjBgkqhkiG9w0BCQQxFgQUxKbKVSew55b5Nfl7uETT OVyuI9AwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAAb39pa9/Wa41qY4DMbCHM+H2mYNaKF1WcOqY5V26mH7gUWhki1DRKd1N7VI/12YONyRb45w 20avN0Nfss796SxlFW1/59/uLio2wJqklZUEeOf3RMzuJ+B8fLg0ZDoNr5zpSbW76FAQvkl6ebm1 tFGOHdNWTTh+46I4WcYYcd8p8wAvrpB/Gl1nuVf5f0BWYXVR1YNHDJwDPTP+g7rMfyqts4uFj/lw 3/qhA9FrfTchL5oxdP1+xmrORLHWN/UMrJI/XqZj6lCDCl2I4YiD+jgMcxEKP4M7EUgrb5Bh9fhS oBpYOhBDCCl7uvKSc7nGg6NBDbTA1k0c63BVAyBfGioAAAAAAAA= --Apple-Mail-4--8296813-- --===============1170577033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============1170577033==-- From mobopts-bounces@irtf.org Mon Jun 12 13:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqS1-0000sv-Be; Mon, 12 Jun 2006 13:43:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqS0-0000sq-Ax for mobopts@irtf.org; Mon, 12 Jun 2006 13:43:44 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpqRy-0000Wq-57 for mobopts@irtf.org; Mon, 12 Jun 2006 13:43:44 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5CHRNLV030441; Mon, 12 Jun 2006 20:27:35 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 20:26:53 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 12 Jun 2006 20:26:52 +0300 Message-ID: <448DA3D8.2050703@iprg.nokia.com> Date: Mon, 12 Jun 2006 10:26:48 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobopts] Ternli BOF References: <031501c68e37$67f6c990$026115ac@dcml.docomolabsusa.com> In-Reply-To: <031501c68e37$67f6c990$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2006 17:26:52.0511 (UTC) FILETIME=[65014EF0:01C68E45] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org We should have some discussion on this at MobOpts and interact with the BOF. Of course, our problem is lot more specific. -Rajeev James Kempf wrote: > In case folks haven't seen this. It seems to address the discussion > last week. > > jak > > ----------------------------- > > Transport-Enhancing Refinements to the Network Layer Interface (TERNLI) > (pronounce: "turn-ly") > > BOF Chairs: > > > Sponsoring Area Directors: > Lars Eggert > Magnus Westerlund > Jari Arkko > > Mailing List: > General Discussion: ternli@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ternli > Archive: http://www.ietf.org/mail-archive/web/ternli/index.html > > > BACKGROUND > > The communication abstraction provided by IP at the network layer > delivers packets in an unordered, unreliable manner and does not > protect against duplication. The users of this abstraction, i.e., the > transport protocols, have made additional assumptions about this > abstraction. Many of these assumptions are critical to the effective > operation of important transport mechanisms, such as congestion > control, flow control or reliability. These assumptions include, for > example, that hosts remain at network locations identified by an IP > address on timescales that are orders of magnitude larger than the > duration of a communication instance. Another such assumption is that > packets flowing from a source to a destination mostly follow the same > path and that changes to that path occur on timescales that are > several orders of magnitude larger than the RTT between the two > hosts. Similarly, transport mechanisms have assumed that the > characteristics of such paths, such as bandwidth, delay, reordering > and loss probabilities, also change on timescales much larger than > the RTT. > > In the current Internet, many of these assumptions are no longer > generally true, because it has become much more dynamic in recent > years. Mobile hosts and whole subnetworks have started to move > between network locations on relatively short timescales. A growing > number of hosts is multi-homed, connected through multiple links with > possibly very different properties at the same time. The Internet has > incorporated new link technologies with characteristics that are much > more dynamic than in the past, due to functionality such as link- > layer retransmissions, adaptive coding or support for link-local > mobility. > > Several extensions to the internal functionality of the network > layer, such as Mobile IP, NEMO, HIP or SHIM6, support communication > in such dynamic environments. These extensions maintain the > traditional interface between network and transport layers, isolating > the transports from some of the dynamic effects present at and below > the network layer, similar to how transports remain unaware of > routing changes or packet fragmentation. They consequently allow > existing transport protocols to continue to operate without > modifications. > > This isolation, however, comes at a cost, because the traditional > communication abstraction maintained by these new network-layer > extensions hides information that transport-layer protocols should > act on. Many common transport mechanisms, such as congestion window > estimation, RTT measurements or path MTU discovery, are not agile > enough to properly handle the significant instantaneous changes to > path characteristics that these network-layer extensions introduce. > This can, in turn, decrease the effectiveness of important transport > mechanisms, such as congestion control. Consequently, although > existing transports can operate on top of these network-layer > extensions to some degree, their performance and efficiency decreases. > > > SCOPE > > This BOF brings together the INT and TSV communities to discuss how > this inter-area problem space can be successfully approached within > the IETF and IRTF. Consequently, detailed presentations of specific > technical proposals are out-of-scope for this BOF. The BOF will also > *not* lead to the formation of a working group. The goal is to give > interested parties a venue for discussing how this problem space > might be sliced. > > The simple, general purpose interface between the network and > transport layers is one of the key features that has guaranteed the > evolvability of the Internet architecture, because it maintains the > independence of transport layers from functionality located below it, > and vice versa. Approaches for extending this core component must > therefore be broadly applicable and be of general usefulness. Point > solutions that optimize for specific deployment scenarios or > technologies are thus not relevant to this discussion. > > > DISCUSSION MATERIAL > > A possible approach might be to identify a generic, technology- > independent set of well-defined network- and lower-layer information > that has the potential to improve performance and operation of a > large number of different transport mechanisms and protocols and can > be provided in different ways by different specific underlying > mechanisms and technologies. This information must be optional, i.e., > it might improve transport operation if present, but transports must > not depend on its presence. > > One existing example of an extension that follows this general > approach is Explicit Congestion Notification (ECN). The ECN signal is > well-defined and can be provided in different ways by network-layer > mechanisms; transport protocols act on the signal independently of > where and how it was generated. Another example of such an extension > in this spirit is Quick-Start, were routers in the network explicitly > signal source hosts the available capacity along the path to their > destinations. Transport protocols can utilize this generic, > technology-independent, network-layer information in different ways > to improve operation and performance. > > One approach forward may be to integrate these existing or proposed > mechanisms with additional, similar extensions that result in a > uniform extension to the current network-layer interface. > > The BOF organizers are interested in soliciting additional approaches > that attempt to address this problem space. > > > FURTHER READING > > L. Eggert and W. Eddy. Towards More Expressive Transport-Layer > Interfaces. Under Submission, June 2006. > http://larseggert.de/papers/2006-ccr-transport-interfaces.pdf > > B. Aboba (ed.) Architectural Implications of Link Indications. > Internet Draft draft-iab-link-indications-04, Work in Progress, > December 2005. > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-iab- > link-indications-04.txt > > K. Ramakrishnan, S. Floyd and D. Black. The Addition of Explicit > Congestion Notification (ECN) to IP. RFC 3168, September 2001. > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=3168 > > A. Jain, S. Floyd, M. Allman and P. Sarolahti. Quick-Start for TCP > and IP. Internet Draft draft-ietf-tsvwg-quickstart-03, Work in > Progress, April 2006. > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=&draft=draft- > ietf-tsvwg-quickstart-03 > > S. Schuetz, L. Eggert, W. Eddy, Y. Swami and K. Le. TCP Response to > Lower-Layer Connectivity-Change Indications. Internet Draft draft- > schuetz-tcpm-tcp-rlci-00, Work in Progress, May 2006. > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=&draft=draft- > schuetz-tcpm-tcp-rlci-00 > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jun 12 14:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpql0-0005MO-3P; Mon, 12 Jun 2006 14:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpqky-0005Lx-Q9; Mon, 12 Jun 2006 14:03:20 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpqkx-00027C-CM; Mon, 12 Jun 2006 14:03:20 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5CI3FvX023490; Mon, 12 Jun 2006 21:03:17 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 21:03:17 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 12 Jun 2006 21:03:16 +0300 Message-ID: <448DAC60.5030002@iprg.nokia.com> Date: Mon, 12 Jun 2006 11:03:12 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ternli@ietf.org Subject: Re: [Mobopts] BOF: Transport-Enhancing Refinements to the Network Layer Interface (TERNLI) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2006 18:03:16.0833 (UTC) FILETIME=[7AF66510:01C68E4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Magnus Westerlund , int-area@ietf.org, ietf@ietf.org, tsvwg@ietf.org, Jari Arkko , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Lars, thanks for the pointer. We are discussing a specific mobility-related problem: when to change an IP address which we can discuss at the BOF (and at MobOpts meeting). Thanks, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 15 15:30:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxXX-0004i0-84; Thu, 15 Jun 2006 15:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxXV-0004g6-FN for mobopts@irtf.org; Thu, 15 Jun 2006 15:30:01 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxXU-0001ZA-0n for mobopts@irtf.org; Thu, 15 Jun 2006 15:30:01 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5FJTwiI016998 for ; Thu, 15 Jun 2006 22:29:59 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 22:29:58 +0300 Received: from [127.0.0.1] ([172.18.141.83]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Jun 2006 22:29:57 +0300 Message-ID: <4491B527.20605@iprg.nokia.com> Date: Thu, 15 Jun 2006 12:29:43 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 19:29:57.0286 (UTC) FILETIME=[15E9CC60:01C690B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Mobopts] Presentation requests X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello folks, please let me know if you would like to present at Montreal as soon as possible. Provide o title of your talk o URL to relevant document o time needed I am planning to have discussion on MIP - ULP interaction and Performance and Policy topics as well. Regards, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jun 16 02:46:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr861-0005mf-1p; Fri, 16 Jun 2006 02:46:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr85z-0005gq-Jk; Fri, 16 Jun 2006 02:46:19 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr85x-000638-Td; Fri, 16 Jun 2006 02:46:19 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1Fr85j-0005gz-1c; Fri, 16 Jun 2006 08:46:05 +0200 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 8C907864F; Fri, 16 Jun 2006 08:46:02 +0200 (CEST) Message-ID: <449253AA.7020907@tm.uka.de> Date: Fri, 16 Jun 2006 08:46:02 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.4) Gecko/20060527 SUSE/1.5.0.4-0.1 Thunderbird/1.5.0.4 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Rajeev Koodli , Vijay Devarapalli References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> <448772F6.9060009@iprg.nokia.com> In-Reply-To: <448772F6.9060009@iprg.nokia.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.5 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip6@ietf.org, Daniel Jungbluth , mobopts@irtf.org Subject: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Rajeev and Vijay, you could also look at existing Internet protocol control blocks. All connections, regardless of the transport protocol they use, are represented by an Internet PCB. That Internet PCB may link to a separate transport-protocol-specific PCB, but that's less important for your needs. You can iterate through a list of all Internet PCBs and look for the "foreign addresses" (i.e., CNs' addresses) recorded. If the MN has an entry in its binding update list for a given foreign address, it would have to notify that CN about the change of its home address. In a related project, we wanted to find out about the establishment of new and the tear-down of old upper-layer connections. Our goal was to create a Mobile IPv6 binding even when the mobile node is at home, in order to facilitate proactive Mobile IPv6 signaling on the home link, which some optimizations require. The project was a diploma thesis of one of my students, Daniel Jungbluth, which I supervised. The following is a link to the documentation of this work: http://doc.tm.uka.de/2006/jungbluth-2006-homebindings.pdf Daniel's diploma thesis is not exactly what /you/ are having in mind---you need to check for existing upper-layer connections, while we wanted to recognize the establishment of new or tear-down of old connections. Specifically, /we/ could not easily use Internet PCBs for our needs; keeping an eye on the sockets turned out the best way to do this in our case. But the document linked above might still be of interest to you. Check section 4.2 in particular. Kind regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Rajeev Koodli wrote: > > Hi Vijay, > > Vijay Devarapalli wrote: > >> we could easily say its implementation specific since its >> internal to the mobile node. :) >> > that's okay. I am trying to see what we can use.. > >> there are many ways this can be achieved inside a mobile >> node. >> >> 1. the mobile node keeps track of number of packets sent >> using a particular binding update list entry. it can >> record this information in the binding update list entry >> itself. >> >> 2. the mobile node records the timestamp of the last packet >> sent using a particular binding update list entry in the >> binding update list entry itself. >> >> 3. the mobile node keeps track of all the sockets that >> were opened with a particular home address. >> > This might work. (1 and 2 above don't really relate to > whether a session/connection is alive or not). > > I am referring to such interaction. How do we formalize it > (if not standardize it)? > >> 4. etc.... >> >> you would see this issue in a non-Mobile IPv6 host too >> when you have multiple IPv6 addresses and the host wants >> to stop using a particular IPv6 address and start using >> another IPv6 address. >> > Yes, but you don't expect session persistence in that case. > > -Rajeev > >> let me know if I am completely off track. >> >> Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jun 16 12:05:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGpE-0008VS-8H; Fri, 16 Jun 2006 12:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGpC-0008VG-U6 for mobopts@irtf.org; Fri, 16 Jun 2006 12:05:34 -0400 Received: from otm-mgo00.iij.ad.jp ([210.138.20.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGpB-0000vB-CP for mobopts@irtf.org; Fri, 16 Jun 2006 12:05:34 -0400 Received: OTM-MO(otm-mgo00) id k5GG5Hmp037531; Sat, 17 Jun 2006 01:05:17 +0900 (JST) Received: OTM-MIX(otm-mix01) id k5GG5HVa022588; Sat, 17 Jun 2006 01:05:17 +0900 (JST) Received: from [192.168.86.2] (h002n086.iij.ad.jp [192.168.86.2]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp) id k5GG5AE1018042 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 17 Jun 2006 01:05:14 +0900 (JST) In-Reply-To: <449253AA.7020907@tm.uka.de> References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> <448772F6.9060009@iprg.nokia.com> <449253AA.7020907@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <258D4D2C-FF32-4F1A-9513-C6FAC010485C@iijlab.net> Content-Transfer-Encoding: 7bit From: Keiichi SHIMA Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Date: Fri, 16 Jun 2006 18:05:08 +0200 To: Christian Vogt X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mip6@ietf.org, Rajeev Koodli , Daniel Jungbluth , Keiichi SHIMA , Vijay Devarapalli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, On 2006/06/16, at 8:46, Christian Vogt wrote: > you could also look at existing Internet protocol control blocks. > > All connections, regardless of the transport protocol they use, are > represented by an Internet PCB. That Internet PCB may link to a > separate transport-protocol-specific PCB, but that's less important > for > your needs. You can iterate through a list of all Internet PCBs and > look for the "foreign addresses" (i.e., CNs' addresses) recorded. If > the MN has an entry in its binding update list for a given foreign > address, it would have to notify that CN about the change of its home > address. In the BSD style PCB archtecture, we can check all connections using TCP, but it is difficult to check UDP connection(?)s. Because one UDP socket (= one PCB) may be used for multiple destination. I think, if we need more accurate mechanism to bind upper layers and MIP layer, maybe we need a new mechanism. --- Keiichi SHIMA IIJ Research Laboratory WIDE Project _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sun Jun 18 12:23:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs03w-00022V-Oq; Sun, 18 Jun 2006 12:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs03v-00022Q-LH for mobopts@irtf.org; Sun, 18 Jun 2006 12:23:47 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs03u-0002ec-6J for mobopts@irtf.org; Sun, 18 Jun 2006 12:23:47 -0400 Received: from [192.168.1.3] (p54ABBFA4.dip0.t-ipconnect.de [84.171.191.164]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5E5521BAC4D; Sun, 18 Jun 2006 18:12:14 +0200 (CEST) Message-ID: <44957E0F.10207@netlab.nec.de> Date: Sun, 18 Jun 2006 18:23:43 +0200 From: Telemaco Melia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] Performance and Policy References: <44861D2C.2010900@iprg.nokia.com> <4488C1AE.2040505@iprg.nokia.com> In-Reply-To: <4488C1AE.2040505@iprg.nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi all, Here go some first ideas. Feedback is welcome. Requirements: ========== - Unified model for both network side and terminal side - Network mainly interested in: + performance optimization (vertical handovers) + roaming across boundaries (inter domain handovers) + network controlled and network initiated handovers - (Multi mode) Terminal interested in: + Keep best connectivity (depending on radio conditions...) + Receive via multiple interfaces (multihoming, multiple bindings...) o management of flows o soft handover might be more suitable + Power saving (imagine a device with HSDPA, Wimax mobile and WLAN) o not at MAC level, rather as a policy + Influence on mobility of less volatile information such as context (applications) If people are interested I could come up with a fews slides elaborating the above. What do you think? regards, telemaco Rajeev Koodli wrote: > Vijay Devarapallli wrote: > >> On 6/6/06, Rajeev Koodli wrote: >> >>> Another topic that comes to mind is policy. Inter-technology >>> mobility is >>> subject >>> to policy controls when crossing provider boundaries. Yet, I am not >>> sure we are paying enough attention to policy when designing for >>> performance. >> >> >> I am very interested in this topic. I have been working on this >> recently. >> let me know if you need someone to write up a problem statement. >> > I like the idea of putting together a document. We should dedicate > some time > in Montreal for this topic. > In the meanwhile, what are the issues? Let's discuss on the ML. > > -Rajeev > >> Vijay > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts -- Telemaco Melia telemaco.melia@netlab.nec.de Research Staff Member Tel: +49 (0) 6221 4342- 142 Network Laboratories Fax: +49 (0) 6221 4342- 155 NEC Europe Ltd. Web: http://netlab.nec.de Kurfrsten-Anlage 36 D-69115 Heidelberg Germany _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jun 19 03:39:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEM1-0005f6-De; Mon, 19 Jun 2006 03:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsELz-0005ee-Gi for mobopts@irtf.org; Mon, 19 Jun 2006 03:39:23 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsEL3-0006kk-Kf for mobopts@irtf.org; Mon, 19 Jun 2006 03:39:23 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 0728A4C057; Mon, 19 Jun 2006 16:38:21 +0900 (JST) Date: Mon, 19 Jun 2006 10:38:19 +0300 From: Shinta Sugimoto To: Rajeev Koodli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <44870922.3040408@iprg.nokia.com> References: <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> Message-Id: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mip6@ietf.org, Vijay Devarapalli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Rajeev, I am catching up on this thread. Please find my comments inline. On Wed, 07 Jun 2006 10:13:06 -0700 Rajeev Koodli wrote: > Vijay Devarapalli wrote: > > > Rajeev Koodli wrote: > > > >> If a MN wishes to change its HoA with a CN (e.g., use a different > >> pseudo-hoa for > >> privacy purposes), it has no _reliable_ way of knowing whether it has > >> existing sessions with that CN. > > > > > > I read this paragraph three times, but couldn't get > > the context. > > > > if in the privacy context, I assume there is still > > a *real* HoA. the pseudo HoA appears in the route > > optimized traffic to the CN *instead* of the real > > HoA. the CN knows the real HoA and the pseudo HoA. > > the mapping from the real HoA to the pseudo HoA is > > done using the binding update list at the MN and > > the binding cache entry at the CN. > > > This is a way to do it. Nevertheless, keeping the privacy issue aside.. > > > if not for privacy, perhaps the mobile node shouldn't > > change its HoA abruptly, but let existing sessions > > continue with the existing HoA and use the new HoA > > for new sessions. the mobile node would also have > > to update the DNS entry if it wants its FQDN to > > resolve to the new HoA. > > > The problem here is how does the MN know to "let the > existing sessions continue with the existing HoA"? If there is no CN's > address in BUL, surely the MN can choose a suitable HoA. For > a CN with which it has a binding, it has no reliable way of knowing > whether there are any ULP sessions. If you need to maintain the sessions while changing the HoA from one to another, I think you need additional mechanism than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed to assure the reachability to a given HoA with the current location of the mobile node (CoA). If the app wants to change HoAs for some reason (I assume that privacy is the main interest), there is a need to maintain the mapping of the identity and the locator of the mobile node. One option would be to run Shim6 over MIPv6. Such usage has already been discussed in Shim6 WG. By mobile node establishing Shim6 context with its HA/CN, it could utilize multiple HoAs without annoying upper layer protocols. However, I am not sure if it fulfills your requirement especially in terms of privacy (hiding the identity, which is MN's HoA in this case). Would you see any problem with this approach ? I see that signaling overhead may also be a concern (to run both Shim6 and MIPv6). I have some additional questions: - If privacy is the main concern, would you think http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt would help to solve your initial requirement ? If not, could you please tell me why ? - Do you assume that different HoAs that mobile node may request are derived from different home prefixes ? Or are you considering that the node generates HoAs from a single prefix with privacy extension ? Regards, Shinta _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jun 19 10:29:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKlD-0000XX-69; Mon, 19 Jun 2006 10:29:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKlB-0000Wq-UJ for mobopts@irtf.org; Mon, 19 Jun 2006 10:29:49 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsKkJ-0001q2-Ab for mobopts@irtf.org; Mon, 19 Jun 2006 10:28:56 -0400 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by mailer.gwdg.de with esmtp (Exim 4.60) (envelope-from ) id 1FsKjx-0006H7-9n; Mon, 19 Jun 2006 16:28:44 +0200 Received: from [172.22.0.51] (tmg51.tmg.loc [172.22.0.51]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP; Mon, 19 Jun 2006 16:28:32 +0200 (CEST) Message-ID: <4496B490.40800@cs.uni-goettingen.de> Date: Mon, 19 Jun 2006 16:28:32 +0200 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec-rg@listserv.cybertrust.com, mobopts@irtf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: + X-Spam-Report: Content analysis: 1.3 points, 6.0 required 1.3 INFO_TLD URI: Contains an URL in the INFO top-level domain X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.5 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Mobopts] Preliminary Call for Papers: MobiArch 2006 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear colleagues, Please find below the preliminary call for papers for MobiArch'06 workshop. Our appologizes if you receive multiple copies. Best regards, Xiaoming Fu -------------------------------------------------------------------- The First IEEE/ACM* International Workshop on Mobility in the Evolving Internet Architecture (MobiArch 2006) held in conjunction with IEEE GLOBECOM 2006, San Francisco, CA, USA, November/December 2006 http://user.informatik.uni-goettingen.de/~mobiarch/ (* - IEEE/ACM sponsorship pending approval) -------------------------------------------------------------------- E-mail contact : mobiarch@cs.uni-goettingen.de CFP in printable pdf format can be downloaded in http://user.informatik.uni-goettingen.de/~mobiarch/Cfp_MobiArch06.pdf Scope: ===== With the recent development of technologies in wireless access and mobile devices, terminal and network mobility have become an indispensable component of today's Internet vision, and this is likely to continue in the near future, while affecting the way of the whole Internet architecture design. Yet, issues like efficient mobility management and optimizations, locator-identifier split, multi-homing, security and related operational/deployment concerns are still in their early stages of development. Moreover, the Internet architecture, its end-to-end principles and business models will require rethinking due to the massive penetration of mobility into the Internet. The MobiArch'06 workshop solicits papers, both from researchers and practitioners, dealing with architectures, protocols, and experiences with emerging technologies on mobility support in the Internet, with an emphasis on new mobility protocols, mobility and location management, mobile network performance, multi-homing, security, architectural impacts and deployment considerations. The workshop will include presentations and discussions of accepted technical papers, as well as invited talks and panel sessions. Topics of Interest: ================== Original contributions are solicited in all aspects of architectural issues and system support for mobility in the Internet, including but not limited to: - Mobility impact on the Internet architecture - Architectures and protocols for mobility support in the Internet, ranging from approaches in link layer, network, transport to session/application layers and cross-layer design - Locator/identifier split, multihoming and load sharing issues - Security and privacy issues in mobility networks and impacts to Internet architecture - QoS and middlebox issues in mobility networks and impacts to Internet architecture - Economic and deployment issues of mobility infrastructure designs Submissions: =========== Submissions should be made to MobiArch'06 EDAS entry: http://edas.info/4920, following the guidelines in MobiArch'06 webpage: http://user.informatik.uni-goettingen.de/~mobiarch/ Important Dates: =============== Submission Deadline: Monday, July 24, 2006 Acceptance Notification: August 31, 2006 Camera-ready version due: September 27, 2006 Workshop: One-day in GLOBECOM 2006 (to be announced) GLOBECOM Main Conference: November 27-December 1, 2006 GENERAL CHAIR ============= Jon Crowcroft, U. Cambridge (UK) PROGRAM CO-CHAIRS ================= Xiaoming Fu, U. Goettingen (DE) Katherine Guo, Bell Labs (US) PROGRAM COMMITTEE ================= Jari Arkko, Ericsson (FI) Raouf Boutaba, U. Waterloo (CA) Jon Crowcroft, U. Cambridge (UK) Wesley Eddy, NASA/Verizon (US) Xiaoming Fu, U. Goettingen (DE) Ivano Guardini, Telecom Italia Lab (IT) Katherine Guo, Bell Labs (US) Dieter Hogrefe, U. Goettingen (DE) Yuming Jiang, NTNU (NO) Cornelia Kappler, Siemens (DE) Ben Liang, U. Toronto (CA) Meng How Lim, Intel Research Cambridge (UK) John Loughney, Nokia Research Center (FI) Joerg Ott, Helsinki U of Techology (FI) Charles Perkins, Nokia Research Center (US) Christian Prehofer, Nokia Research Center (FI) Henning Schulzrinne, Columbia U. (US) Hannes Tschofenig, Siemens (DE) Zhi-Li Zhang, U. Minnesoda (US) Taieb Znati, U. Pittsburg/NSF (US) -------------------------------------------------------------------- For more information: http://user.informatik.uni-goettingen.de/~mobiarch/ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jun 19 11:29:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLhC-0004Nv-0S; Mon, 19 Jun 2006 11:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLhA-0004Nq-Gf for mobopts@irtf.org; Mon, 19 Jun 2006 11:29:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsLhA-0001Nz-EM for mobopts@irtf.org; Mon, 19 Jun 2006 11:29:44 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsLh8-0002UU-D1 for mobopts@irtf.org; Mon, 19 Jun 2006 11:29:43 -0400 Message-ID: <05e401c693b5$4d0e1510$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Telemaco Melia" , "Rajeev Koodli" References: <44861D2C.2010900@iprg.nokia.com> <4488C1AE.2040505@iprg.nokia.com> <44957E0F.10207@netlab.nec.de> Subject: Re: [Mobopts] Performance and Policy Date: Mon, 19 Jun 2006 08:30:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org "Soft handover" is a L2 technique only. If it is in use, the IP layer never sees the outstanding hanodever legs. I think you mean "make before break" handover, in which the terminal gets data plane packets via the old leg while configuring on the new AP via the new. jak ----- Original Message ----- From: "Telemaco Melia" To: "Rajeev Koodli" Cc: Sent: Sunday, June 18, 2006 9:23 AM Subject: Re: [Mobopts] Performance and Policy > Hi all, > > Here go some first ideas. Feedback is welcome. > > Requirements: > ========== > - Unified model for both network side and terminal side > > - Network mainly interested in: > + performance optimization (vertical handovers) > + roaming across boundaries (inter domain handovers) > + network controlled and network initiated handovers > > - (Multi mode) Terminal interested in: > + Keep best connectivity (depending on radio conditions...) > + Receive via multiple interfaces (multihoming, multiple bindings...) > o management of flows > o soft handover might be more suitable > + Power saving (imagine a device with HSDPA, Wimax mobile and WLAN) > o not at MAC level, rather as a policy > + Influence on mobility of less volatile information such as context > (applications) > > If people are interested I could come up with a fews slides elaborating > the above. > What do you think? > > regards, > telemaco > > > Rajeev Koodli wrote: >> Vijay Devarapallli wrote: >> >>> On 6/6/06, Rajeev Koodli wrote: >>> >>>> Another topic that comes to mind is policy. Inter-technology mobility >>>> is >>>> subject >>>> to policy controls when crossing provider boundaries. Yet, I am not >>>> sure we are paying enough attention to policy when designing for >>>> performance. >>> >>> >>> I am very interested in this topic. I have been working on this >>> recently. >>> let me know if you need someone to write up a problem statement. >>> >> I like the idea of putting together a document. We should dedicate some >> time >> in Montreal for this topic. >> In the meanwhile, what are the issues? Let's discuss on the ML. >> >> -Rajeev >> >>> Vijay >> >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts > > > -- > Telemaco Melia telemaco.melia@netlab.nec.de > Research Staff Member Tel: +49 (0) 6221 4342- 142 > Network Laboratories Fax: +49 (0) 6221 4342- 155 > NEC Europe Ltd. Web: http://netlab.nec.de > Kurfrsten-Anlage 36 > D-69115 Heidelberg > Germany > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jun 19 20:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTrS-0005n5-P0; Mon, 19 Jun 2006 20:12:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTrR-0005mp-LE for mobopts@irtf.org; Mon, 19 Jun 2006 20:12:53 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTrQ-00064z-9M for mobopts@irtf.org; Mon, 19 Jun 2006 20:12:53 -0400 Received: from [10.1.201.12] ([10.1.201.12]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 17:12:51 -0700 Message-ID: <44973D7B.6030109@azairenet.com> Date: Mon, 19 Jun 2006 17:12:43 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Shinta Sugimoto Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 00:12:51.0193 (UTC) FILETIME=[44CD7690:01C693FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Shinta Sugimoto wrote: >> The problem here is how does the MN know to "let the >> existing sessions continue with the existing HoA"? If there is no CN's >> address in BUL, surely the MN can choose a suitable HoA. For >> a CN with which it has a binding, it has no reliable way of knowing >> whether there are any ULP sessions. > > If you need to maintain the sessions while changing the HoA > from one to another, I think you need additional mechanism > than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed > to assure the reachability to a given HoA with the current > location of the mobile node (CoA). If the app wants > to change HoAs for some reason (I assume that privacy is the > main interest), there is a need to maintain the mapping of > the identity and the locator of the mobile node. Mobile IPv6 today allows you to use two home addresses at the same time. it also allows you to bind both home addresses to the same CoA. > One option would be to run Shim6 over MIPv6. Such usage has > already been discussed in Shim6 WG. By mobile node establishing > Shim6 context with its HA/CN, it could utilize multiple HoAs > without annoying upper layer protocols. yes, this can be done. but I would like to restrict shim6 usage when mip6 is used to the case where the home link is site multihomed and the mobile node already has the multiple home addresses configured on it. not when the mobile node decides to change its home address. > I have some additional questions: > > - If privacy is the main concern, would you think > http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt > would help to solve your initial requirement ? If not, could > you please tell me why ? I think its orthogonal. the use of pseudo-HoA instead of the actual HoA is also being worked on in mobopts. > - Do you assume that different HoAs that mobile node may > request are derived from different home prefixes ? Or are you > considering that the node generates HoAs from a single prefix > with privacy extension ? I think its the same prefix, but I guess its better if Rajeev clarifies. Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jun 19 21:12:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUn1-0003Kt-Bn; Mon, 19 Jun 2006 21:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUn0-0003Kf-0x; Mon, 19 Jun 2006 21:12:22 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsUmy-0007GP-Ht; Mon, 19 Jun 2006 21:12:22 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5K1CBag000308; Tue, 20 Jun 2006 04:12:16 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 04:12:14 +0300 Received: from [127.0.0.1] ([10.241.53.182]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Jun 2006 04:12:14 +0300 Message-ID: <44974B6A.6060709@iprg.nokia.com> Date: Mon, 19 Jun 2006 21:12:10 -0400 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shinta Sugimoto Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 01:12:15.0131 (UTC) FILETIME=[91133EB0:01C69406] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: mip6@ietf.org, Vijay Devarapalli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, the purpose here is to list the available options. Perhaps SHIM6 is one option, but there are others to explore. I encourage you to discuss them at the MobOpts meeting. -Rajeev ps: location privacy as such is being discussed in a problem statement draft, and there is also a mobopts drfat on solutions. Please have a look at them. Thanks. Shinta Sugimoto wrote: >Hi Rajeev, > > > >If you need to maintain the sessions while changing the HoA >from one to another, I think you need additional mechanism >than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed >to assure the reachability to a given HoA with the current >location of the mobile node (CoA). If the app wants >to change HoAs for some reason (I assume that privacy is the >main interest), there is a need to maintain the mapping of >the identity and the locator of the mobile node. > >One option would be to run Shim6 over MIPv6. Such usage has >already been discussed in Shim6 WG. By mobile node establishing >Shim6 context with its HA/CN, it could utilize multiple HoAs >without annoying upper layer protocols. However, I am not sure >if it fulfills your requirement especially in terms of privacy >(hiding the identity, which is MN's HoA in this case). >Would you see any problem with this approach ? I see that >signaling overhead may also be a concern (to run both Shim6 >and MIPv6). > >I have some additional questions: > >- If privacy is the main concern, would you think >http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt >would help to solve your initial requirement ? If not, could >you please tell me why ? >- Do you assume that different HoAs that mobile node may >request are derived from different home prefixes ? Or are you >considering that the node generates HoAs from a single prefix >with privacy extension ? > > >Regards, >Shinta > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 20 01:20:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsYfF-0000zO-3a; Tue, 20 Jun 2006 01:20:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsYfC-0000wh-V3 for mobopts@irtf.org; Tue, 20 Jun 2006 01:20:34 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsYfC-0002A5-8b for mobopts@irtf.org; Tue, 20 Jun 2006 01:20:34 -0400 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5K5KVWq017092 for ; Tue, 20 Jun 2006 00:20:32 -0500 (CDT) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Jun 2006 10:50:19 +0530 Message-ID: <3BE48DD0EC7D3948BC183931D9150C21075BEC50@ii0015exch001u.iprc.lucent.com> From: "Thaker, Shardul (Shardul)** CTR **" To: "'mobopts@irtf.org'" Date: Tue, 20 Jun 2006 10:50:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.5 (/) X-Scan-Signature: 69ad46fbd0e474a7c7f3312d9e320336 Subject: [Mobopts] Re: Re: Performance and Policy : Inter-technology mobility policy control X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Rajeev & All, I am interested to explore Inter-technology mobility field for research. Infact i was looking at Inter System (technology) handover issue since quite some time. Can you throw some light on the same? Thanks. Shardul Thaker Research Intern Bell Labs India -----Original Message----- From: mobopts-request@irtf.org [mailto:mobopts-request@irtf.org] Sent: Monday, June 19, 2006 9:30 PM To: mobopts@irtf.org Subject: Mobopts Digest, Vol 25, Issue 10 Send Mobopts mailing list submissions to mobopts@irtf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/mobopts or, via email, send a message with subject or body 'help' to mobopts-request@irtf.org You can reach the person managing the list at mobopts-owner@irtf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Mobopts digest..." Today's Topics: 1. Re: Performance and Policy (Telemaco Melia) 2. Re: Re: [Mip6] MIP and Upper Layer Protocol interaction (Shinta Sugimoto) 3. Preliminary Call for Papers: MobiArch 2006 (Xiaoming Fu) 4. Re: Performance and Policy (James Kempf) ---------------------------------------------------------------------- Message: 1 Date: Sun, 18 Jun 2006 18:23:43 +0200 From: Telemaco Melia Subject: Re: [Mobopts] Performance and Policy To: Rajeev Koodli Cc: mobopts@irtf.org Message-ID: <44957E0F.10207@netlab.nec.de> Content-Type: text/plain; charset=UTF-8; format=flowed Hi all, Here go some first ideas. Feedback is welcome. Requirements: ========== - Unified model for both network side and terminal side - Network mainly interested in: + performance optimization (vertical handovers) + roaming across boundaries (inter domain handovers) + network controlled and network initiated handovers - (Multi mode) Terminal interested in: + Keep best connectivity (depending on radio conditions...) + Receive via multiple interfaces (multihoming, multiple bindings...) o management of flows o soft handover might be more suitable + Power saving (imagine a device with HSDPA, Wimax mobile and WLAN) o not at MAC level, rather as a policy + Influence on mobility of less volatile information such as context (applications) If people are interested I could come up with a fews slides elaborating the above. What do you think? regards, telemaco Rajeev Koodli wrote: > Vijay Devarapallli wrote: > >> On 6/6/06, Rajeev Koodli wrote: >> >>> Another topic that comes to mind is policy. Inter-technology >>> mobility is >>> subject >>> to policy controls when crossing provider boundaries. Yet, I am not >>> sure we are paying enough attention to policy when designing for >>> performance. >> >> >> I am very interested in this topic. I have been working on this >> recently. >> let me know if you need someone to write up a problem statement. >> > I like the idea of putting together a document. We should dedicate > some time > in Montreal for this topic. > In the meanwhile, what are the issues? Let's discuss on the ML. > > -Rajeev > >> Vijay > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts -- Telemaco Melia telemaco.melia@netlab.nec.de Research Staff Member Tel: +49 (0) 6221 4342- 142 Network Laboratories Fax: +49 (0) 6221 4342- 155 NEC Europe Ltd. Web: http://netlab.nec.de Kurfrsten-Anlage 36 D-69115 Heidelberg Germany ------------------------------ Message: 2 Date: Mon, 19 Jun 2006 10:38:19 +0300 From: Shinta Sugimoto Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction To: Rajeev Koodli Cc: mip6@ietf.org, Vijay Devarapalli , mobopts@irtf.org Message-ID: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset="US-ASCII" Hi Rajeev, I am catching up on this thread. Please find my comments inline. On Wed, 07 Jun 2006 10:13:06 -0700 Rajeev Koodli wrote: > Vijay Devarapalli wrote: > > > Rajeev Koodli wrote: > > > >> If a MN wishes to change its HoA with a CN (e.g., use a different > >> pseudo-hoa for > >> privacy purposes), it has no _reliable_ way of knowing whether it has > >> existing sessions with that CN. > > > > > > I read this paragraph three times, but couldn't get > > the context. > > > > if in the privacy context, I assume there is still > > a *real* HoA. the pseudo HoA appears in the route > > optimized traffic to the CN *instead* of the real > > HoA. the CN knows the real HoA and the pseudo HoA. > > the mapping from the real HoA to the pseudo HoA is > > done using the binding update list at the MN and > > the binding cache entry at the CN. > > > This is a way to do it. Nevertheless, keeping the privacy issue aside.. > > > if not for privacy, perhaps the mobile node shouldn't > > change its HoA abruptly, but let existing sessions > > continue with the existing HoA and use the new HoA > > for new sessions. the mobile node would also have > > to update the DNS entry if it wants its FQDN to > > resolve to the new HoA. > > > The problem here is how does the MN know to "let the > existing sessions continue with the existing HoA"? If there is no CN's > address in BUL, surely the MN can choose a suitable HoA. For > a CN with which it has a binding, it has no reliable way of knowing > whether there are any ULP sessions. If you need to maintain the sessions while changing the HoA from one to another, I think you need additional mechanism than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed to assure the reachability to a given HoA with the current location of the mobile node (CoA). If the app wants to change HoAs for some reason (I assume that privacy is the main interest), there is a need to maintain the mapping of the identity and the locator of the mobile node. One option would be to run Shim6 over MIPv6. Such usage has already been discussed in Shim6 WG. By mobile node establishing Shim6 context with its HA/CN, it could utilize multiple HoAs without annoying upper layer protocols. However, I am not sure if it fulfills your requirement especially in terms of privacy (hiding the identity, which is MN's HoA in this case). Would you see any problem with this approach ? I see that signaling overhead may also be a concern (to run both Shim6 and MIPv6). I have some additional questions: - If privacy is the main concern, would you think http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt would help to solve your initial requirement ? If not, could you please tell me why ? - Do you assume that different HoAs that mobile node may request are derived from different home prefixes ? Or are you considering that the node generates HoAs from a single prefix with privacy extension ? Regards, Shinta ------------------------------ Message: 3 Date: Mon, 19 Jun 2006 16:28:32 +0200 From: Xiaoming Fu Subject: [Mobopts] Preliminary Call for Papers: MobiArch 2006 To: hipsec-rg@listserv.cybertrust.com, mobopts@irtf.org Message-ID: <4496B490.40800@cs.uni-goettingen.de> Content-Type: text/plain; charset=windows-1252; format=flowed Dear colleagues, Please find below the preliminary call for papers for MobiArch'06 workshop. Our appologizes if you receive multiple copies. Best regards, Xiaoming Fu -------------------------------------------------------------------- The First IEEE/ACM* International Workshop on Mobility in the Evolving Internet Architecture (MobiArch 2006) held in conjunction with IEEE GLOBECOM 2006, San Francisco, CA, USA, November/December 2006 http://user.informatik.uni-goettingen.de/~mobiarch/ (* - IEEE/ACM sponsorship pending approval) -------------------------------------------------------------------- E-mail contact : mobiarch@cs.uni-goettingen.de CFP in printable pdf format can be downloaded in http://user.informatik.uni-goettingen.de/~mobiarch/Cfp_MobiArch06.pdf Scope: ===== With the recent development of technologies in wireless access and mobile devices, terminal and network mobility have become an indispensable component of today's Internet vision, and this is likely to continue in the near future, while affecting the way of the whole Internet architecture design. Yet, issues like efficient mobility management and optimizations, locator-identifier split, multi-homing, security and related operational/deployment concerns are still in their early stages of development. Moreover, the Internet architecture, its end-to-end principles and business models will require rethinking due to the massive penetration of mobility into the Internet. The MobiArch'06 workshop solicits papers, both from researchers and practitioners, dealing with architectures, protocols, and experiences with emerging technologies on mobility support in the Internet, with an emphasis on new mobility protocols, mobility and location management, mobile network performance, multi-homing, security, architectural impacts and deployment considerations. The workshop will include presentations and discussions of accepted technical papers, as well as invited talks and panel sessions. Topics of Interest: ================== Original contributions are solicited in all aspects of architectural issues and system support for mobility in the Internet, including but not limited to: - Mobility impact on the Internet architecture - Architectures and protocols for mobility support in the Internet, ranging from approaches in link layer, network, transport to session/application layers and cross-layer design - Locator/identifier split, multihoming and load sharing issues - Security and privacy issues in mobility networks and impacts to Internet architecture - QoS and middlebox issues in mobility networks and impacts to Internet architecture - Economic and deployment issues of mobility infrastructure designs Submissions: =========== Submissions should be made to MobiArch'06 EDAS entry: http://edas.info/4920, following the guidelines in MobiArch'06 webpage: http://user.informatik.uni-goettingen.de/~mobiarch/ Important Dates: =============== Submission Deadline: Monday, July 24, 2006 Acceptance Notification: August 31, 2006 Camera-ready version due: September 27, 2006 Workshop: One-day in GLOBECOM 2006 (to be announced) GLOBECOM Main Conference: November 27-December 1, 2006 GENERAL CHAIR ============= Jon Crowcroft, U. Cambridge (UK) PROGRAM CO-CHAIRS ================= Xiaoming Fu, U. Goettingen (DE) Katherine Guo, Bell Labs (US) PROGRAM COMMITTEE ================= Jari Arkko, Ericsson (FI) Raouf Boutaba, U. Waterloo (CA) Jon Crowcroft, U. Cambridge (UK) Wesley Eddy, NASA/Verizon (US) Xiaoming Fu, U. Goettingen (DE) Ivano Guardini, Telecom Italia Lab (IT) Katherine Guo, Bell Labs (US) Dieter Hogrefe, U. Goettingen (DE) Yuming Jiang, NTNU (NO) Cornelia Kappler, Siemens (DE) Ben Liang, U. Toronto (CA) Meng How Lim, Intel Research Cambridge (UK) John Loughney, Nokia Research Center (FI) Joerg Ott, Helsinki U of Techology (FI) Charles Perkins, Nokia Research Center (US) Christian Prehofer, Nokia Research Center (FI) Henning Schulzrinne, Columbia U. (US) Hannes Tschofenig, Siemens (DE) Zhi-Li Zhang, U. Minnesoda (US) Taieb Znati, U. Pittsburg/NSF (US) -------------------------------------------------------------------- For more information: http://user.informatik.uni-goettingen.de/~mobiarch/ ------------------------------ Message: 4 Date: Mon, 19 Jun 2006 08:30:31 -0700 From: "James Kempf" Subject: Re: [Mobopts] Performance and Policy To: "Telemaco Melia" , "Rajeev Koodli" Cc: mobopts@irtf.org Message-ID: <05e401c693b5$4d0e1510$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response "Soft handover" is a L2 technique only. If it is in use, the IP layer never sees the outstanding hanodever legs. I think you mean "make before break" handover, in which the terminal gets data plane packets via the old leg while configuring on the new AP via the new. jak ----- Original Message ----- From: "Telemaco Melia" To: "Rajeev Koodli" Cc: Sent: Sunday, June 18, 2006 9:23 AM Subject: Re: [Mobopts] Performance and Policy > Hi all, > > Here go some first ideas. Feedback is welcome. > > Requirements: > ========== > - Unified model for both network side and terminal side > > - Network mainly interested in: > + performance optimization (vertical handovers) > + roaming across boundaries (inter domain handovers) > + network controlled and network initiated handovers > > - (Multi mode) Terminal interested in: > + Keep best connectivity (depending on radio conditions...) > + Receive via multiple interfaces (multihoming, multiple bindings...) > o management of flows > o soft handover might be more suitable > + Power saving (imagine a device with HSDPA, Wimax mobile and WLAN) > o not at MAC level, rather as a policy > + Influence on mobility of less volatile information such as context > (applications) > > If people are interested I could come up with a fews slides elaborating > the above. > What do you think? > > regards, > telemaco > > > Rajeev Koodli wrote: >> Vijay Devarapallli wrote: >> >>> On 6/6/06, Rajeev Koodli wrote: >>> >>>> Another topic that comes to mind is policy. Inter-technology mobility >>>> is >>>> subject >>>> to policy controls when crossing provider boundaries. Yet, I am not >>>> sure we are paying enough attention to policy when designing for >>>> performance. >>> >>> >>> I am very interested in this topic. I have been working on this >>> recently. >>> let me know if you need someone to write up a problem statement. >>> >> I like the idea of putting together a document. We should dedicate some >> time >> in Montreal for this topic. >> In the meanwhile, what are the issues? Let's discuss on the ML. >> >> -Rajeev >> >>> Vijay >> >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts > > > -- > Telemaco Melia telemaco.melia@netlab.nec.de > Research Staff Member Tel: +49 (0) 6221 4342- 142 > Network Laboratories Fax: +49 (0) 6221 4342- 155 > NEC Europe Ltd. Web: http://netlab.nec.de > Kurfrsten-Anlage 36 > D-69115 Heidelberg > Germany > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > ------------------------------ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts End of Mobopts Digest, Vol 25, Issue 10 *************************************** _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 20 03:38:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsaoy-00034u-Hg; Tue, 20 Jun 2006 03:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsaow-00034l-9g for mobopts@irtf.org; Tue, 20 Jun 2006 03:38:46 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsaoC-0000Wj-Sz for mobopts@irtf.org; Tue, 20 Jun 2006 03:38:46 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1F8954D8AE; Tue, 20 Jun 2006 16:37:54 +0900 (JST) Date: Tue, 20 Jun 2006 10:37:53 +0300 From: Shinta Sugimoto To: Vijay Devarapalli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <44973D7B.6030109@azairenet.com> References: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> <44973D7B.6030109@azairenet.com> Message-Id: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Vijay, please find my comments inline. On Mon, 19 Jun 2006 17:12:43 -0700 Vijay Devarapalli wrote: > Shinta Sugimoto wrote: > >> The problem here is how does the MN know to "let the > >> existing sessions continue with the existing HoA"? If there is no CN's > >> address in BUL, surely the MN can choose a suitable HoA. For > >> a CN with which it has a binding, it has no reliable way of knowing > >> whether there are any ULP sessions. > > > > If you need to maintain the sessions while changing the HoA > > from one to another, I think you need additional mechanism > > than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed > > to assure the reachability to a given HoA with the current > > location of the mobile node (CoA). If the app wants > > to change HoAs for some reason (I assume that privacy is the > > main interest), there is a need to maintain the mapping of > > the identity and the locator of the mobile node. > > Mobile IPv6 today allows you to use two home addresses > at the same time. it also allows you to bind both home > addresses to the same CoA. Yes, that's true. But then there is a problem to choose which one for which communication. When it comes to agility, it's more problematic. > > One option would be to run Shim6 over MIPv6. Such usage has > > already been discussed in Shim6 WG. By mobile node establishing > > Shim6 context with its HA/CN, it could utilize multiple HoAs > > without annoying upper layer protocols. > > yes, this can be done. but I would like to restrict > shim6 usage when mip6 is used to the case where the > home link is site multihomed and the mobile node already > has the multiple home addresses configured on it. not > when the mobile node decides to change its home address. I think it depends on motivation whether it makes sense to apply Shim6 here. Utilizing Shim6 would allow HoA agility (from ULP point of view). OTOH, Shim6 (in the current form) does not take privacy into consideration very much, actually. So if the motivation is to achieve location privacy (not allowing third party to learn the binding), I think that we may probably need something else. > > > I have some additional questions: > > > > - If privacy is the main concern, would you think > > http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt > > would help to solve your initial requirement ? If not, could > > you please tell me why ? > > I think its orthogonal. the use of pseudo-HoA instead > of the actual HoA is also being worked on in mobopts. I've read the solution draft from the mobopts and it seems to me that both draft try to achieve the same goal. > > - Do you assume that different HoAs that mobile node may > > request are derived from different home prefixes ? Or are you > > considering that the node generates HoAs from a single prefix > > with privacy extension ? > > I think its the same prefix, but I guess its better if > Rajeev clarifies. Ok, it seems so (HoAs are derived from same prefix). Regards, Shinta _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 20 04:00:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsbAK-0005nG-Ka; Tue, 20 Jun 2006 04:00:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsbAJ-0005mo-56 for mobopts@irtf.org; Tue, 20 Jun 2006 04:00:51 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsb9c-0003xG-Ie for mobopts@irtf.org; Tue, 20 Jun 2006 04:00:51 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id AFB464D8CA; Tue, 20 Jun 2006 17:00:04 +0900 (JST) Date: Tue, 20 Jun 2006 11:00:01 +0300 From: Shinta Sugimoto To: Rajeev Koodli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <44974B6A.6060709@iprg.nokia.com> References: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> <44974B6A.6060709@iprg.nokia.com> Message-Id: <20060620103743.AA20.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip6@ietf.org, Vijay Devarapalli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Rajeev, please find my comments/questions inline. On Mon, 19 Jun 2006 21:12:10 -0400 Rajeev Koodli wrote: > > Hi, > > the purpose here is to list the available options. Perhaps SHIM6 is > one option, but there are others to explore. Ok, I see. > I encourage you to > discuss them at the MobOpts meeting. Yes. > > -Rajeev > > ps: location privacy as such is being discussed in a problem statement > draft, and there is also a mobopts drfat on solutions. Please have a look > at them. Thanks. Thanks for the information. I've just read the ps and solution drafts. Still I am not quite sure if I understand the exact issue being discussed on this thread. Is the issue 1) how to identify correspondent node with whom the mobile node already established a sessoin based on a given HoA, or 2) how to provide HoA agility when the mobile node changes it's HoA from one to another (for privacy reason), or both ? Regards, Shinta _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 20 06:44:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdiv-0005ia-Tn; Tue, 20 Jun 2006 06:44:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdiv-0005iQ-C7 for mobopts@irtf.org; Tue, 20 Jun 2006 06:44:45 -0400 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsdis-0001WT-NK for mobopts@irtf.org; Tue, 20 Jun 2006 06:44:45 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5KAiZwi021250 for ; Tue, 20 Jun 2006 18:44:35 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5KAiY11021233 for ; Tue, 20 Jun 2006 18:44:34 +0800 (SGT) Received: from mailbe01.teak.local.net ([192.122.134.10]) by mailhost.lit.org.sg (Sun Java System Messaging Server 6.1 HotFix 0.06 (built Nov 11 2004)) with ESMTP id <0J1500BMLN6C6R10@mailhost.lit.org.sg> for mobopts@irtf.org; Tue, 20 Jun 2006 18:44:37 +0800 (SGT) Received: from mailfe01.teak.local.net ([192.122.134.9]) by mailbe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 18:44:17 +0800 Received: from D8ZXLJ1S ([192.168.137.186]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 18:44:16 +0800 Date: Tue, 20 Jun 2006 18:44:50 +0800 From: QIU Ying Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction To: Shinta Sugimoto , Rajeev Koodli Message-id: <05c001c69456$8ea368d0$ba89a8c0@D8ZXLJ1S> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> <20060620103743.AA20.SHINTA@sfc.wide.ad.jp> X-OriginalArrivalTime: 20 Jun 2006 10:44:16.0786 (UTC) FILETIME=[7A602F20:01C69456] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mip6@ietf.org, Vijay Devarapalli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, Shinta My cents is also inline. >> ps: location privacy as such is being discussed in a problem statement >> draft, and there is also a mobopts drfat on solutions. Please have a look >> at them. Thanks. > > Thanks for the information. I've just read the ps and solution drafts. Thanks for your attention on the drafts. > > Still I am not quite sure if I understand the exact issue being > discussed on this thread. Is the issue 1) how to identify correspondent > node with whom the mobile node already established a sessoin based on a > given HoA, In MIPv6, after receiving a BU message from MN, the CN check it BU cache. If no entry about the MN, CN create a new entry for the MN. In other word, if there is the MN entry in BU cache, it means the MN has already established a connection. Of course, the entry is not for a specifical session only, it is for the connection between two peers. >or 2) how to provide HoA agility when the mobile node changes > it's HoA from one to another (for privacy reason), or both ? a pseudo HoA is used to replace the actual HoA. pseudo home address = one of home network prefix || Enc(Kph_i, interface ID) More detail please refer to our new version that should be online by the weekend. Regards and Thanks Qiu Ying > > > Regards, > Shinta > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts ------------ Institute For Infocomm Research - Disclaimer ------------- This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you. -------------------------------------------------------- _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 20 07:14:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FseBN-0004Vw-EE; Tue, 20 Jun 2006 07:14:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FseBM-0004VS-0W for mobopts@irtf.org; Tue, 20 Jun 2006 07:14:08 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fse9q-00039n-UQ for mobopts@irtf.org; Tue, 20 Jun 2006 07:14:07 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CF3724D8AF; Tue, 20 Jun 2006 20:12:30 +0900 (JST) Date: Tue, 20 Jun 2006 14:12:27 +0300 From: Shinta Sugimoto To: QIU Ying Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <05c001c69456$8ea368d0$ba89a8c0@D8ZXLJ1S> References: <20060620103743.AA20.SHINTA@sfc.wide.ad.jp> <05c001c69456$8ea368d0$ba89a8c0@D8ZXLJ1S> Message-Id: <20060620135048.AA2C.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mip6@ietf.org, mobopts@irtf.org, Rajeev Koodli , Vijay Devarapalli X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Ying, please find my comments below. On Tue, 20 Jun 2006 18:44:50 +0800 QIU Ying wrote: >=20 > Hi, Shinta >=20 > My cents is also inline. >=20 > >> ps: location privacy as such is being discussed in a problem statement > >> draft, and there is also a mobopts drfat on solutions. Please have a l= ook > >> at them. Thanks. > > > > Thanks for the information. I've just read the ps and solution drafts. >=20 > Thanks for your attention on the drafts. > > > > Still I am not quite sure if I understand the exact issue being > > discussed on this thread. Is the issue 1) how to identify corresponden= t > > node with whom the mobile node already established a sessoin based on a > > given HoA, >=20 > In MIPv6, after receiving a BU message from MN, the CN check it BU cache.= If=20 > no entry about the MN, CN create a new entry for the MN. In other word, i= f=20 > there is the MN entry in BU cache, it means the MN has already establishe= d a=20 > connection. I assume, you are referring to a binding association between the MN and CN by the "connection" in above sentence. > Of course, the entry is not for a specifical session only, it is=20 > for the connection between two peers. Yes. =46rom MN's perspective (also from CN's perspective), it's quite obvious if there has already been a binding association established with a given CN or not, from its BUL (in case of CN, it can be found in BC as you said). What I meant by 1) is how can the MN identify with which CN, it has one or more TCP session which is based on its HoA. Note that I am *not* asking if it's possible or not (I think it's possible, BTW), but I am clarifying if it's the issue being discussed on this thread or not. >=20 > >or 2) how to provide HoA agility when the mobile node changes > > it's HoA from one to another (for privacy reason), or both ? >=20 > a pseudo HoA is used to replace the actual HoA. > pseudo home address =3D one of home network prefix || Enc(Kph_i, interfac= e ID) Ok. > More detail please refer to our new version that should be online by the= =20 > weekend. Ok, thanks. Will check that. Regards, Shinta _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 20 13:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskN4-0002y6-Oa; Tue, 20 Jun 2006 13:50:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskN3-0002x0-4n for mobopts@irtf.org; Tue, 20 Jun 2006 13:50:37 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskJl-00053R-3G for mobopts@irtf.org; Tue, 20 Jun 2006 13:47:14 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 10:47:12 -0700 Message-ID: <4498342D.2030708@azairenet.com> Date: Tue, 20 Jun 2006 10:45:17 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <7EB20EA0938B4D42A2D82689365C9B7A04F95A@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04F95A@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 17:47:12.0185 (UTC) FILETIME=[8F4ACA90:01C69491] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Soliman, Hesham wrote: > > > One option would be to run Shim6 over MIPv6. Such usage has > > > already been discussed in Shim6 WG. By mobile node establishing > > > Shim6 context with its HA/CN, it could utilize multiple HoAs > > > without annoying upper layer protocols. > > > > yes, this can be done. but I would like to restrict > > shim6 usage when mip6 is used to the case where the > > home link is site multihomed and the mobile node already > > has the multiple home addresses configured on it. not > > when the mobile node decides to change its home address. > > => There is no difference between the two scenarios. your reply is too cryptic. when shim6 is used, one cannot start using another address without first adding that address to the list of addresses that the HA/CN need to be aware of (basically add to the shim6 state). also, if both home addresses are from the same prefix, shim6 shouldn't be used. if the home link is multihomed and the mobile node has multiple home addresses from the different prefixes, then shim6 is applicable. ofcourse, one can do all this with shim6, but then quoting you "shim6 is trying to solve world hunger". ;) (hope you don't mind it). Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 20 13:56:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskSG-0006hQ-7m; Tue, 20 Jun 2006 13:56:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskSE-0006hB-QQ for mobopts@irtf.org; Tue, 20 Jun 2006 13:55:58 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskSE-0006aU-8I for mobopts@irtf.org; Tue, 20 Jun 2006 13:55:58 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 10:55:57 -0700 Message-ID: <4498363E.4050702@azairenet.com> Date: Tue, 20 Jun 2006 10:54:06 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shinta Sugimoto Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> <44973D7B.6030109@azairenet.com> <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 17:55:57.0270 (UTC) FILETIME=[C8446760:01C69492] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Shinta Sugimoto wrote: >> >>>>The problem here is how does the MN know to "let the >>>>existing sessions continue with the existing HoA"? If there is no CN's >>>>address in BUL, surely the MN can choose a suitable HoA. For >>>>a CN with which it has a binding, it has no reliable way of knowing >>>>whether there are any ULP sessions. >>> >>>If you need to maintain the sessions while changing the HoA >>>from one to another, I think you need additional mechanism >>>than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed >>>to assure the reachability to a given HoA with the current >>>location of the mobile node (CoA). If the app wants >>>to change HoAs for some reason (I assume that privacy is the >>>main interest), there is a need to maintain the mapping of >>>the identity and the locator of the mobile node. >> >>Mobile IPv6 today allows you to use two home addresses >>at the same time. it also allows you to bind both home >>addresses to the same CoA. > > > Yes, that's true. But then there is a problem to choose > which one for which communication. When it comes to agility, > it's more problematic. actually we are not looking for address agility here. we want the mobile node to change its home address and while changing it allow existing sessions using the old home address to continue and start using the new home address for new sessions. not sure if shim6 addresses this. >>>One option would be to run Shim6 over MIPv6. Such usage has >>>already been discussed in Shim6 WG. By mobile node establishing >>>Shim6 context with its HA/CN, it could utilize multiple HoAs >>>without annoying upper layer protocols. >> >>yes, this can be done. but I would like to restrict >>shim6 usage when mip6 is used to the case where the >>home link is site multihomed and the mobile node already >>has the multiple home addresses configured on it. not >>when the mobile node decides to change its home address. > > > I think it depends on motivation whether it makes sense > to apply Shim6 here. Utilizing Shim6 would allow HoA agility > (from ULP point of view). see above. >>>I have some additional questions: >>> >>>- If privacy is the main concern, would you think >>>http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt >>>would help to solve your initial requirement ? If not, could >>>you please tell me why ? >> >>I think its orthogonal. the use of pseudo-HoA instead >>of the actual HoA is also being worked on in mobopts. > > > I've read the solution draft from the mobopts > > and it seems to me that both draft try to achieve the same goal. there were a bunch of solution drafts on mip6 privacy (I think four of them). draft-irtf-mobopts-location-privacy-solutions-01.txt, is trying to come up with one solution. >>>- Do you assume that different HoAs that mobile node may >>>request are derived from different home prefixes ? Or are you >>>considering that the node generates HoAs from a single prefix >>>with privacy extension ? >> >>I think its the same prefix, but I guess its better if >>Rajeev clarifies. > > Ok, it seems so (HoAs are derived from same prefix). see my reply to Hesham. Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 20 19:29:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FspfR-0000j7-P2; Tue, 20 Jun 2006 19:29:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FspfQ-0000iw-AW for mobopts@irtf.org; Tue, 20 Jun 2006 19:29:56 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FspfO-00087L-PB for mobopts@irtf.org; Tue, 20 Jun 2006 19:29:56 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J16009HWMLSXK@mailout3.samsung.com> for mobopts@irtf.org; Wed, 21 Jun 2006 08:29:52 +0900 (KST) Received: from daniellaptop ([124.235.139.4]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J1600FGRMLQI8@mmp2.samsung.com> for mobopts@irtf.org; Wed, 21 Jun 2006 08:29:52 +0900 (KST) Date: Wed, 21 Jun 2006 08:29:51 +0900 From: Soohong Daniel Park To: mobopts@irtf.org Message-id: <034601c694c1$6e94c3c0$bd01640a@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ternli@ietf.org Subject: [Mobopts] Fw: I-D ACTION:draft-korhonen-mobopts-delivery-analysis-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org FYI. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: To: Sent: Wednesday, June 21, 2006 7:50 AM Subject: I-D ACTION:draft-korhonen-mobopts-delivery-analysis-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Link and Path Characteristic Information Delivery Analysis > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-mobopts-delivery-analysis-00.txt > Pages : 19 > Date : 2006-6-20 > > This document analyses capabilities and applicability of various IP > Mobility, signaling and transport protocols for delivering Link and > Path Characteristic Information between communicating end points. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-mobopts-delivery-analysis-00.txt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 21 04:29:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsy5l-0004GM-MU; Wed, 21 Jun 2006 04:29:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsy5l-0004GH-3o for mobopts@irtf.org; Wed, 21 Jun 2006 04:29:41 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsy5h-0006o0-Nt for mobopts@irtf.org; Wed, 21 Jun 2006 04:29:41 -0400 Received: by nf-out-0910.google.com with SMTP id c2so54412nfe for ; Wed, 21 Jun 2006 01:29:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CT1TzKGDrqWbxP5YgHcRF1j+LCcAQ5QhrpqZd4TdDTrAe2P2zq3piYGMR5bwdk5VgmMg3ZPH7LYaTM49iiyKYEckrK2eFB4fueq53woFovJtfqOs7gsarmg39nr6jFPUz16EQ7BLG+8ZJ8ib6LTaOZcMG8puncLHdxaYHKnD8Sc= Received: by 10.49.59.5 with SMTP id m5mr323302nfk; Wed, 21 Jun 2006 01:29:36 -0700 (PDT) Received: by 10.48.241.18 with HTTP; Wed, 21 Jun 2006 01:29:36 -0700 (PDT) Message-ID: <36cb7a210606210129n4aeb910am8f9f0c6a51290368@mail.gmail.com> Date: Wed, 21 Jun 2006 18:29:36 +1000 From: "Henrik Petander" To: "Rajeev Koodli" Subject: Re: [Mobopts] Presentation requests In-Reply-To: <4491B527.20605@iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4491B527.20605@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henrik.petander@iki.fi List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Rajeev, I would like to present a draft on an extension for Fast Mobile IPv6, SafetyNet which addresses the packet duplication and data transmission overhead issues in bicasting. The draft is available at : http://users.tkk.fi/~lpetande/drafts/draft-petander-safetynet-00.txt I would like 10 minutes for the presentation. We have an implementation of the draft and some experimental results on the performance effects of the selective delivery. Abstract - "More and more mobile nodes are being equipped with multiple radios, such as 3G and 802.11. This document specifies SafetyNet, an extension to Fast Handovers for Mobile IPv6 (RFC 4068) which takes advantage of the additional capabilities of these Mobile Nodes. Similarly to Simultaneous Bindings for Fast Handovers, the SafetyNet extension uses bicasting to allow a Mobile Node to continue receiving packets directly from the Previous Access Router during the handoff process. In addition, the SafetyNet extension numbers the packets to enable the New Access Router to only deliver those packets from its buffer that the Mobile Node has not already received directly from the Previous Access Router. This reduces the overhead of bicasting and eliminates the receiving of duplicate packets at the Mobile Node which may improve TCP performance." Regards, Henrik Petander On 6/16/06, Rajeev Koodli wrote: > > Hello folks, > > please let me know if you would like to present at Montreal as soon as > possible. Provide > > o title of your talk > o URL to relevant document > o time needed > > I am planning to have discussion on MIP - ULP interaction and > Performance and Policy topics as well. > > Regards, > > -Rajeev > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 21 06:15:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fszjg-0002xf-0o; Wed, 21 Jun 2006 06:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fszje-0002xa-Sz for mobopts@irtf.org; Wed, 21 Jun 2006 06:14:58 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsziL-0002HC-2L for mobopts@irtf.org; Wed, 21 Jun 2006 06:14:58 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 32EE34CE7A; Wed, 21 Jun 2006 19:13:32 +0900 (JST) Date: Wed, 21 Jun 2006 13:13:34 +0300 From: Shinta Sugimoto To: Vijay Devarapalli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <4498363E.4050702@azairenet.com> References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <4498363E.4050702@azairenet.com> Message-Id: <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Vijay, please find my further comments inline. On Tue, 20 Jun 2006 10:54:06 -0700 Vijay Devarapalli wrote: > Shinta Sugimoto wrote: > > >> > >>>>The problem here is how does the MN know to "let the > >>>>existing sessions continue with the existing HoA"? If there is no CN's > >>>>address in BUL, surely the MN can choose a suitable HoA. For > >>>>a CN with which it has a binding, it has no reliable way of knowing > >>>>whether there are any ULP sessions. > >>> > >>>If you need to maintain the sessions while changing the HoA > >>>from one to another, I think you need additional mechanism > >>>than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed > >>>to assure the reachability to a given HoA with the current > >>>location of the mobile node (CoA). If the app wants > >>>to change HoAs for some reason (I assume that privacy is the > >>>main interest), there is a need to maintain the mapping of > >>>the identity and the locator of the mobile node. > >> > >>Mobile IPv6 today allows you to use two home addresses > >>at the same time. it also allows you to bind both home > >>addresses to the same CoA. > > > > > > Yes, that's true. But then there is a problem to choose > > which one for which communication. When it comes to agility, > > it's more problematic. > > actually we are not looking for address agility here. we want > the mobile node to change its home address and while changing > it allow existing sessions using the old home address to > continue and start using the new home address for new sessions. I see. Now I understand that address agility is not the main issue here. If I understand the above correctly, the issue is more about how to handle pseudo-HoA especially for correspondents of the mobile node, and how to minimize the impact to the existing communication. Now I have another question. Looking into the solution draft (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me that a pseudo-HoA is derived from mobile node's home prefix and it is actually a globally unique IPv6 address. If I understand the role of pseudo-HoA correctly, it aims to serve as a tag to locate the real HoA for the MN. If so, I am afraid that it may not be necessary to generate a pseudo-HoA in form of IPv6 address. In particular, there is no need to contain the home prefix which could be of interest for an eavesdropper to identify the mobile node. Am I missing something ? > not sure if shim6 addresses this. AFAICT, Shim6 does not provide any exact solution for this particular issue. However, there has been privacy analysis made for Shim6 (see Marcelo's draft for detail). http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-privacy-00.txt But in general, I think the requirements and prerequisite for the privacy are a bit different in MIPv6 and Shim6. > > >>>One option would be to run Shim6 over MIPv6. Such usage has > >>>already been discussed in Shim6 WG. By mobile node establishing > >>>Shim6 context with its HA/CN, it could utilize multiple HoAs > >>>without annoying upper layer protocols. > >> > >>yes, this can be done. but I would like to restrict > >>shim6 usage when mip6 is used to the case where the > >>home link is site multihomed and the mobile node already > >>has the multiple home addresses configured on it. not > >>when the mobile node decides to change its home address. > > > > > > I think it depends on motivation whether it makes sense > > to apply Shim6 here. Utilizing Shim6 would allow HoA agility > > (from ULP point of view). > > see above. > > >>>I have some additional questions: > >>> > >>>- If privacy is the main concern, would you think > >>>http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt > >>>would help to solve your initial requirement ? If not, could > >>>you please tell me why ? > >> > >>I think its orthogonal. the use of pseudo-HoA instead > >>of the actual HoA is also being worked on in mobopts. > > > > > > I've read the solution draft from the mobopts > > > > and it seems to me that both draft try to achieve the same goal. > > there were a bunch of solution drafts on mip6 privacy (I > think four of them). draft-irtf-mobopts-location-privacy-solutions-01.txt, > is trying to come up with one solution. Ok. Thanks for the clarification. > > >>>- Do you assume that different HoAs that mobile node may > >>>request are derived from different home prefixes ? Or are you > >>>considering that the node generates HoAs from a single prefix > >>>with privacy extension ? > >> > >>I think its the same prefix, but I guess its better if > >>Rajeev clarifies. > > > > Ok, it seems so (HoAs are derived from same prefix). > > see my reply to Hesham. Ok. Regards, Shinta _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 21 13:36:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6dO-0005Ic-Ic; Wed, 21 Jun 2006 13:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6dN-0005IO-7X for mobopts@irtf.org; Wed, 21 Jun 2006 13:36:57 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6dL-0005Sk-U3 for mobopts@irtf.org; Wed, 21 Jun 2006 13:36:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Date: Wed, 21 Jun 2006 10:36:52 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Thread-Index: AcaUkZjsu/9iQGBqRYCAAKL6E3yXaQAj6qtgAA3nIiA= From: "Vijay Devarapalli" To: "Soliman, Hesham" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org > > > =3D> There is no difference between the two scenarios.=20 > >=20 > > your reply is too cryptic. > >=20 > > when shim6 is used, one cannot start using another address > > without first adding that address to the list of addresses > > that the HA/CN need to be aware of (basically add to the > > shim6 state). >=20 > =3D> Of course, which is doable in both scenarios. >=20 > >=20 > > also, if both home addresses are from the same prefix, > > shim6 shouldn't be used.=20 > ^^^^^^^^^ > =3D> that's your opinion, but the point is it can be used just as = easily > whether it's the same prefix or a different one. It actually=20 > makes sense > to use on solution for both cases. >=20 >=20 > if the home link is multihomed > > and the mobile node has multiple home addresses from the > > different prefixes, then shim6 is applicable. >=20 > =3D> It's applicable in both cases, you want to use it in one case.=20 yes. in my first reply to Shinta, I had said, I=20 _would like_ to restrict the use of shim6 when MIP6 is used to the scenario when the home link is multihomed. this is one of the reasons why folks are still=20 confused about the role of shim6 (see recent=20 discussion on the shim6 mailing list).=20 Vijay >=20 > Hesham >=20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 21 18:03:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAmw-0007T7-BA; Wed, 21 Jun 2006 18:03:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAmv-0007Sx-8Z for mobopts@irtf.org; Wed, 21 Jun 2006 18:03:05 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAmt-0003Ex-TX for mobopts@irtf.org; Wed, 21 Jun 2006 18:03:05 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 15:02:57 -0700 Message-ID: <4499C19F.3050707@azairenet.com> Date: Wed, 21 Jun 2006 15:01:03 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shinta Sugimoto Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <4498363E.4050702@azairenet.com> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 22:02:57.0857 (UTC) FILETIME=[74704310:01C6957E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Shinta Sugimoto wrote: >>>>>>The problem here is how does the MN know to "let the >>>>>>existing sessions continue with the existing HoA"? If there is no CN's >>>>>>address in BUL, surely the MN can choose a suitable HoA. For >>>>>>a CN with which it has a binding, it has no reliable way of knowing >>>>>>whether there are any ULP sessions. >>>>> >>>>>If you need to maintain the sessions while changing the HoA >>>> >>>>>from one to another, I think you need additional mechanism >>>> >>>>>than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed >>>>>to assure the reachability to a given HoA with the current >>>>>location of the mobile node (CoA). If the app wants >>>>>to change HoAs for some reason (I assume that privacy is the >>>>>main interest), there is a need to maintain the mapping of >>>>>the identity and the locator of the mobile node. >>>> >>>>Mobile IPv6 today allows you to use two home addresses >>>>at the same time. it also allows you to bind both home >>>>addresses to the same CoA. >>> >>> >>>Yes, that's true. But then there is a problem to choose >>>which one for which communication. When it comes to agility, >>>it's more problematic. >> >>actually we are not looking for address agility here. we want >>the mobile node to change its home address and while changing >>it allow existing sessions using the old home address to >>continue and start using the new home address for new sessions. > > > I see. Now I understand that address agility is not the main > issue here. If I understand the above correctly, the issue > is more about how to handle pseudo-HoA especially for correspondents > of the mobile node, and how to minimize the impact to the > existing communication. its not even about privacy. its about the mobile node deciding to change home addresses, while minimizing impact on existing sessions. new sessions would be started with the new HoA. for a short period there will be two home addresses with some sessions based on the old HoA and some on the new HoA. > Now I have another question. Looking into the solution draft > (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me > that a pseudo-HoA is derived from mobile node's home prefix > and it is actually a globally unique IPv6 address. If I understand > the role of pseudo-HoA correctly, it aims to serve as a tag to > locate the real HoA for the MN. If so, I am afraid that it may > not be necessary to generate a pseudo-HoA in form of IPv6 address. > In particular, there is no need to contain the home prefix which > could be of interest for an eavesdropper to identify the mobile > node. Am I missing something ? I would actually wait for version 02, which should be out next week before we discuss further. I wasn't very happy with version 01. regarding the pseudo-HoA, it can be any 128 bit value. does not have to have the home prefix. Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 21 18:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtBK6-0003qB-DX; Wed, 21 Jun 2006 18:37:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtBK5-0003q1-9S for mobopts@irtf.org; Wed, 21 Jun 2006 18:37:21 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtADz-0007Rf-0E for mobopts@irtf.org; Wed, 21 Jun 2006 17:26:59 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtA0B-0006D1-8k for mobopts@irtf.org; Wed, 21 Jun 2006 17:12:47 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LLCcHp010351; Thu, 22 Jun 2006 00:12:40 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 00:12:38 +0300 Received: from [127.0.0.1] ([10.241.161.123]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Jun 2006 00:12:36 +0300 Message-ID: <4499B639.8050200@iprg.nokia.com> Date: Wed, 21 Jun 2006 17:12:25 -0400 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: henrik.petander@iki.fi Subject: Re: [Mobopts] Presentation requests References: <4491B527.20605@iprg.nokia.com> <36cb7a210606210129n4aeb910am8f9f0c6a51290368@mail.gmail.com> In-Reply-To: <36cb7a210606210129n4aeb910am8f9f0c6a51290368@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 21:12:37.0374 (UTC) FILETIME=[6C1721E0:01C69577] X-Spam-Score: -2.6 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Noted. Regards, -Rajeev Henrik Petander wrote: > Hi Rajeev, > > I would like to present a draft on an extension for Fast Mobile IPv6, > SafetyNet which addresses the packet duplication and data transmission > overhead issues in bicasting. > > The draft is available at : > http://users.tkk.fi/~lpetande/drafts/draft-petander-safetynet-00.txt > > I would like 10 minutes for the presentation. We have an > implementation of the draft and some experimental results on the > performance effects of the selective delivery. > > Abstract - "More and more mobile nodes are being equipped with > multiple radios, such as 3G and 802.11. This document specifies > SafetyNet, an extension to Fast Handovers for Mobile IPv6 (RFC 4068) > which takes advantage of the additional capabilities of these Mobile > Nodes. Similarly to Simultaneous Bindings for Fast Handovers, the > SafetyNet extension uses bicasting to allow a Mobile Node to continue > receiving packets directly from the Previous Access Router during the > handoff process. In addition, the SafetyNet extension numbers the > packets to enable the New Access Router to only deliver those packets > from its buffer that the Mobile Node has not already received directly > from the Previous Access Router. This reduces the overhead of > bicasting and eliminates the receiving of duplicate packets at the > Mobile Node which may improve TCP performance." > > Regards, > Henrik Petander > > On 6/16/06, Rajeev Koodli wrote: > >> >> Hello folks, >> >> please let me know if you would like to present at Montreal as soon as >> possible. Provide >> >> o title of your talk >> o URL to relevant document >> o time needed >> >> I am planning to have discussion on MIP - ULP interaction and >> Performance and Policy topics as well. >> >> Regards, >> >> -Rajeev >> >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts >> _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 22 00:39:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGyx-0003Pv-IZ; Thu, 22 Jun 2006 00:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGyw-0003Pq-6Q for mobopts@irtf.org; Thu, 22 Jun 2006 00:39:54 -0400 Received: from otm-mgo00.iij.ad.jp ([210.138.20.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtGyu-0005Ln-IB for mobopts@irtf.org; Thu, 22 Jun 2006 00:39:54 -0400 Received: OTM-MO(otm-mgo00) id k5M4dgDw083890; Thu, 22 Jun 2006 13:39:42 +0900 (JST) Received: OTM-MIX(otm-mix01) id k5M4dgm1091383; Thu, 22 Jun 2006 13:39:42 +0900 (JST) Received: from [192.168.64.81] (n064-h081-dhcp.osaka.iij.ad.jp [192.168.64.81]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp) id k5M4dfXl003473 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 22 Jun 2006 13:39:42 +0900 (JST) In-Reply-To: <4499C19F.3050707@azairenet.com> References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <4498363E.4050702@azairenet.com> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <4499C19F.3050707@azairenet.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69816405-8861-4B68-B9DA-6E133DFB4E73@iijlab.net> Content-Transfer-Encoding: 7bit From: Keiichi SHIMA Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Date: Thu, 22 Jun 2006 13:39:44 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi all, On 2006/06/22, at 7:01, Vijay Devarapalli wrote: > Shinta Sugimoto wrote: > >>>>>>> The problem here is how does the MN know to "let the >>>>>>> existing sessions continue with the existing HoA"? If there >>>>>>> is no CN's >>>>>>> address in BUL, surely the MN can choose a suitable HoA. For >>>>>>> a CN with which it has a binding, it has no reliable way of >>>>>>> knowing >>>>>>> whether there are any ULP sessions. >>>>>> >>>>>> If you need to maintain the sessions while changing the HoA >>>>> >>>>>> from one to another, I think you need additional mechanism >>>>> >>>>>> than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed >>>>>> to assure the reachability to a given HoA with the current >>>>>> location of the mobile node (CoA). If the app wants >>>>>> to change HoAs for some reason (I assume that privacy is the >>>>>> main interest), there is a need to maintain the mapping of >>>>>> the identity and the locator of the mobile node. >>>>> >>>>> Mobile IPv6 today allows you to use two home addresses >>>>> at the same time. it also allows you to bind both home >>>>> addresses to the same CoA. >>>> >>>> >>>> Yes, that's true. But then there is a problem to choose >>>> which one for which communication. When it comes to agility, >>>> it's more problematic. >>> >>> actually we are not looking for address agility here. we want >>> the mobile node to change its home address and while changing >>> it allow existing sessions using the old home address to >>> continue and start using the new home address for new sessions. >> I see. Now I understand that address agility is not the main >> issue here. If I understand the above correctly, the issue >> is more about how to handle pseudo-HoA especially for correspondents >> of the mobile node, and how to minimize the impact to the >> existing communication. > > its not even about privacy. its about the mobile node deciding > to change home addresses, while minimizing impact on existing > sessions. new sessions would be started with the new HoA. for > a short period there will be two home addresses with some > sessions based on the old HoA and some on the new HoA. What does 'minimizing impact on sessions'? Does it mean session continuity? Then, I have a simple question that why do we need to provide session continuity when home address changes? A home address is the identifier of the end node. If it changed, then the sessions related to the identifier should be terminated. If we can change from one home address to another home address, then why do we need Mobile IP? Or does the discussion is for a new mobility mechanism other than MIP based? # or I am misunderstanding...? --- Keiichi SHIMA IIJ Research Laboratory WIDE Project _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 22 07:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtN3e-0002Qf-Ie; Thu, 22 Jun 2006 07:09:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtN3d-0002QX-Co for mobopts@irtf.org; Thu, 22 Jun 2006 07:09:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtN3d-0004C0-A6 for mobopts@irtf.org; Thu, 22 Jun 2006 07:09:09 -0400 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtN3Z-0002eo-Sw for mobopts@irtf.org; Thu, 22 Jun 2006 07:09:09 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5MB8r9M025651 for ; Thu, 22 Jun 2006 19:08:53 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5MB8qWh025633 for ; Thu, 22 Jun 2006 19:08:53 +0800 (SGT) Received: from mailbe01.teak.local.net ([192.122.134.10]) by mailhost.lit.org.sg (Sun Java System Messaging Server 6.1 HotFix 0.06 (built Nov 11 2004)) with ESMTP id <0J1900MVFDMY9P10@mailhost.lit.org.sg> for mobopts@irtf.org; Thu, 22 Jun 2006 19:08:58 +0800 (SGT) Received: from mailfe01.teak.local.net ([192.122.134.9]) by mailbe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 19:08:39 +0800 Received: from D8ZXLJ1S ([192.168.137.186]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 19:08:39 +0800 Date: Thu, 22 Jun 2006 19:09:13 +0800 From: QIU Ying Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction To: Keiichi SHIMA , Vijay Devarapalli Message-id: <091901c695ec$4b251620$ba89a8c0@D8ZXLJ1S> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <69816405-8861-4B68-B9DA-6E133DFB4E73@iijlab.net> X-OriginalArrivalTime: 22 Jun 2006 11:08:39.0107 (UTC) FILETIME=[36D02930:01C695EC] X-Spam-Score: -2.6 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, all, My comments is at the bottom. a long quotation. ----- Original Message ----- From: "Keiichi SHIMA" To: "Vijay Devarapalli" Cc: ; "Rajeev Koodli" ; Sent: Thursday, June 22, 2006 12:39 PM Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction > Hi all, > > On 2006/06/22, at 7:01, Vijay Devarapalli wrote: > >> Shinta Sugimoto wrote: >> >>>>>>>> The problem here is how does the MN know to "let the >>>>>>>> existing sessions continue with the existing HoA"? If there is no >>>>>>>> CN's >>>>>>>> address in BUL, surely the MN can choose a suitable HoA. For >>>>>>>> a CN with which it has a binding, it has no reliable way of >>>>>>>> knowing >>>>>>>> whether there are any ULP sessions. >>>>>>> >>>>>>> If you need to maintain the sessions while changing the HoA >>>>>> >>>>>>> from one to another, I think you need additional mechanism >>>>>> >>>>>>> than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed >>>>>>> to assure the reachability to a given HoA with the current >>>>>>> location of the mobile node (CoA). If the app wants >>>>>>> to change HoAs for some reason (I assume that privacy is the >>>>>>> main interest), there is a need to maintain the mapping of >>>>>>> the identity and the locator of the mobile node. >>>>>> >>>>>> Mobile IPv6 today allows you to use two home addresses >>>>>> at the same time. it also allows you to bind both home >>>>>> addresses to the same CoA. >>>>> >>>>> >>>>> Yes, that's true. But then there is a problem to choose >>>>> which one for which communication. When it comes to agility, >>>>> it's more problematic. >>>> >>>> actually we are not looking for address agility here. we want >>>> the mobile node to change its home address and while changing >>>> it allow existing sessions using the old home address to >>>> continue and start using the new home address for new sessions. >>> I see. Now I understand that address agility is not the main >>> issue here. If I understand the above correctly, the issue >>> is more about how to handle pseudo-HoA especially for correspondents >>> of the mobile node, and how to minimize the impact to the >>> existing communication. >> >> its not even about privacy. its about the mobile node deciding >> to change home addresses, while minimizing impact on existing >> sessions. new sessions would be started with the new HoA. for >> a short period there will be two home addresses with some >> sessions based on the old HoA and some on the new HoA. > > What does 'minimizing impact on sessions'? Does it mean session > continuity? Yes. > Then, I have a simple question that why do we need to provide session > continuity when home address changes? A home address is the identifier > of the end node. Yes, it is the key point. In normal MIP6, the identity HoA is always bound with CoA. However, for the privacy reason, we must break the relationship CoA and HoA in an eavesdropper perspective. It is why we need change the HoA. In fact, to change the HoA does means to change the owner, it just change the ones mask. > If it changed, then the sessions related to the identifier should be > terminated. If we can change from one home address to another home > address, then why do we need Mobile IP? Home address indicate the owner of the CoA. MN is not able to get a packet with HoA as the destination address. Mobile IP ensure the direct connection between MN and CN. > Or does the discussion is for a new mobility mechanism other than MIP > based? It follows the mechanism of RFC3775 and 3776. Regards Qiu Ying > > # or I am misunderstanding...? > > > --- > Keiichi SHIMA > IIJ Research Laboratory > WIDE Project > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts ------------ Institute For Infocomm Research - Disclaimer ------------- This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you. -------------------------------------------------------- _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 22 07:31:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNPV-0004pU-Dy; Thu, 22 Jun 2006 07:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNPU-0004p2-5v for mobopts@irtf.org; Thu, 22 Jun 2006 07:31:44 -0400 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNPR-0005n5-Jh for mobopts@irtf.org; Thu, 22 Jun 2006 07:31:44 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5MBVUGu029079 for ; Thu, 22 Jun 2006 19:31:30 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5MBVUNp029062 for ; Thu, 22 Jun 2006 19:31:30 +0800 (SGT) Received: from mailbe01.teak.local.net ([192.122.134.10]) by mailhost.lit.org.sg (Sun Java System Messaging Server 6.1 HotFix 0.06 (built Nov 11 2004)) with ESMTP id <0J1900M1YEON9P20@mailhost.lit.org.sg> for mobopts@irtf.org; Thu, 22 Jun 2006 19:31:35 +0800 (SGT) Received: from mailfe01.teak.local.net ([192.122.134.9]) by mailbe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 19:31:16 +0800 Received: from D8ZXLJ1S ([192.168.137.186]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 19:31:16 +0800 Date: Thu, 22 Jun 2006 19:31:50 +0800 From: QIU Ying Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction To: Vijay Devarapalli , Shinta Sugimoto Message-id: <091e01c695ef$744c07e0$ba89a8c0@D8ZXLJ1S> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <4499C19F.3050707@azairenet.com> X-OriginalArrivalTime: 22 Jun 2006 11:31:16.0620 (UTC) FILETIME=[5FF434C0:01C695EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, Shinta and Vijay I skip some old quotation for easy read >> Now I have another question. Looking into the solution draft >> (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me >> that a pseudo-HoA is derived from mobile node's home prefix >> and it is actually a globally unique IPv6 address. If I understand >> the role of pseudo-HoA correctly, it aims to serve as a tag to >> locate the real HoA for the MN. If so, I am afraid that it may >> not be necessary to generate a pseudo-HoA in form of IPv6 address. RFC3775 requires that option/routing address must be a routable address. So a random number as the destination option is not acceptable. >> In particular, there is no need to contain the home prefix which >> could be of interest for an eavesdropper to identify the mobile >> node. Am I missing something ? So we need multi home prefix to generate the psuedo HoA to delude the eavesdroppers. The reason of the psuedo HoA with home prefix is that the psuedo HoA in both HoTI/HoT and BU must be the same, while the HoT must be routed to the home agent. > I would actually wait for version 02, which should be out next > week before we discuss further. I wasn't very happy with > version 01. Hope the version 02 do not disappoint you :-) Regards Qiu Ying > regarding the pseudo-HoA, it can be any 128 bit value. does > not have to have the home prefix. > > Vijay > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts ------------ Institute For Infocomm Research - Disclaimer ------------- This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you. -------------------------------------------------------- _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 22 08:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVl-0007RH-2J; Thu, 22 Jun 2006 08:42:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVd-0007Fd-J4 for mobopts@irtf.org; Thu, 22 Jun 2006 08:42:09 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOQ6-0000Yk-5R for mobopts@irtf.org; Thu, 22 Jun 2006 08:37:20 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 72E554CC4D; Thu, 22 Jun 2006 21:36:18 +0900 (JST) Date: Thu, 22 Jun 2006 15:36:20 +0300 From: Shinta Sugimoto To: QIU Ying Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <091e01c695ef$744c07e0$ba89a8c0@D8ZXLJ1S> References: <4499C19F.3050707@azairenet.com> <091e01c695ef$744c07e0$ba89a8c0@D8ZXLJ1S> Message-Id: <20060622150758.AA71.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mip6@ietf.org, mobopts@irtf.org, Rajeev Koodli X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Ying, Thanks for your clarification. Please find my comments inline. On Thu, 22 Jun 2006 19:31:50 +0800 QIU Ying wrote: > > Hi, Shinta and Vijay > > I skip some old quotation for easy read > > >> Now I have another question. Looking into the solution draft > >> (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me > >> that a pseudo-HoA is derived from mobile node's home prefix > >> and it is actually a globally unique IPv6 address. If I understand > >> the role of pseudo-HoA correctly, it aims to serve as a tag to > >> locate the real HoA for the MN. If so, I am afraid that it may > >> not be necessary to generate a pseudo-HoA in form of IPv6 address. > > RFC3775 requires that option/routing address must be a routable address. So > a random number as the destination option is not acceptable. Correct. And it's mainly for security reason. RH2 and HAO DSTOPT are MIPv6 specific, and they are processed only by the final destination. So, in order to extend the MIPv6 protocol for privacy support, I think exceptionional cases shall be made. And I am afraid that the version 01 actually suggests to include encrypted HoA E(Kbm, HoA) in the HAO destination option, doesn't it ? > > >> In particular, there is no need to contain the home prefix which > >> could be of interest for an eavesdropper to identify the mobile > >> node. Am I missing something ? > > So we need multi home prefix to generate the psuedo HoA to delude the > eavesdroppers. I am sorry, but I failed to understand why multiple home prefix is needed to achieve the goal (privacy). Could you please elaborate ? > The reason of the psuedo HoA with home prefix is that the > psuedo HoA in both HoTI/HoT and BU must be the same, while the HoT must be > routed to the home agent. Could you please explain why does the draft suggest to modify the way of CN trasmitting HoT to the MN ? In plain MIPv6, HoT is sent by the CN to the MN's HoA (to be set as the destination address). Then we can expect that the HoT message is protected by the IPsec tunnel established between the MN and HA. Is there any problem with that ? > > > I would actually wait for version 02, which should be out next > > week before we discuss further. I wasn't very happy with > > version 01. > > Hope the version 02 do not disappoint you :-) No, I am not disappointed at all, it's an interesting draft. Regards, Shinta _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 22 09:27:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtPD1-0005Ul-Qd; Thu, 22 Jun 2006 09:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtPD0-0005UU-Hp for mobopts@irtf.org; Thu, 22 Jun 2006 09:26:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtJhy-0005WQ-AG for mobopts@irtf.org; Thu, 22 Jun 2006 03:34:34 -0400 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtJSz-0007DR-21 for mobopts@irtf.org; Thu, 22 Jun 2006 03:19:06 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 91A364CE7E; Thu, 22 Jun 2006 16:18:56 +0900 (JST) Date: Thu, 22 Jun 2006 10:18:59 +0300 From: Shinta Sugimoto To: Vijay Devarapalli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <4499C19F.3050707@azairenet.com> References: <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <4499C19F.3050707@azairenet.com> Message-Id: <20060622100958.AA6B.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org On Wed, 21 Jun 2006 15:01:03 -0700 Vijay Devarapalli wrote: > Shinta Sugimoto wrote: > > >>>>>>The problem here is how does the MN know to "let the > >>>>>>existing sessions continue with the existing HoA"? If there is no CN's > >>>>>>address in BUL, surely the MN can choose a suitable HoA. For > >>>>>>a CN with which it has a binding, it has no reliable way of knowing > >>>>>>whether there are any ULP sessions. > >>>>> > >>>>>If you need to maintain the sessions while changing the HoA > >>>> > >>>>>from one to another, I think you need additional mechanism > >>>> > >>>>>than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed > >>>>>to assure the reachability to a given HoA with the current > >>>>>location of the mobile node (CoA). If the app wants > >>>>>to change HoAs for some reason (I assume that privacy is the > >>>>>main interest), there is a need to maintain the mapping of > >>>>>the identity and the locator of the mobile node. > >>>> > >>>>Mobile IPv6 today allows you to use two home addresses > >>>>at the same time. it also allows you to bind both home > >>>>addresses to the same CoA. > >>> > >>> > >>>Yes, that's true. But then there is a problem to choose > >>>which one for which communication. When it comes to agility, > >>>it's more problematic. > >> > >>actually we are not looking for address agility here. we want > >>the mobile node to change its home address and while changing > >>it allow existing sessions using the old home address to > >>continue and start using the new home address for new sessions. > > > > > > I see. Now I understand that address agility is not the main > > issue here. If I understand the above correctly, the issue > > is more about how to handle pseudo-HoA especially for correspondents > > of the mobile node, and how to minimize the impact to the > > existing communication. > > its not even about privacy. its about the mobile node deciding > to change home addresses, while minimizing impact on existing > sessions. new sessions would be started with the new HoA. for > a short period there will be two home addresses with some > sessions based on the old HoA and some on the new HoA. If I understand it correctly, upper layer protocol continue to use *same* HoA even if the pseudo-HoA is changed, right ? Pseudo-HoA that appears in RH2/HAO is expected to be updated accordingly. So, I am afraid that "changing HoA" is a bit misleading explanation in this case. > > > Now I have another question. Looking into the solution draft > > (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me > > that a pseudo-HoA is derived from mobile node's home prefix > > and it is actually a globally unique IPv6 address. If I understand > > the role of pseudo-HoA correctly, it aims to serve as a tag to > > locate the real HoA for the MN. If so, I am afraid that it may > > not be necessary to generate a pseudo-HoA in form of IPv6 address. > > In particular, there is no need to contain the home prefix which > > could be of interest for an eavesdropper to identify the mobile > > node. Am I missing something ? > > I would actually wait for version 02, which should be out next > week before we discuss further. I wasn't very happy with > version 01. Ok, let's wait for the next version of the solution draft then resume discussion. > > regarding the pseudo-HoA, it can be any 128 bit value. does > not have to have the home prefix. Ok. Regards, Shinta _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 22 13:24:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSuX-0001xb-Pe; Thu, 22 Jun 2006 13:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSuW-0001sZ-9v for mobopts@irtf.org; Thu, 22 Jun 2006 13:24:08 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSuU-00022l-WD for mobopts@irtf.org; Thu, 22 Jun 2006 13:24:08 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 10:24:05 -0700 Message-ID: <449AD1BC.9070606@azairenet.com> Date: Thu, 22 Jun 2006 10:22:04 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <4498363E.4050702@azairenet.com> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <4499C19F.3050707@azairenet.com> <69816405-8861-4B68-B9DA-6E133DFB4E73@iijlab.net> In-Reply-To: <69816405-8861-4B68-B9DA-6E133DFB4E73@iijlab.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2006 17:24:05.0096 (UTC) FILETIME=[A9594E80:01C69620] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Keiichi SHIMA wrote: >> its not even about privacy. its about the mobile node deciding >> to change home addresses, while minimizing impact on existing >> sessions. new sessions would be started with the new HoA. for >> a short period there will be two home addresses with some >> sessions based on the old HoA and some on the new HoA. > > > What does 'minimizing impact on sessions'? Does it mean session > continuity? just let the sessions on the old HoA continue for a while (not forever though). > Then, I have a simple question that why do we need to provide session > continuity when home address changes? A home address is the identifier > of the end node. If it changed, then the sessions related to the > identifier should be terminated. thats one option. another option is to let the use of old HoA and the new HoA for a while. > If we can change from one home > address to another home address, then why do we need Mobile IP? > > Or does the discussion is for a new mobility mechanism other than MIP > based? > > # or I am misunderstanding...? we need to go back to the original mail from Rajeev and figure out what problem we are trying to solve. this thread has been too long. :) Vijay _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jun 22 17:27:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWiT-0002Nr-58; Thu, 22 Jun 2006 17:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWiQ-0002Nm-J0 for mobopts@irtf.org; Thu, 22 Jun 2006 17:27:54 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtWiP-0005ti-4B for mobopts@irtf.org; Thu, 22 Jun 2006 17:27:54 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MLRb7m017175; Fri, 23 Jun 2006 00:27:38 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 00:27:37 +0300 Received: from [127.0.0.1] ([10.241.53.137]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Jun 2006 00:27:37 +0300 Message-ID: <449B0B43.8020202@iprg.nokia.com> Date: Thu, 22 Jun 2006 17:27:31 -0400 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <4498363E.4050702@azairenet.com> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <4499C19F.3050707@azairenet.com> <69816405-8861-4B68-B9DA-6E133DFB4E73@iijlab.net> <449AD1BC.9070606@azairenet.com> In-Reply-To: <449AD1BC.9070606@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2006 21:27:37.0436 (UTC) FILETIME=[AEFB71C0:01C69642] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip6@ietf.org, Keiichi SHIMA , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Vijay Devarapalli wrote: > >> Then, I have a simple question that why do we need to provide >> session continuity when home address changes? A home address is >> the identifier of the end node. If it changed, then the sessions >> related to the identifier should be terminated. > > > thats one option. another option is to let the use of old > HoA and the new HoA for a while. > yes, how to allow a previous HoA to be used while using a different HoA for new sessions. >> If we can change from one home address to another home address, then >> why do we need Mobile IP? >> >> Or does the discussion is for a new mobility mechanism other than >> MIP based? >> >> # or I am misunderstanding...? > > > we need to go back to the original mail from Rajeev and > figure out what problem we are trying to solve. this thread > has been too long. :) > I guess we never really ran into this issue within the realm of MIP.. However, there is no reason why you cannot use a different HoA. If you have dynamic HoA assignment which happens to take place when the MN is using a previous (dynamically assigned) HoA, you have this problem. We can argue that you can make the HoA effectively the same across the assignments, but that is not the only solution we should have. Anyway, this has been a good discussion so far. We should summarize and continue at Mobopts meeting in Montreal. Regards, -Rajeev > Vijay > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 27 19:35:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvN61-0004nY-JH; Tue, 27 Jun 2006 19:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvN60-0004mX-0l for mobopts@irtf.org; Tue, 27 Jun 2006 19:35:52 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvN5y-0003AA-JN for mobopts@irtf.org; Tue, 27 Jun 2006 19:35:51 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5RNZmWL009555 for ; Wed, 28 Jun 2006 02:35:49 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 02:35:14 +0300 Received: from [127.0.0.1] ([172.18.141.192]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jun 2006 02:35:14 +0300 Message-ID: <44A1C0AE.6000509@iprg.nokia.com> Date: Tue, 27 Jun 2006 16:35:10 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2006 23:35:14.0641 (UTC) FILETIME=[5718F410:01C69A42] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Mobopts] Montreal Agenda X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Folks, here is the agenda. 1. Introduction, document status, Rajeev, 5 minutes. 2. Performance and Policy, Vijay Devarapalli, 20 minutes 3. MIP - ULP interaction, summary, Vijay Devarapalli/Rajeev, 20 minutes 4. Network-Initiated Handovers, Performance and Policy, Telemaco Melia, 15 minutes 5. Transport protocol performance during mobility, Ryuji Wakikawa, 15 minutes 6. Link Characteristics Information conveyance, Jouni Korhonen, 15 minutes 7. SafetyNet, Henrik Petander, 15 minutes 8. Location Privacy Solution update, Rajeev, 15 minutes 9. Multicast and Mobility problem Statement update, Rajeev, 10 minutes. Regards, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jun 27 19:39:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvN95-0007K5-GI; Tue, 27 Jun 2006 19:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvN94-0007K0-VZ for mobopts@irtf.org; Tue, 27 Jun 2006 19:39:02 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvN93-0003u5-HM for mobopts@irtf.org; Tue, 27 Jun 2006 19:39:02 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5RNcvfd019698 for ; Wed, 28 Jun 2006 02:39:00 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 02:38:58 +0300 Received: from [127.0.0.1] ([172.18.141.192]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jun 2006 02:38:58 +0300 Message-ID: <44A1C18E.5080003@iprg.nokia.com> Date: Tue, 27 Jun 2006 16:38:54 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2006 23:38:58.0492 (UTC) FILETIME=[DC85E7C0:01C69A42] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Mobopts] MobOpts Dinner X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Continuing the practice.. I would like to have it on Wednesday evening after the plenary, say at 8 pm. Please let me know if you would like to attend. If you know of good places, please suggest. -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jun 28 10:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbSY-0002yM-Os; Wed, 28 Jun 2006 10:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbSX-0002uC-4z for mobopts@irtf.org; Wed, 28 Jun 2006 10:56:05 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvbSU-0008VP-Ly for mobopts@irtf.org; Wed, 28 Jun 2006 10:56:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3CCCD20031DD; Wed, 28 Jun 2006 16:56:23 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08448-03; Wed, 28 Jun 2006 16:56:23 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1BF1620031DC; Wed, 28 Jun 2006 16:56:23 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 16:56:01 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id EBD6612B3A8; Wed, 28 Jun 2006 16:56:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) To: ternli@ietf.org, tsvwg@ietf.org, int-area@ietf.org, mobopts@irtf.org, iccrg Message-Id: References: From: Lars Eggert Date: Wed, 28 Jun 2006 16:55:59 +0200 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Jun 2006 14:56:01.0836 (UTC) FILETIME=[F8FDE6C0:01C69AC2] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Subject: [Mobopts] Fwd: 66th IETF - TERNLI BOF Cancelled X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0891648176==" Errors-To: mobopts-bounces@irtf.org --===============0891648176== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17--746815637; protocol="application/pkcs7-signature" --Apple-Mail-17--746815637 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: IETF Agenda > Date: June 28, 2006 4:24:42 PM GMT+02:00 > To: IETF Announcement list > Subject: 66th IETF - TERNLI BOF Cancelled > > The TERNLI BOF session scheduled for Monday at 1520-1720 has been > cancelled. > > BOF preparations were much more elaborate than initially estimated, > due to the > complex problem space that this BOF targeted. Because a poor BOF is > worse than > no BOF, the organizers have decided to postpone TERNLI until the > San Diego > meeting. This will give the interested parties more time to prepare > for a > successful session. > > In order to attract additional people interested in this topic, the > Montreal > TSVAREA and INTAREA meetings will have a short talk on the overall > problem > space. > > TSV and INT ADs -- Lars Eggert NEC Network Laboratories --Apple-Mail-17--746815637 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNjI4MTQ1NTYwWjAjBgkqhkiG9w0BCQQxFgQUWDVt8YoJtssNbxM2CJ8Z p96J5UowgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAHd981/FmML9eahdQT2WHktlDBpk/npQDShPgkl6qBYuE3bSQIEGBeMCYAcTE8HL2qGqJc5P fParcNJ7lrng2+WF2lyCKmREHnXVlpbrN+IVFiHaeRARbdC3K/fd3xBtBGl08GnZGXLo0KlvqFhJ aOG0OFcAap+olzbSK+QfIm/XLw0vGEne0Kyfi3c+Rn/Ni5lskAYvXgTH7pEZrnxkhm/kEU1f3F2o i0hJdA9zILz357lkzlFrvxCG/f5RURev1yb800owTE2AU05n/VItN+yr7cvmpvAHv+uRy6Sl1++l Hmbiyqusox110MskNwvS3P8TfNYdOVivMayZbSU2kOsAAAAAAAA= --Apple-Mail-17--746815637-- --===============0891648176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0891648176==-- From mobopts-bounces@irtf.org Wed Jun 28 12:53:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvdIA-000643-Tu; Wed, 28 Jun 2006 12:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvdI9-00063x-JK for mobopts@irtf.org; Wed, 28 Jun 2006 12:53:29 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvdI7-0002vt-8U for mobopts@irtf.org; Wed, 28 Jun 2006 12:53:29 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DA7E320031DC; Wed, 28 Jun 2006 18:53:47 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11251-06; Wed, 28 Jun 2006 18:53:47 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C7E7720001B5; Wed, 28 Jun 2006 18:53:47 +0200 (CEST) Received: from [10.1.1.217] ([10.1.1.217]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 18:53:26 +0200 Message-ID: <44A2B406.5080703@netlab.nec.de> Date: Wed, 28 Jun 2006 18:53:26 +0200 From: Telemaco Melia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] MobOpts Dinner References: <44A1C18E.5080003@iprg.nokia.com> In-Reply-To: <44A1C18E.5080003@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2006 16:53:26.0535 (UTC) FILETIME=[5FF5A970:01C69AD3] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Rajeev Koodli wrote: > > Continuing the practice.. I would like to have it on Wednesday > evening after the plenary, say at 8 pm. > > Please let me know if you would like to attend. If you know of > good places, please suggest. > > -Rajeev > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts I ll be there. telemaco -- Telemaco Melia telemaco.melia@netlab.nec.de Research Staff Member Tel: +49 (0) 6221 4342- 142 Network Laboratories Fax: +49 (0) 6221 4342- 155 NEC Europe Ltd. Web: http://netlab.nec.de Kurfrsten-Anlage 36 D-69115 Heidelberg Germany _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts