From Marco.Liebsch@neclab.eu Wed Sep 7 08:48:46 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4E021F8D31 for ; Wed, 7 Sep 2011 08:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8kghyib3Qyz for ; Wed, 7 Sep 2011 08:48:44 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9EACC21F8D30 for ; Wed, 7 Sep 2011 08:48:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 026AE280004BE for ; Wed, 7 Sep 2011 17:50:34 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXKRR9xCDV4G for ; Wed, 7 Sep 2011 17:50:33 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id D5687280002FE for ; Wed, 7 Sep 2011 17:50:28 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.240]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 7 Sep 2011 17:50:28 +0200 From: Marco Liebsch To: "multimob@ietf.org" Thread-Topic: PMIP MC handover -- some thoughts Thread-Index: AcxtdLZMS8JkrTyaRA+5+rmiE1Vk6g== Date: Wed, 7 Sep 2011 15:50:28 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.212] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D1CE5C498DAPHNISofficehd_" MIME-Version: 1.0 Subject: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 15:48:46 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D1CE5C498DAPHNISofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, based on some discussion about multicast handover optimization during IETF8= 1 in Quebec, I have been asked to send some thoughts to the list to foster the discussion in this context. Please find below some quick thoughts and questions which I write down. You may take them into account for the PMIP MC handover discussion. Hope some of them make sense and are useful. marco - Why FHO-like forwarding between MAGs is beneficial for multicast? It puts assumptions on inter-MAG operation and introduces overhead which should be justified. - Does performance really benefit from forwarding? What's a typical use cas= e: Video broadcast, for example. Streaming applications may have some buffered packets on the player. How does packet drop during handover impact QoE compared to FHO-like forwarded MC packets? I guess they have to be buffered at the target MAG before they can be delivered to the MN, so latency is introduced whereas only packet drop is reduced. - Is packet re-ordering an issue (forwarded packets between MAGs vs direct packets)? Well, RTP may help on the player if it's used. Or is re-orderin= g resolved on the MAG by means of scheduled delivery to the MN? - Maybe CTX of multicast context is sufficient. Proactive CTX may help. Whereas the benefit of reactive CTX needs to be compared against the performance of the Multimob base approach for PMIPv6 - If forwarding between MAGs is adopted, we may consider it optional - If forwarding between MAGs is not really beneficial, what is the right wa= y for CTX? 2 approaches are being discussed: inter-MAG CTX (as per RFC4067) and CTX via LMA. Can we assume efficient paths between MAGs in operator networks? CTX via LMA puts less assumptions on SAs between MAGs and link characteristics between MAGs. In particular beneficial when LMA stores some multicast context. --_000_69756203DDDDE64E987BC4F70B71A26D1CE5C498DAPHNISofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

based on some discussion about multicast handover optimization during IETF8= 1
in Quebec, I have been asked to send some thoughts to the list to foster the discussion in this context. Please find below some quick thoughts and questions which I write down. You may take them into account for the
PMIP MC handover discussion. Hope some of them make sense and are useful.

marco

 

- Why FHO-like forwarding between MAGs is benefic= ial for multicast?
  It puts assumptions on inter-MAG operation and introduces overhead w= hich
  should be justified.

 

- Does performance really benefit from forwarding= ? What's a typical use case:
  Video broadcast, for example. Streaming applications may have some   buffered packets on the player. How does packet drop during handover=
  impact QoE compared to FHO-like forwarded MC packets? I guess they   have to be buffered at the target MAG before they can be delivered t= o
  the MN, so latency is introduced whereas only packet drop is reduced= .

 

- Is packet re-ordering an issue (forwarded packe= ts between MAGs vs direct
  packets)? Well, RTP may help on the player if it’s used. Or is= re-ordering
  resolved on the MAG by means of scheduled delivery to the MN? <= /o:p>

 

- Maybe CTX of multicast context is sufficient. P= roactive CTX may help.
  Whereas the benefit of reactive CTX needs to be compared against the=
  performance of the Multimob base approach for PMIPv6

- If forwarding between MAGs is adopted, we may c= onsider it optional


- If forwarding between MAGs is not really beneficial, what is the right wa= y for CTX?
  2 approaches are being discussed: inter-MAG CTX (as per RFC4067) and=
  CTX via LMA. Can we assume efficient paths between MAGs in operator<= br>   networks? CTX via LMA puts less assumptions on SAs between MAGs and<= br>   link characteristics between MAGs. In particular beneficial when LMA=
  stores some multicast context.

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D1CE5C498DAPHNISofficehd_-- From behcetsarikaya@yahoo.com Mon Sep 12 11:03:19 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525C221F863E for ; Mon, 12 Sep 2011 11:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njrF3yKouZs6 for ; Mon, 12 Sep 2011 11:03:18 -0700 (PDT) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by ietfa.amsl.com (Postfix) with SMTP id DA5ED21F85AE for ; Mon, 12 Sep 2011 11:03:18 -0700 (PDT) Received: from [98.139.91.67] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 12 Sep 2011 18:05:20 -0000 Received: from [98.139.91.21] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 12 Sep 2011 18:05:20 -0000 Received: from [127.0.0.1] by omp1021.mail.sp2.yahoo.com with NNFMP; 12 Sep 2011 18:05:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 544753.58951.bm@omp1021.mail.sp2.yahoo.com Received: (qmail 75685 invoked by uid 60001); 12 Sep 2011 18:05:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315850720; bh=gCedonQ3mjgf/7j8DYPsXRovx0uKJyPb/Lp316WYTGs=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=V5lf8WgQbLlI9tcK2sk7mPB0Ykc3m/mDG+cXCxKaUfIWOx3a5yPhiZDY7+q9vQZ8cKL9HlSNGLwKtmnDhe9NT/Nx5owjzU9cBWTleox4CDvhpuYoKWNFWQNJqsJ5tKplxDKF7Eq/yv7bxH+qkZP9YhZPEInCE1o4YRtWEJ0xvnQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vApvVtbP9hAOjvNkvos1ayxCDVla3yopktSPwMbPZvCzEx9Xj6IIaIIDice78ExJgGWAlboQdysmF54W0udkwr68h3vUrle1JS5Ffpz7Tq+xz1XfKfXXiKbs1B5sT+KRyKatWotucd+BX/EGVSSbufZLJGTcrCJVgQzBHfzVTt8=; X-YMail-OSG: 5EyvlRsVM1m4vadMhEz82S1LbZPk7ZcPLyQiZQCCI2RCjYw _gVAOjtq6PS2K2WgspQrAnQ0h73jQbpFcbsbsvZ6PsXBCm3zB2U0VISjLTbl czdwevN46OA0DsyPRFlIytykcrbURXZjm48cHz3xZGe4F0SAUyT0E9ASMUG2 7xiYt5KQhS6A_bd.nGJARdDcsfElAKyAjWvzh1p0oTw4fkEKJIdHI4PeBih3 ngDw2vT_C1yb8wI8uZtIoiJ3V2VTRogIIa5I.bvpa3ZoEu1Ue1mPEkYbke62 _bfZc0v7BdQKBMeB7DImnnsgVY9RuMrI5hiIhnmwwB7eQgkpDO_ivjnyuUtT FQ3o8qPd2PAfjCU0tw1hb0.TQYQLklONKeYgHSW4O0p6A7i1Vhl93JMaWdfJ 38ZbgUQdNlTCmqCNjoh9WhPFCOxRRoG4d8F9SHd1f2851VxbN7YTS4eNSF8o 2t5t9gYI- Received: from [50.58.7.243] by web111410.mail.gq1.yahoo.com via HTTP; Mon, 12 Sep 2011 11:05:20 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <20110711171426.2622.51120.idtracker@ietfa.amsl.com> Message-ID: <1315850720.75663.YahooMailNeo@web111410.mail.gq1.yahoo.com> Date: Mon, 12 Sep 2011 11:05:20 -0700 (PDT) From: Behcet Sarikaya To: "multimob@ietf.org" In-Reply-To: <20110711171426.2622.51120.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] I-D Action: draft-ietf-multimob-igmp-mld-tuning-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 18:03:19 -0000 Hi authors,=0A=0AAre there any issues left in this draft?=0AIs there a new = version in the plans?=0A=0AI don't know about MLD but IGMP has certainly be= en deployed. I think we should try to get some feedback from =0A=0AIGMP com= munity but I don't know how to do that, any ideas?=0A=0ARegards,=0A=0ABehce= t=0A=0A=0A=0A>Subject: [multimob] I-D Action: draft-ietf-multimob-igmp-mld-= tuning-01.txt=0A=0A> =0A> A New Internet-Draft is available from the on-lin= e Internet-Drafts directories. =0A> This draft is a work item of the Multic= ast Mobility Working Group of the IETF.=0A> =0A> =A0=A0=A0 Title=A0 =A0 =A0= =A0 =A0 : Tuning the Behavior of IGMP and MLD for Routers in Mobile =0A> = and Wireless Networks=0A> =A0=A0=A0 Author(s)=A0 =A0 =A0 : Hitoshi Asaeda= =0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hui Liu=0A> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Qin Wu=0A> =A0=A0=A0 Filena= me=A0 =A0 =A0 =A0 : draft-ietf-multimob-igmp-mld-tuning-01.txt=0A> =A0=A0= =A0 Pages=A0 =A0 =A0 =A0 =A0 : 18=0A> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 = =A0 : 2011-07-11=0A> =0A> =A0 IGMP and MLD are the protocols used by hosts= and multicast routers to=0A> =A0 exchange their IP multicast group member= ships with each other.=A0 This=0A> =A0 document describes the ways of IGMP= v3 and MLDv2 protocol optimization=0A> =A0 for mobility, and aims to becom= e a guideline for query and other=0A> =A0 timers and values tuning.=0A> = =0A> =0A> A URL for this Internet-Draft is:=0A> http://www.ietf.org/interne= t-drafts/draft-ietf-multimob-igmp-mld-tuning-01.txt=0A> =0A> Internet-Draft= s are also available by anonymous FTP at:=0A> ftp://ftp.ietf.org/internet-d= rafts/=0A> =0A> This Internet-Draft can be retrieved at:=0A> ftp://ftp.ietf= .org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-01.txt=0A> _______= ________________________________________=0A> multimob mailing list=0A> mult= imob@ietf.org=0A> https://www.ietf.org/mailman/listinfo/multimob=0A> From asaeda@sfc.wide.ad.jp Thu Sep 15 02:07:47 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8C21F84C3 for ; Thu, 15 Sep 2011 02:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ljE06kEG5or for ; Thu, 15 Sep 2011 02:07:47 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADBD21F84C1 for ; Thu, 15 Sep 2011 02:07:46 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:200:0:8801:129a:ddff:fe4f:16d2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D2ED02780A3; Thu, 15 Sep 2011 18:09:26 +0900 (JST) Date: Thu, 15 Sep 2011 18:09:26 +0900 (JST) Message-Id: <20110915.180926.177618042.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <1315850720.75663.YahooMailNeo@web111410.mail.gq1.yahoo.com> References: <20110711171426.2622.51120.idtracker@ietfa.amsl.com> <1315850720.75663.YahooMailNeo@web111410.mail.gq1.yahoo.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] I-D Action: draft-ietf-multimob-igmp-mld-tuning-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 09:07:47 -0000 Hi Behcet, > Are there any issues left in this draft? > Is there a new version in the plans? > > I don't know about MLD but IGMP has certainly been deployed. I think > we should try to get some feedback from > IGMP community but I don't know how to do that, any ideas? I think we need more feedback. Multimob folks, could you review this draft and give us comments? Thank you for your cooperation. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Thu Sep 15 08:57:48 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21B021F8B6B for ; Thu, 15 Sep 2011 08:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.065 X-Spam-Level: X-Spam-Status: No, score=-0.065 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_60=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKiAN-klgERT for ; Thu, 15 Sep 2011 08:57:48 -0700 (PDT) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by ietfa.amsl.com (Postfix) with SMTP id 728E721F8B65 for ; Thu, 15 Sep 2011 08:57:48 -0700 (PDT) Received: from [98.139.91.61] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 15 Sep 2011 15:59:55 -0000 Received: from [98.139.91.39] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 15 Sep 2011 15:59:55 -0000 Received: from [127.0.0.1] by omp1039.mail.sp2.yahoo.com with NNFMP; 15 Sep 2011 15:59:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 608777.44722.bm@omp1039.mail.sp2.yahoo.com Received: (qmail 78841 invoked by uid 60001); 15 Sep 2011 15:59:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1316102395; bh=tvhVO9CvP1y+e2JbSN5cZocVpeDqEMfasyaIV9Yp7mE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=Tm2z85fOIqRoxoUMX58CIK63ck+1H+wHLOGsZBAAROfulbTvVhU/0Xj2THgBCy8glP0ttJlj5PoG/UA5GmZXnXSa/IdCDd/H5kOYS78uj+9P/HOJ6T6olmny+yl59Qm1LPEkAu4KOtjwY4ydC+izBV2NRtPC/BVv0D7M8cjppCs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=umOBLTbXlcDxoLBe1l/ppzXHyPReIuhGNXUEbMWG3poMLf6kAten93cbABNu0DuvaGU+/4xaEVYUaETIYVGVnspK6I9hSk4FMG+m7jkU27n3WRzcRViwAVJ/iHZ53X6aWVFtisNuAQGqwZrUSQMU7sB0WQRbegp14JdVTddRpnI=; X-YMail-OSG: AcpQrWYVM1kXiHjvhomWbDg.wT1hREMZzlMmbvzKll_XPK3 71TSNeNXCbj.IojVadrSfYbpqSdJjrvmnRgbPHm1GffulUcMUv7Nsbjszd45 mNc85pW0tofDy3cFoR._fD6YL6l3ZJ3ozw5pVY8vpFY3fdBYFA0bYheqWN4V .by18DUYIFfDhU9qgJKG5bFMaAjdjpcC0LTAvtXNO.UhZGCzaJ_TB5LQMhzP 3hU3RwV13WuJTa__WU3A9Fbib.piX0ztbqMFdNAf.8OD1.q.7dgsp8JLyRad zp83jP__nKmjLLLGpmo3yPV1xvz_COPLm1Vd4Ileo0ep5eeL.dSYLw8WH.or hgeagxCjKp_JAhOtEGYoPn2M6ZBfDtrcgE9AlID_08WELcz4R2vKmMfyqwzt CfNnHTr9jv5CyhT.v7uQtg.asuIFrjkJ90PS7viorBpMbKVKIPNvpNBwbFW_ HtJdyQkY- Received: from [50.58.7.243] by web111415.mail.gq1.yahoo.com via HTTP; Thu, 15 Sep 2011 08:59:55 PDT X-Mailer: YahooMailWebService/0.8.113.315625 Message-ID: <1316102395.78752.YahooMailNeo@web111415.mail.gq1.yahoo.com> Date: Thu, 15 Sep 2011 08:59:55 -0700 (PDT) From: Behcet Sarikaya To: "mboned@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-881217703-595932612-1316102395=:78752" Cc: "multimob@ietf.org" Subject: [multimob] draft-ietf-multimob-igmp-mld-tuning-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 15:57:49 -0000 ---881217703-595932612-1316102395=:78752 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello Mboned Folks,=0A=A0 In Multimob we have a WG draft on tuning MLD-IGMP= in mobile environments.=0ACan you please take some time and review this do= cument and give us some good feedback?=0AYou can post your review on either= or both Mboned and Multimob lists.=0A=0ARegards,=0A=0ABehcet=0A ---881217703-595932612-1316102395=:78752 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Mboned Fol= ks,
  In Multimob we have a WG draft on tuning MLD-IGMP in m= obile environments.
Can you please take some time and review this= document and give us some good feedback?
You can post your revie= w on either or both Mboned and Multimob lists.

Reg= ards,

Behcet
---881217703-595932612-1316102395=:78752-- From Dirk.von-Hugo@telekom.de Thu Sep 22 09:52:35 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A2921F84D9 for ; Thu, 22 Sep 2011 09:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjpbPLhZVFC5 for ; Thu, 22 Sep 2011 09:52:31 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 29B8D21F8672 for ; Thu, 22 Sep 2011 09:52:30 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 22 Sep 2011 18:54:59 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.49]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 22 Sep 2011 18:54:59 +0200 From: To: , Date: Thu, 22 Sep 2011 18:54:57 +0200 Thread-Topic: PMIP MC handover -- some thoughts Thread-Index: AcxtdLZMS8JkrTyaRA+5+rmiE1Vk6gLyWhvQ Message-ID: <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A26469FFD35HE113484emea1_" MIME-Version: 1.0 Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 16:52:35 -0000 --_000_05C81A773E48DD49B181B04BA21A342A26469FFD35HE113484emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marco, thanks for your appreciated thoughts and please excuse the long silence! I think you are perfectly right that any additional effort due to messages = and interfaces between e.g. MAGs have to be evaluated vs. the gain in terms= of packet drop during handover - and whether the application scenario real= ly improves by buffering. I agree that especially for live video broadcast the introduced latency wil= l make integrity of fully delivered packets senseless. However the scenario= of a multicast download of videofiles for later viewing could gain from th= at approach (perhaps is live viewing during movement not the typical applic= ation, at least for the driver :-)). The question of degree of HO delay improvement in different CTX scenarios v= ery much depends on the topology as was already stressed at Quebec meeting.= I did some rough estimations for inter-MAG CTX and MAG-LMA CTX (aka RAMS) = compared to base multimob approach for the different scenarios: MN-MAG delay << MAG-MAG delay < MAG-LMA delay (as may be typical for curren= t 3G topologies with large delays in the core, but allowing for inter-MAG s= hortcuts): Delay/loss rate: base Multimob, proactive RAMS < inter-MAG CTX < reactive = RAMS MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for curren= t 3G topologies with large delays in the core w/o inter-MAG shortcuts): Delay/loss rate: base Multimob, proactive RAMS < reactive RAMS < inter-MAG = CTX MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in futur= e LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs communi= cate vie LMA): Delay/loss rate: base Multimob > RAMS > inter-MAG CTX Whereas in all cases the total additional signalling load is largest for in= ter-MAG CTX, whereas the load on radio access (MN-MAG) is largest for base = Multimob. Do you think the assumptions above make sense? I am currently preparing a paper on those considerations - and will share = results once they are stable for comments and suggestions. Concerning whether efficient paths between MAGs in operator networks can be= assumed IMO it depends: Whereas a direct interconnection (X2) between eNod= eBs in E-UTRAN can be assumed, MAGs may be also implemented further up in t= he network (with even more probable direct links?) ... I also agree with the existing MAG-LMA association and think a buffering at= LMA could be more beneficial (serving even more potential receivers with i= ntermediate outage ...). I think Carlos also agreed to that feature ... Let's stay in discussion. Thanks! Best regards Dirk ________________________________ Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftra= g von Marco Liebsch Gesendet: Mittwoch, 7. September 2011 17:50 An: multimob@ietf.org Betreff: [multimob] PMIP MC handover -- some thoughts Hi, based on some discussion about multicast handover optimization during IETF8= 1 in Quebec, I have been asked to send some thoughts to the list to foster the discussion in this context. Please find below some quick thoughts and questions which I write down. You may take them into account for the PMIP MC handover discussion. Hope some of them make sense and are useful. marco - Why FHO-like forwarding between MAGs is beneficial for multicast? It puts assumptions on inter-MAG operation and introduces overhead which should be justified. - Does performance really benefit from forwarding? What's a typical use cas= e: Video broadcast, for example. Streaming applications may have some buffered packets on the player. How does packet drop during handover impact QoE compared to FHO-like forwarded MC packets? I guess they have to be buffered at the target MAG before they can be delivered to the MN, so latency is introduced whereas only packet drop is reduced. - Is packet re-ordering an issue (forwarded packets between MAGs vs direct packets)? Well, RTP may help on the player if it's used. Or is re-orderin= g resolved on the MAG by means of scheduled delivery to the MN? - Maybe CTX of multicast context is sufficient. Proactive CTX may help. Whereas the benefit of reactive CTX needs to be compared against the performance of the Multimob base approach for PMIPv6 - If forwarding between MAGs is adopted, we may consider it optional - If forwarding between MAGs is not really beneficial, what is the right wa= y for CTX? 2 approaches are being discussed: inter-MAG CTX (as per RFC4067) and CTX via LMA. Can we assume efficient paths between MAGs in operator networks? CTX via LMA puts less assumptions on SAs between MAGs and link characteristics between MAGs. In particular beneficial when LMA stores some multicast context. --_000_05C81A773E48DD49B181B04BA21A342A26469FFD35HE113484emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Marco,
 
thanks for your appreciated thoughts and please = excuse=20 the long silence!
I think you are perfectly right that any additio= nal=20 effort due to messages and interfaces between e.g. MAGs have to be evaluate= d vs.=20 the gain in terms of packet drop during handover - and whether the applicat= ion=20 scenario really improves by buffering.
I agree that especially for live video broadcast= the=20 introduced latency will make integrity of fully delivered packets senseless= .=20 However the scenario of a multicast download of videofiles for later viewin= g=20 could gain from that approach (perhaps is live viewing during movement not = the=20 typical application, at least for the driver :-)).
 
The question of degree of HO delay improvement i= n=20 different CTX scenarios very much depends on the topology as was already=20 stressed at Quebec meeting. I did some rough estimations for inter-MAG CTX = and=20 MAG-LMA CTX (aka RAMS) compared to base multimob approach for the different= =20 scenarios:
 
MN-MAG delay << MAG-MAG delay < MAG-LMA= delay=20 (as may be typical for current 3G topologies with large delays in the core,= but=20 allowing for inter-MAG shortcuts):
 
Delay/loss rate: base=20 Multimob, proactive RAMS < inter-MAG CTX  <=20 reactive RAMS=20
 
MN-MAG delay << MAG-LMA delay < MAG-MAG= delay=20 (as may be typical for current 3G topologies with large delays in the core = w/o=20 inter-MAG shortcuts):
 
Delay/loss rate= :=20 base Multimob, proactive RAMS < reactive RAMS < inter-MAG= CTX=20
 
MN/MAG delay > MAG-MAG delay > MAG-LMA del= ay (as=20 could be achieved in future LTE/EPC topologies without direct inter-MAG=20 connection, i.e. MAGs communicate vie LMA):
 
Delay/loss rate: base Multimob > RAMS &g= t;=20 inter-MAG CTX
 
Whereas in all cases the total additional signal= ling=20 load is largest for inter-MAG CTX, whereas the load on radio access (MN-MAG= ) is=20 largest for base Multimob.
 
Do you think the assumptions above make=20 sense?
I am currently preparing a paper on those=20 considerations - and will share  results once they are stable=20 for comments and suggestions.
 
Concerning whether efficient paths between MAGs = in=20 operator networks can be assumed IMO it depends: Whereas a direct=20 interconnection (X2) between eNodeBs in E-UTRAN can be assumed, MAGs may be= also=20 implemented further up in the network (with even more probable direct links= ?)=20 ...
 
I also=20 agree with the existing MAG-LMA association and think a buffering at LMA co= uld=20 be more beneficial (serving even more potential receivers with intermediate= =20 outage ...). I think Carlos also agreed to that feature ...
 
Let's=20 stay in discussion.
 
Thanks!
 
Best=20 regards

Dirk

 

Von: multimob-bounces@ietf.org=20 [mailto:multimob-bounces@ietf.org] Im Auftrag von Marco=20 Liebsch
Gesendet: Mittwoch, 7. September 2011 17:50
An:= =20 multimob@ietf.org
Betreff: [multimob] PMIP MC handover -- some=20 thoughts

Hi,

based on some discussion about multicast ha= ndover=20 optimization during IETF81
in Quebec, I have been asked to send some tho= ughts=20 to the list to foster
the discussion in this context. Please find below = some=20 quick thoughts and
questions which I write down. You may take them into= =20 account for the
PMIP MC handover discussion. Hope some of them make sens= e and=20 are useful.

marco

 

- Why FHO-like forwarding between MAGs is beneficia= l for=20 multicast?
  It puts assumptions on inter-MAG operation and introdu= ces=20 overhead which
  should be justified.

 

- Does performance really benefit from forwarding? = What's=20 a typical use case:
  Video broadcast, for example. Streaming=20 applications may have some
  buffered packets on the player. How do= es=20 packet drop during handover
  impact QoE compared to FHO-like forwa= rded=20 MC packets? I guess they
  have to be buffered at the target MAG be= fore=20 they can be delivered to
  the MN, so latency is introduced whereas= only=20 packet drop is reduced.

 

- Is packet re-ordering an issue (forwarded packets= =20 between MAGs vs direct
  packets)? Well, RTP may help on the player= if=20 it’s used. Or is re-ordering
  resolved on the MAG by means o= f scheduled=20 delivery to the MN?

 

- Maybe CTX of multicast context is sufficient. Pro= active=20 CTX may help.
  Whereas the benefit of reactive CTX needs to be com= pared=20 against the
  performance of the Multimob base approach for=20 PMIPv6

- If forwarding between MAGs is adopted, we may con= sider=20 it optional


- If forwarding between MAGs is not really bene= ficial,=20 what is the right way for CTX?
  2 approaches are being discussed:= =20 inter-MAG CTX (as per RFC4067) and
  CTX via LMA. Can we assume=20 efficient paths between MAGs in operator
  networks? CTX via LMA pu= ts=20 less assumptions on SAs between MAGs and
  link characteristics bet= ween=20 MAGs. In particular beneficial when LMA
  stores some multicast=20 context.

 

 

--_000_05C81A773E48DD49B181B04BA21A342A26469FFD35HE113484emea1_-- From schmidt@informatik.haw-hamburg.de Thu Sep 22 14:05:18 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D5E1F0C87 for ; Thu, 22 Sep 2011 14:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.319 X-Spam-Level: X-Spam-Status: No, score=-102.319 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVkicC9d82tn for ; Thu, 22 Sep 2011 14:05:17 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 955EB1F0C85 for ; Thu, 22 Sep 2011 14:05:17 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231108172.adsl.alicedsl.de ([92.231.108.172] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1R6qUm-0001A3-68; Thu, 22 Sep 2011 23:07:48 +0200 Message-ID: <4E7BA3A3.5070004@informatik.haw-hamburg.de> Date: Thu, 22 Sep 2011 23:07:47 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Marco Liebsch References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 21:05:19 -0000 Hi Marco, thanks for picking this up: Context transfer in MULTIMOB should actually converge once in a while, we are discussing this since a long time. From the general perspective, context transfer is an optimization and not the base/minimal handover solution (like in unicast). Multimob is currently scheduled to do optimizations. Coming to your points, please see answers inline. On 07.09.2011 17:50, Marco Liebsch wrote: > - Why FHO-like forwarding between MAGs is beneficial for multicast? > It puts assumptions on inter-MAG operation and introduces overhead which > should be justified. > There are two assumptions here: 1. There is sufficient mutual trust relationship between MAGs to allow CTX/forwarding (typically an intra provider scenario). 2. The shortest routing distance between pMAG and nMAG is direct routing (i.e., the triangle inequality holds - typically true within a provider network). Under these assumptions, FHO-like forwarding is the fastest way of data continuity. This is the justification. > - Does performance really benefit from forwarding? What's a typical use > case: > Video broadcast, for example. Streaming applications may have some > buffered packets on the player. How does packet drop during handover > impact QoE compared to FHO-like forwarded MC packets? I guess they > have to be buffered at the target MAG before they can be delivered to > the MN, so latency is introduced whereas only packet drop is reduced. > For the video broadcast, FHO-like forwarding will reduce/diminish packet loss in the presence of buffering (as you said). I consider this an advantage over the base solution, where - depending on the signaling delay to LMA - packets may go bust. I don't understand your latency argument: Buffering at the nMAG will happen only until the MN has arrived and submitted its MLD report. This is the minimal HO delay, so no extra latency is introduced. As for other use cases: Conferencing, gaming, stock tickers (all very delay sensitive!) ... > - Is packet re-ordering an issue (forwarded packets between MAGs vs direct > packets)? Well, RTP may help on the player if it’s used. Or is re-ordering > resolved on the MAG by means of scheduled delivery to the MN? > Reordering must be acceptable by the app. for UDP data - still it is not desirable. However, UDP-based apps always need to regain order if they need it (e.g., by RTP). When comparing the two handover approaches (base vers. FHO-like) you count loss against possible reordering. > - Maybe CTX of multicast context is sufficient. Proactive CTX may help. > Whereas the benefit of reactive CTX needs to be compared against the > performance of the Multimob base approach for PMIPv6 > I see two answers: * CTX-transfer (when aligned with unicast like in the FHO-type) without forwarding is as good as the topology supports it. It is very easy to come up with all type of results (depending on various routing distances that need to be traversed for signaling). It seems like a good idea to add a "cookbook-type of evaluation" in the appendix to evaluate the benefit of forwarding. We should add this. * CTX-transfer without unicast alignment can lead to all sorts of weird results, one of which steering traffic to the wrong MAG in repeated handovers as was raised by Marshall in the last meeting. > - If forwarding between MAGs is adopted, we may consider it optional > Yes, good point -> this should go along well with the "cookbook-type of evaluation". > > - If forwarding between MAGs is not really beneficial, what is the right > way for CTX? > 2 approaches are being discussed: inter-MAG CTX (as per RFC4067) and > CTX via LMA. Can we assume efficient paths between MAGs in operator > networks? CTX via LMA puts less assumptions on SAs between MAGs and > link characteristics between MAGs. In particular beneficial when LMA > stores some multicast context. > This comes back to the initial assumptions: 1. If pMAG and nMAG both have a trust relation to the same LMA, it may be reasonable to assume a corresponding inter-MAG trust relation. 2. MAGs are access routers in a provider network ... they should allow for a direct routing on the shortest available path. Btw., for the core argument it does not really matter whether this path is "the most direct connection we can think of". All it says is "the shortest path from pMAG to nMAG" (and thats where the traffic has to move). Coming back to the CTX via LMA: This should not only always be the longer/slower way, but from my understanding the LMA is a very central entity concerned with very many MAGs / MNs. Managing the CTX via the LMA puts an additional burden onto this box (multiplied by thousands of customers), which much easier could be handled by the (less loaded) MAGs. This also is closer to the general paradigm of the Internet - where the intelligence sits at the edges, leaving the core with simple duties. So long, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Thu Sep 22 14:56:59 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58D321F8B43 for ; Thu, 22 Sep 2011 14:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-9Ds5BcZkkL for ; Thu, 22 Sep 2011 14:56:59 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id AC7C121F8A97 for ; Thu, 22 Sep 2011 14:56:58 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231108172.adsl.alicedsl.de ([92.231.108.172] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1R6rIo-0006vK-Ab; Thu, 22 Sep 2011 23:59:30 +0200 Message-ID: <4E7BAFC2.5080503@informatik.haw-hamburg.de> Date: Thu, 22 Sep 2011 23:59:30 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 21:56:59 -0000 Hi Dirk, to start first with the last: We would be very interested to see your preliminary evaluation paper and discuss results. Some more comments inline: On 22.09.2011 18:54, Dirk.von-Hugo@telekom.de wrote: > The question of degree of HO delay improvement in different CTX > scenarios very much depends on the topology as was already stressed at > Quebec meeting. I did some rough estimations for inter-MAG CTX and > MAG-LMA CTX (aka RAMS) compared to base multimob approach for the > different scenarios: > MN-MAG delay << MAG-MAG delay < MAG-LMA delay (as may be typical for > current 3G topologies with large delays in the core, but allowing for > inter-MAG shortcuts): This assumption sounds reasonable to me. > Delay/loss rate: base Multimob, proactive RAMS < inter-MAG CTX < > reactiveRAMS Delay/loss rate looks like an odd metric to me. What shall we think of a network that experiences zero delay, but little to infinite loss? What is 0/0 then? > MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for > current 3G topologies with large delays in the core w/o inter-MAG > shortcuts): More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG delay ... and "pMAG-nMAG delay =< pMAG-LMA-nMAG delay" should always hold. > MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in > future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs > communicate vie LMA): ???? I'm not an LTE expert, but as far as I know, the wireless link delay in LTE is small. I read "downlink below 1 ms". If true, this assumption seems artificial. > Do you think the assumptions above make sense? As said, some of them do, some don't. > Concerning whether efficient paths between MAGs in operator networks can > be assumed IMO it depends: Whereas a direct interconnection (X2) between > eNodeBs in E-UTRAN can be assumed, MAGs may be also implemented further > up in the network (with even more probable direct links?) ... MAGs need to be the first hop routers, so below the MAG its all L2. Personally, the worst network I can think of builds a star topology starting from LMA - still some meshing in larger provider networks seems appropriate. But you'll never know - some people sell wireless access cables on Ebay. > I also agree with the existing MAG-LMA association and think a buffering > at LMA could be more beneficial (serving even more potential receivers > with intermediate outage ...). I think Carlos also agreed to that > feature ... Buffering on the LMA means buffering in the core network. This carries the (misleading) charm that the same packets could be replayed to different MAGs/MNs. However, this is not that simple, as MNs do not behave in a synchronized fashion. Even if subscribed to the same group, each MN performs its handover at a different position in the packet flow. So the LMA would need to keep track of that (for MN X select packets Y-Z from group buffer G_X). My counter picture would see the LMA keeping individual buffers for thousands of MNs ... which looks like a case for Avici. Unfortunately, Avici is gone. Best wishes, Thomas > ------------------------------------------------------------------------ > *Von:* multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] *Im > Auftrag von *Marco Liebsch > *Gesendet:* Mittwoch, 7. September 2011 17:50 > *An:* multimob@ietf.org > *Betreff:* [multimob] PMIP MC handover -- some thoughts > > Hi, > > based on some discussion about multicast handover optimization during IETF81 > in Quebec, I have been asked to send some thoughts to the list to foster > the discussion in this context. Please find below some quick thoughts and > questions which I write down. You may take them into account for the > PMIP MC handover discussion. Hope some of them make sense and are useful. > > marco > > - Why FHO-like forwarding between MAGs is beneficial for multicast? > It puts assumptions on inter-MAG operation and introduces overhead which > should be justified. > > - Does performance really benefit from forwarding? What's a typical use > case: > Video broadcast, for example. Streaming applications may have some > buffered packets on the player. How does packet drop during handover > impact QoE compared to FHO-like forwarded MC packets? I guess they > have to be buffered at the target MAG before they can be delivered to > the MN, so latency is introduced whereas only packet drop is reduced. > > - Is packet re-ordering an issue (forwarded packets between MAGs vs direct > packets)? Well, RTP may help on the player if it’s used. Or is re-ordering > resolved on the MAG by means of scheduled delivery to the MN? > > - Maybe CTX of multicast context is sufficient. Proactive CTX may help. > Whereas the benefit of reactive CTX needs to be compared against the > performance of the Multimob base approach for PMIPv6 > > - If forwarding between MAGs is adopted, we may consider it optional > > > - If forwarding between MAGs is not really beneficial, what is the right > way for CTX? > 2 approaches are being discussed: inter-MAG CTX (as per RFC4067) and > CTX via LMA. Can we assume efficient paths between MAGs in operator > networks? CTX via LMA puts less assumptions on SAs between MAGs and > link characteristics between MAGs. In particular beneficial when LMA > stores some multicast context. > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From sarikaya2012@gmail.com Wed Sep 21 23:46:47 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9970821F8A64 for ; Wed, 21 Sep 2011 23:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGcllsj1Uozn for ; Wed, 21 Sep 2011 23:46:46 -0700 (PDT) Received: from mail-gw0-f66.google.com (mail-gw0-f66.google.com [74.125.83.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8B89221F8801 for ; Wed, 21 Sep 2011 23:46:46 -0700 (PDT) Received: by gwj16 with SMTP id 16so133709gwj.1 for ; Wed, 21 Sep 2011 23:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=A1hS3+ICnxTaB08M/dr2oUENirAbsCzvBPSzbykF/EI=; b=foR5rN6c8dnazt3AgpUcRY87iBeMlm7DOrZx5a7iLEK548X8D6m1md1Txf1IrX46Nv FgmCzvzH+GcIOwXfrJLEV83ZkmNbak3zEfrqXMzvkSUyqHJG15ZOTu8CHQXUweO6xggJ +EO5Lo+sMHtLtDX18iyLwVNwaqNjSaQ0NEYoI= MIME-Version: 1.0 Received: by 10.236.37.202 with SMTP id y50mr11030449yha.101.1316674157058; Wed, 21 Sep 2011 23:49:17 -0700 (PDT) Received: by 10.236.108.180 with HTTP; Wed, 21 Sep 2011 23:49:16 -0700 (PDT) Date: Thu, 22 Sep 2011 01:49:16 -0500 Message-ID: From: Behcet Sarikaya To: contreras.uc3m@gmail.com, cjbc@it.uc3m.es, multimob@ietf.org Content-Type: multipart/alternative; boundary=20cf303bfad46a9bab04ad8217cd Subject: [multimob] draft-contreras-multimob-rams-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 00:51:04 -0000 --20cf303bfad46a9bab04ad8217cd Content-Type: text/plain; charset=ISO-8859-1 Hi Luis, Carlos, Here are some comments on your draft: Section 3: It seems like you are defining a new option to pass the multicast state from MAG to LMA. It seems that that's all you need. Why do you have Sec. 3.2 and 3.3 then? Why not define single option with some flags and simplify this section? 3.5 active multicast subscription indication messages you defined, why do we need them? I am not convinced. Maybe there are ways of achieving the same without two new messages. Section 5: This section should be TBD because we don't know which solution will be selected. You say: the solution is applicable to the base solution. Can you clarify this by referring to the state MLD Proxy keeps at the MAG? Regards, Behcet --20cf303bfad46a9bab04ad8217cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Luis, Carlos,
=A0 Here are some comments on your draft:
Section 3:= It seems like you are defining a new option to pass the multicast state fr= om MAG to LMA.
It seems that that's all you need.
Why do you hav= e Sec. 3.2 and 3.3 then? Why not define=A0 single option with some flags an= d simplify this section?

3.5 active multicast subscription indication = messages you defined, why do we need them? I am not convinced. Maybe there = are ways of achieving the same without two new messages.

Section 5: = This section should be TBD because we don't know which solution will be= selected.
You say:
the solution=A0 is=A0 applicable to the base solution. Can you clarify this by referring to the state MLD= Proxy keeps at the MAG?

Regards,

Behcet
--20cf303bfad46a9bab04ad8217cd-- From sarikaya2012@gmail.com Thu Sep 22 18:20:34 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BF621F8BD5 for ; Thu, 22 Sep 2011 18:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPdDTpSDTVYY for ; Thu, 22 Sep 2011 18:20:33 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76B7921F8BCD for ; Thu, 22 Sep 2011 18:20:33 -0700 (PDT) Received: by gyd12 with SMTP id 12so2750056gyd.31 for ; Thu, 22 Sep 2011 18:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=Slp2BzsJd288i4EEaqTVZBQ632zwr8cJuXwlaBLkxKk=; b=jI+U9J6AAmPVHFR+0q93pGMXNE399ZEyKonR5D8w3p1fvEvbrElyWY+zM53p13kjc0 Fyb5P2OEEIxN5NaHcZNWXOUgvP3px+NmlrZIoyd7sLxhN6sdLo4P3gVEI3Ur2IxARTGV Ri/U/HpU+SfdD2oh1U+2tmRujwCIqQMzPZqCM= MIME-Version: 1.0 Received: by 10.236.191.103 with SMTP id f67mr18267342yhn.16.1316740985996; Thu, 22 Sep 2011 18:23:05 -0700 (PDT) Received: by 10.236.108.180 with HTTP; Thu, 22 Sep 2011 18:23:05 -0700 (PDT) Date: Thu, 22 Sep 2011 20:23:05 -0500 Message-ID: From: Behcet Sarikaya To: contreras.uc3m@gmail.com, cjbc@it.uc3m.es, multimob@ietf.org Content-Type: multipart/alternative; boundary=20cf30434ba0bb475904ad91a6fc Subject: [multimob] draft-contreras-multimob-rams-01.txt - resending X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 01:20:34 -0000 --20cf30434ba0bb475904ad91a6fc Content-Type: text/plain; charset=ISO-8859-1 Hi Luis, Carlos, > Here are some comments on your draft: > Section 3: It seems like you are defining a new option to pass the > multicast state from MAG to LMA. > It seems that that's all you need. > Why do you have Sec. 3.2 and 3.3 then? Why not define single option with > some flags and simplify this section? > > 3.5 active multicast subscription indication messages you defined, why do > we need them? I am not convinced. Maybe there are ways of achieving the same > without two new messages. > > Section 5: This section should be TBD because we don't know which solution > will be selected. > You say: > the solution is applicable to the base solution. Can you clarify this by > referring to the state MLD Proxy keeps at the MAG? > > Regards, > > Behcet > --20cf30434ba0bb475904ad91a6fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Luis= , Carlos,
=A0 Here are some comments on your draft:
Section 3: It see= ms like you are defining a new option to pass the multicast state from MAG = to LMA.
It seems that that's all you need.
Why do you have Sec. 3.2 and 3.3= then? Why not define=A0 single option with some flags and simplify this se= ction?

3.5 active multicast subscription indication messages you = defined, why do we need them? I am not convinced. Maybe there are ways of a= chieving the same without two new messages.

Section 5: This section = should be TBD because we don't know which solution will be selected. You say:
the solution=A0 is=A0 applicable to the base solution. Can you clarify this by referring to the state MLD= Proxy keeps at the MAG?

Regards,

Beh= cet

--20cf30434ba0bb475904ad91a6fc-- From contreras.uc3m@gmail.com Mon Sep 26 13:20:48 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377EE1F0CCA for ; Mon, 26 Sep 2011 13:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQjAzG6jUT3T for ; Mon, 26 Sep 2011 13:20:46 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0F721F8DCB for ; Mon, 26 Sep 2011 13:20:06 -0700 (PDT) Received: by vws5 with SMTP id 5so7301593vws.31 for ; Mon, 26 Sep 2011 13:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+yLzv2FUZu7Z1YbOG0ichxjvn93hsQft6yAIw+t7anA=; b=UD53a+tq4R8XnZ2Knb0kfs56QxCEmIlHQMs0tG6sm+U2095P4C0LxeI8Mt4OOVaQ/H ChYhyKVGP9PwX/Eo858+z2Ga7/tLxddUD2R2GQGN/T1jYgmepMPmN5azH0OtVyUMadIf KNWtWaHUOcPIeCnSG4awYfQ43pn+872kANSDg= MIME-Version: 1.0 Received: by 10.52.188.65 with SMTP id fy1mr3912316vdc.442.1317068569628; Mon, 26 Sep 2011 13:22:49 -0700 (PDT) Received: by 10.52.109.6 with HTTP; Mon, 26 Sep 2011 13:22:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 22:22:49 +0200 Message-ID: From: "Luis M. Contreras" To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=bcaec547c87b3cd0ea04adddeccf Cc: multimob@ietf.org Subject: Re: [multimob] draft-contreras-multimob-rams-01.txt - resending X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:20:48 -0000 --bcaec547c87b3cd0ea04adddeccf Content-Type: text/plain; charset=ISO-8859-1 Hi Behcet, thank yoo very much for your comments. My apologies for answering so late. Please, find the answer below, within your text. 2011/9/23 Behcet Sarikaya > > > Hi Luis, Carlos, >> Here are some comments on your draft: >> Section 3: It seems like you are defining a new option to pass the >> multicast state from MAG to LMA. >> It seems that that's all you need. >> Why do you have Sec. 3.2 and 3.3 then? Why not define single option with >> some flags and simplify this section? >> > ----- Luis>> The flags you mention, the one in the PBU/PBA messages (the one described in sec. 3.2), and the one in the LMA cache (defined in sec. 3.3), are used for different things. The former is used to interexchange multicast-support capability information between MAG and LMA. In case the MAG does not support multicast, the LMA will not interrogate the pMAG about any subscription, even if the MN maintains an active multicast session (thus, saving resources). The later flag, the one in the LMA cache, is useful to trigger the interrogation towards the pMAG. According to the state of the flag, the LMA takes the action of interrogating or not the pMAG (always talking about the reactive case). In the new version we propose also to mark the multicast activity in the MN's profile as an option. The idea behind of having the flag also in the MN's profile is to advice in advance the MAG about the existence of an active multicast subscription by the MN entering the MAG coverage area. Then, the MAG becomes aware of an existing subscription before registering the MN. We see this possibility like an option, being the flag on the LMA the mandatory implementation. ---- > >> 3.5 active multicast subscription indication messages you defined, why do >> we need them? I am not convinced. Maybe there are ways of achieving the same >> without two new messages. >> > ---- Luis>> These two messages are the ones that set to 1 or 0 the multicast activity flag in the LMA cache. These messages are indications about the multicast status establishment in the MAG. Such change in the status of the MN can not be signaled by any other existing message, so we belive it is necessary to define these two new messages to handle the multicast activity flag. ----- > >> Section 5: This section should be TBD because we don't know which solution >> will be selected. >> > ----- Luis>> well, it only tries to highlight the fact that the RAMS mechanism is compatible with all the existing proposals for multicast support evolution. It is only informative. If formally it is more correct to maintain it as TBD we can consider it for the next version, but I think that we should maintain it for completeness ----- > You say: >> the solution is applicable to the base solution. Can you clarify this by >> referring to the state MLD Proxy keeps at the MAG? >> > ----- Luis>> In our opinion is compatible because it does not modify the base solution behavior. The MAG continues sending the MLD queries of the corresponding MLD proxy instance as specified in RFC 6224. The information retrieved from the MLD Report should be coherent with that obtained via the LMA. The MLD proxy instance will be updated with the information obtained via the LMA. The MAG will set up the multicast status of the MN during the registration process, and will handle the subscription to the desired group in case it is not yet arriving to the MAG. In our opinion, RAMS helps to accelerate the acquisition of such subscription info by the MAG. You can see this as a kind of redundancy, but also it can be seen as a resilient way of getting the multicast context of the active multicast session at the MN. ____ > >> Regards, >> >> Behcet >> > > Thanks, best regards, Luis --bcaec547c87b3cd0ea04adddeccf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Behcet,

thank yoo very much for your comments. My apologies for a= nswering so late.

Please, find the answer below, within your text.

2011/9/23 Behcet Sarikaya <sarikaya2012@gmail.com<= /a>>


Hi Luis, Carlos,
=A0 Here are some comments on your draft:
Section 3:= It seems like you are defining a new option to pass the multicast state fr= om MAG to LMA.
It seems that that's all you need.
Why do you have Sec. 3.2 and 3.3= then? Why not define=A0 single option with some flags and simplify this se= ction?

-----
Luis>> Th= e flags you mention, the one in the PBU/PBA messages (the one described in = sec. 3.2), and the one in the LMA cache (defined in sec. 3.3), are used for= different things. The former is used to interexchange multicast-support ca= pability information between MAG and LMA. In case the MAG does not support = multicast, the LMA will not interrogate the pMAG about any subscription, ev= en if the MN maintains an active multicast session (thus, saving resources)= .

The later flag, the one in the LMA cache, is useful to trigger the inte= rrogation towards the pMAG. According to the state of the flag, the LMA tak= es the action of interrogating or not the pMAG (always talking about the re= active case).

In the new version we propose also to mark the multicast activity in th= e MN's profile as an option. The idea behind of having the flag also in= the MN's profile is to advice in advance the MAG about the existence o= f an active multicast subscription by the MN entering the MAG coverage area= . Then, the MAG becomes aware of an existing subscription before registerin= g the MN. We see this possibility like an option, being the flag on the LMA= the mandatory implementation.
----
=A0
=

3.5 active multicast subscription indication messages you = defined, why do we need them? I am not convinced. Maybe there are ways of a= chieving the same without two new messages.
----
Luis>> These two messages are the ones that set to 1 or = 0 the multicast activity flag in the LMA cache. These messages are indicati= ons about the multicast status establishment in the MAG.

Such chang= e in the status of the MN can not be signaled by any other existing message= , so we belive it is necessary to define these two new messages to handle t= he multicast activity flag.=A0
-----
=A0

Section 5: This section should be TBD because we don't know which s= olution will be selected.

-----=
Luis>> well, it only tries to highlight the fact that the RAMS me= chanism is compatible with all the existing proposals for multicast support= evolution. It is only informative. If formally it is more correct to maint= ain it as TBD we can consider it for the next version, but I think that we = should maintain it for completeness
-----
=A0
You say:
the solution=A0 is=A0 applicable to the base solution. Can you clarify this by referring to the state MLD= Proxy keeps at the MAG?
-----
L= uis>> In our opinion is compatible because it does not modify the bas= e solution behavior. The MAG continues sending the MLD queries of the corre= sponding MLD proxy instance as specified in RFC 6224. The information retri= eved from the MLD Report should be coherent with that obtained via the LMA.= The MLD proxy instance will be updated with the information obtained via t= he LMA. The MAG will set up the multicast status of the MN during the regis= tration process, and will handle the subscription to the desired group in c= ase it is not yet arriving to the MAG.

In our opinion, RAMS helps to accelerate the acquisition of such subscr= iption info by the MAG. You can see this as a kind of redundancy, but also = it can be seen as a resilient way of getting the multicast context of the a= ctive multicast session at the MN.
____
=A0
=

Regards,

Behcet

Thanks, best regards,

Luis
--bcaec547c87b3cd0ea04adddeccf-- From lmcm@tid.es Tue Sep 27 02:22:21 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91B821F87FC for ; Tue, 27 Sep 2011 02:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.015 X-Spam-Level: * X-Spam-Status: No, score=1.015 tagged_above=-999 required=5 tests=[AWL=-1.201, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4fQBzG69Xbg for ; Tue, 27 Sep 2011 02:22:18 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6945C21F86EE for ; Tue, 27 Sep 2011 02:22:06 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS600DRSCTEEG@tid.hi.inet> for multimob@ietf.org; Tue, 27 Sep 2011 11:24:50 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 5E.FF.08217.266918E4; Tue, 27 Sep 2011 11:24:50 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LS600DRNCTDEG@tid.hi.inet> for multimob@ietf.org; Tue, 27 Sep 2011 11:24:50 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Tue, 27 Sep 2011 11:24:50 +0200 Date: Tue, 27 Sep 2011 11:24:49 +0200 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: To: "Dirk.von-Hugo@telekom.de" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1D+C35ousIoLT4kxCh+8IQ)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [multimob] PMIP MC handover -- some thoughts Thread-index: Acx55CEfOP+oQippTOKOxSqeS6oamQDCDHqA acceptlanguage: es-ES, en-US X-AuditID: 0a5f4068-b7f816d000002019-01-4e81966239d1 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLKsWRmVeSWpSXmKPExsXCFe/ApZs0rdHPYP1yQYsZH/tYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0dh1nq3g+jLGiskb+hkbGDdNZuxi5OSQEDCRWLrlMCuELSZx 4d56ti5GLg4hgY2MEle7brNCOH8YJWZ+fA2VaWSUmNp+hAWkhUVAVaLp218mEJtNwFBi1s5J YKOEBSwl7i+eDmZzCgRLbF+/jRnEFgGKb/3cCRZnFtCWmPZvEVicV8BT4vXq9ewQtqDEj8n3 WCBqciVufHvJCGGLS8z5NRGsl1FAVmLl+dOMEDOtJFY/+88KYRtJ/Pk6mwmiRkbi//K9LBCv CUgs2XOeGcIWlXj5+B/UZw8YJab9PcgygVFsFpLds5DsnoVkN4StI7Fg9ye2WVA/LFv4mhnG PnPgMROy+AJG9lWMYsVJRZnpGSW5iZk56QaGehmZepl5qSWbGCHxl7GDcflOlUOMAhyMSjy8 zlsa/IRYE8uKK3MPMUpyMCmJ8t6c2ugnxJeUn1KZkVicEV9UmpNafIhRgoNZSYTXcBJQjjcl sbIqtSgfJiXDwaEkwTsXpE2wKDU9tSItMweYZGDSTBycIO08QO2dU0DaiwsSc4sz0yHypxhV Ofqebz3BKMSSl5+XKiXOOxNkkABIUUZpHtycV4ziQAcL8+7vB8ryANMk3IRXQMOZgIZ/LQQb XpKIkJJqYMwxfMWT+j5t25dvG5qkI9zMJH91FIVfCdaLPqQ1Rz8k9Wdhzc6jDhPbKvy/vFWc XBN60JujV64qYvPFM2pLOGZ6PPgt+4s1Xvmf3j8Vjj27V+uVTelp+rm8tfKd372rqxrO6rqE XdmWz8cw/+8E6e1K3N0TTjR0PPC7KRguUNT2tzZ+T7HIPSWW4oxEQy3mouJEAHe0lIhQAwAA References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 09:22:22 -0000 --Boundary_(ID_1D+C35ousIoLT4kxCh+8IQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Dirk, Some comments below. ******** The question of degree of HO delay improvement in different CTX scenarios very much depends on the topology as was already stressed at Quebec meeting. I did some rough estimations for inter-MAG CTX and MAG-LMA CTX (aka RAMS) compared to base multimob approach for the different scenarios: MN-MAG delay << MAG-MAG delay < MAG-LMA delay (as may be typical for current 3G topologies with large delays in the core, but allowing for inter-MAG shortcuts): Delay/loss rate: base Multimob, proactive RAMS < inter-MAG CTX < reactive RAMS ----- [Luis>>] For this first scenario, I wonder what RTT measurements are you considering for establishing that in current 3G networks MN-MAG delay is below the delays you can find in the MAG-MAG or MAG-LMA communication. I think this is hard to achieve, even for LTE, if we consider no ideal conditions in the radio part. Regarding the estimation you do, I have some considerations. First at all, regarding base solution vs proactive RAMS, base multimob solution has to account for the MLD Query/Report delays, while RAMS certainly not, because the subscription information or multicast context is piggybacked in the de-registration messages. So, in my opinion, base multimob solution performs always worst, except if we assume that MLD process takes 0 ms (both message transmission as well as message processing). Respect to the comparison between FHO and reactive RAMS, if MAG-MAG delay < MAG-LMA delay, I think that you comparison holds only in the case of CTX transfer for predictive FHO, not in the case of multicast traffic forwarding, because in such case you need additional MLD Query/Report messages from nMAG to pMAG, thus adding more delay, nor in the case of reactive FHO, because in such case FHO depends on the radio part, introducing the delays required for framing, and the delays required for solving the MLD process with the MN. ----- MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for current 3G topologies with large delays in the core w/o inter-MAG shortcuts): Delay/loss rate: base Multimob, proactive RAMS < reactive RAMS < inter-MAG CTX ---- [Luis>>] I think this comparison holds in the same terms as above regarding proactive RAMS and base solution. ---- MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs communicate vie LMA): Delay/loss rate: base Multimob > RAMS > inter-MAG CTX ---- [Luis>>] I don't understand well this comparison. If MAG-MAG delay > MAG-LMA delay, then RAMS performs always better than FHO. Do you agree? ---- Whereas in all cases the total additional signalling load is largest for inter-MAG CTX, whereas the load on radio access (MN-MAG) is largest for base Multimob. ---- [Luis>>] Well, FHO also relays in radio mechanisms to report new point of attachment, so FHO also generates load at radio level. ---- Do you think the assumptions above make sense? I am currently preparing a paper on those considerations - and will share results once they are stable for comments and suggestions. Concerning whether efficient paths between MAGs in operator networks can be assumed IMO it depends: Whereas a direct interconnection (X2) between eNodeBs in E-UTRAN can be assumed, MAGs may be also implemented further up in the network (with even more probable direct links?) ... ---- [Luis>>] Direct links can be useful in scenarios where the MAG-MAG communication can be offloaded from the data network. Could be the support of FHO for multicast the justification for this? I'm not totally sure, at least not as a general case (neither for unicast case). In my opinion, an architecture without such shortcuts will be more common. But it is only my vision. ---- I also agree with the existing MAG-LMA association and think a buffering at LMA could be more beneficial (serving even more potential receivers with intermediate outage ...). I think Carlos also agreed to that feature ... Let's stay in discussion. Thanks! Best regards Dirk ---- [Luis>>] Best regards, Luis ---- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_1D+C35ousIoLT4kxCh+8IQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Dirk,

 

Some comments below.

 

******** 

The question of degree of HO delay improvement in different CTX scenarios very much depends on the topology as was already stressed at Quebec meeting. I did some rough estimations for inter-MAG CTX and MAG-LMA CTX (aka RAMS) compared to base multimob approach for the different scenarios:

 

MN-MAG delay << MAG-MAG delay < MAG-LMA delay (as may be typical for current 3G topologies with large delays in the core, but allowing for inter-MAG shortcuts):

 

Delay/loss rate: base Multimob, proactive RAMS < inter-MAG CTX  < reactive RAMS

 

-----

[Luis>>] For this first scenario, I wonder what RTT measurements are you considering for establishing that in current 3G networks MN-MAG delay is below the delays you can find in the MAG-MAG or MAG-LMA communication. I think this is hard to achieve, even for LTE, if we consider no ideal conditions in the radio part.

Regarding the estimation you do, I have some considerations. First at all, regarding base solution vs proactive RAMS, base multimob solution has to account for the MLD Query/Report delays, while RAMS certainly not, because the subscription information or multicast context is piggybacked in the de-registration messages. So, in my opinion, base multimob solution performs always worst, except if we assume that MLD process takes 0 ms (both message transmission as well as message processing).

Respect to the comparison between FHO and reactive RAMS, if MAG-MAG delay < MAG-LMA delay, I think that you comparison holds only in the case of CTX transfer for predictive FHO, not in the case of multicast traffic forwarding, because in such case you need additional MLD Query/Report messages from nMAG to pMAG, thus adding more delay, nor in the case of reactive FHO, because in such case FHO  depends on the radio part, introducing the delays required for framing, and the delays required for solving the MLD process with the MN.

-----

 

MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for current 3G topologies with large delays in the core w/o inter-MAG shortcuts):

 

Delay/loss rate: base Multimob, proactive RAMS < reactive RAMS < inter-MAG CTX

 

----

[Luis>>] I think this comparison holds in the same terms as above regarding proactive RAMS and base solution.

----

 

MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs communicate vie LMA):

 

Delay/loss rate: base Multimob > RAMS > inter-MAG CTX

 

----

[Luis>>] I don’t understand well this comparison. If MAG-MAG delay > MAG-LMA delay, then RAMS performs always better than FHO. Do you agree?

----

 

Whereas in all cases the total additional signalling load is largest for inter-MAG CTX, whereas the load on radio access (MN-MAG) is largest for base Multimob.

 

----

[Luis>>] Well, FHO also relays in radio mechanisms to report new point of attachment, so FHO also generates load at radio level.

----

 

Do you think the assumptions above make sense?

I am currently preparing a paper on those considerations - and will share  results once they are stable for comments and suggestions.

 

Concerning whether efficient paths between MAGs in operator networks can be assumed IMO it depends: Whereas a direct interconnection (X2) between eNodeBs in E-UTRAN can be assumed, MAGs may be also implemented further up in the network (with even more probable direct links?) ...

 

----

[Luis>>] Direct links can be useful in scenarios where the MAG-MAG communication can be offloaded from the data network. Could be the support of FHO for multicast the justification for this? I’m not totally sure, at least not as a general case (neither for unicast case). In my opinion, an architecture without such shortcuts will be more common. But it is only my vision.

----

 

I also agree with the existing MAG-LMA association and think a buffering at LMA could be more beneficial (serving even more potential receivers with intermediate outage ...). I think Carlos also agreed to that feature ...

 

Let's stay in discussion.

 

Thanks!

 

Best regards

Dirk

 

----

[Luis>>] Best regards,

Luis

----


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_1D+C35ousIoLT4kxCh+8IQ)-- From lmcm@tid.es Tue Sep 27 03:27:34 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8839121F87C9 for ; Tue, 27 Sep 2011 03:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=1.862, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SRmwrvBGXdM for ; Tue, 27 Sep 2011 03:27:33 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 85CB621F88B6 for ; Tue, 27 Sep 2011 03:27:21 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS60074CFU5GR@tid.hi.inet> for multimob@ietf.org; Tue, 27 Sep 2011 12:30:05 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 4F.FB.02718.CA5A18E4; Tue, 27 Sep 2011 12:30:04 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LS600748FU4GR@tid.hi.inet> for multimob@ietf.org; Tue, 27 Sep 2011 12:30:04 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Tue, 27 Sep 2011 12:30:04 +0200 Date: Tue, 27 Sep 2011 12:30:03 +0200 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: To: "schmidt@informatik.haw-hamburg.de" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7lWDkN5Vw0WCyUcTFjBPTw)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [multimob] PMIP MC handover -- some thoughts Thread-index: Acx55C5K4FRPihyhTtC3CD1eLz4OAADE6dbg acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7f146d000000a9e-22-4e81a5ac16c9 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsXCFe9nqLt2aaOfwaZWBYsZH/tYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfHFTZaC/nWMFYs/3GZqYJw+jbGLkZNDQsBEYkLzG3YIW0zi wr31bF2MXBxCAtsZJS7MPMcK4fxhlFi24SQLhNPIKPHmxTlmkBYWAVWJlYvbmUBsNgFDiVk7 J7GC2MIClhL3F08HszkFgiU+vF8Etk5EwFvi8qzVYHFmAW2Jaf8Wgc3hFfCU+Pf+PjuELSjx Y/I9FoiaXIlzh28xQdjiEnN+TQTrZRSQlVh5/jTUTCuJ1c/+s0LYRhIH/x+AqpGR+L98LwvE awISS/acZ4awRSVePv4HViMksI9RYm+j2wRGsVlIVs9CsnoWktUQto7Egt2f2GZBvbBs4Wtm GPvMgcdMyOILGNlXMYoVJxVlpmeU5CZm5qQbGOllZOpl5qWWbGKERF/mDsblO1UOMQpwMCrx 8DpuafATYk0sK67MPcQoycGkJMq7aXGjnxBfUn5KZUZicUZ8UWlOavEhRgkOZiURXsNJQDne lMTKqtSifJiUDAeHkgTvoiVAKcGi1PTUirTMHGCKgUkzcXCCtPMAtX8FqeEtLkjMLc5Mh8if YlTluPt66wlGIZa8/LxUKXHelyBFAiBFGaV5cHNeMYoDHSzMewckywNMknATXgENZwIZXgg2 vCQRISXVwOjOZcQ02/7Mskdi/gxL5RoeN+ewBRVH9DflHOE9yhne7NluMbl1xT+5WSsqupkT zGR/T/3yarmPbtO3x+fYVHrqOffbzlc5XWN05Vb6yehsvcSKeRbfZwklGaWIG527uTdAybDo xeTV5c8/+1461aK0I8znx/1bWZOrhC4ss+URDWE3Kzq9RomlOCPRUIu5qDgRAKBXIVxPAwAA References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> <4E7BA3A3.5070004@informatik.haw-hamburg.de> Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 10:27:34 -0000 --Boundary_(ID_7lWDkN5Vw0WCyUcTFjBPTw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Thomas, Please, find some comments below. ---------- Forwarded message ---------- From: Thomas C. Schmidt > Date: 2011/9/22 Subject: Re: [multimob] PMIP MC handover -- some thoughts To: Marco Liebsch > Cc: "multimob@ietf.org" > On 07.09.2011 17:50, Marco Liebsch wrote: - Why FHO-like forwarding between MAGs is beneficial for multicast? It puts assumptions on inter-MAG operation and introduces overhead which should be justified. There are two assumptions here: 1. There is sufficient mutual trust relationship between MAGs to allow CTX/forwarding (typically an intra provider scenario). 2. The shortest routing distance between pMAG and nMAG is direct routing (i.e., the triangle inequality holds - typically true within a provider network). ---- [Luis>>] Furthermore, both MAGs need to support FHO, and the MNs need to transfer information relative to nMAG ID in case of predictive HO Additionally, you need implement in nMAG a mechanism able to buffer multicast traffic forwarded from pMAG together with multicast traffic directly arriving to nMAG for those groups not forwarded, and feeded by two distinct MLD proxy instances (the one pointing the LMA, and the one pointing the pMAG) ---- Under these assumptions, FHO-like forwarding is the fastest way of data continuity. This is the justification. - Does performance really benefit from forwarding? What's a typical use case: Video broadcast, for example. Streaming applications may have some buffered packets on the player. How does packet drop during handover impact QoE compared to FHO-like forwarded MC packets? I guess they have to be buffered at the target MAG before they can be delivered to the MN, so latency is introduced whereas only packet drop is reduced. For the video broadcast, FHO-like forwarding will reduce/diminish packet loss in the presence of buffering (as you said). I consider this an advantage over the base solution, where - depending on the signaling delay to LMA - packets may go bust. I don't understand your latency argument: Buffering at the nMAG will happen only until the MN has arrived and submitted its MLD report. This is the minimal HO delay, so no extra latency is introduced. ---- [Luis>>] I think that in reactive case the latency incurred by the FHO mechanism is not negligible. First, before triggering the FHO mechanism, you need to obtain the subscription information directly from the MN, and afterwards the nMAG have to trigger the FHO process. Before receiving the multicast flow forwarded by the pMAG, it is necessary to interexchange 4 messages, the HI/HACK couple and the MLD Query/Report pair. In the meanwhile, the nMAG has already triggered the subscription to the groups subscribed by the MN recently attached. So, if you want to serve both the forwarded traffic from pMAG and direct traffic arriving nMAG, you need some kind of buffering, at either MN or nMAG, to play out the multicast traffic conveniently, and this imposes some latency. ---- - Maybe CTX of multicast context is sufficient. Proactive CTX may help. Whereas the benefit of reactive CTX needs to be compared against the performance of the Multimob base approach for PMIPv6 I see two answers: * CTX-transfer (when aligned with unicast like in the FHO-type) without forwarding is as good as the topology supports it. It is very easy to come up with all type of results (depending on various routing distances that need to be traversed for signaling). It seems like a good idea to add a "cookbook-type of evaluation" in the appendix to evaluate the benefit of forwarding. We should add this. * CTX-transfer without unicast alignment can lead to all sorts of weird results, one of which steering traffic to the wrong MAG in repeated handovers as was raised by Marshall in the last meeting. ---- [Luis>>] But FHO certainly decouples multicast from unicast when it is established that in case of HI/HACK messages for unicast have been already sent, new ones are sent for multicast. In my understanding this way of decoupling makes independent the unicast and the multicast HO. Of course they share a common way of transferring the information, a common syntax, but they are not tightly coupled. ---- - If forwarding between MAGs is not really beneficial, what is the right way for CTX? 2 approaches are being discussed: inter-MAG CTX (as per RFC4067) and CTX via LMA. Can we assume efficient paths between MAGs in operator networks? CTX via LMA puts less assumptions on SAs between MAGs and link characteristics between MAGs. In particular beneficial when LMA stores some multicast context. This comes back to the initial assumptions: 1. If pMAG and nMAG both have a trust relation to the same LMA, it may be reasonable to assume a corresponding inter-MAG trust relation. 2. MAGs are access routers in a provider network ... they should allow for a direct routing on the shortest available path. Btw., for the core argument it does not really matter whether this path is "the most direct connection we can think of". All it says is "the shortest path from pMAG to nMAG" (and thats where the traffic has to move). Coming back to the CTX via LMA: This should not only always be the longer/slower way, but from my understanding the LMA is a very central entity concerned with very many MAGs / MNs. Managing the CTX via the LMA puts an additional burden onto this box (multiplied by thousands of customers), which much easier could be handled by the (less loaded) MAGs. This also is closer to the general paradigm of the Internet - where the intelligence sits at the edges, leaving the core with simple duties. ---- [Luis>>]There are ways to do that in a light way. We think RAMS proposal, for instance, does not impose too much to the LMA. ---- So long, Thomas ---- [Luis>>] Regards, Luis ---- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_7lWDkN5Vw0WCyUcTFjBPTw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

Hi Thomas,

 

Please, find some comments below.

 

---------- Forwarded message ----------
From: Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de>
Date: 2011/9/22
Subject: Re: [multimob] PMIP MC handover -- some thoughts
To: Marco Liebsch <Marco.Liebsch@neclab.eu>
Cc: "multimob@ietf.org" <multimob@ietf.org>



On 07.09.2011 17:50, Marco Liebsch wrote:

- Why FHO-like forwarding between MAGs is beneficial for multicast?
It puts assumptions on inter-MAG operation and introduces overhead which
should be justified.

 

There are two assumptions here:

 1. There is sufficient mutual trust relationship between MAGs to allow CTX/forwarding (typically an intra provider scenario).

 2. The shortest routing distance between pMAG and nMAG is direct routing (i.e., the triangle inequality holds - typically true within a provider network).

 

----

[Luis>>] Furthermore, both MAGs need to support FHO, and the MNs need to transfer information relative to nMAG ID in case of predictive HO

Additionally, you need implement in nMAG a mechanism able to buffer multicast traffic forwarded from pMAG together with multicast traffic directly arriving to nMAG for those groups not forwarded, and feeded by two distinct MLD proxy instances (the one pointing the LMA, and the one pointing the pMAG)

----



Under these assumptions, FHO-like forwarding is the fastest way of data continuity. This is the justification.

 

- Does performance really benefit from forwarding? What's a typical use
case:
Video broadcast, for example. Streaming applications may have some
buffered packets on the player. How does packet drop during handover
impact QoE compared to FHO-like forwarded MC packets? I guess they
have to be buffered at the target MAG before they can be delivered to
the MN, so latency is introduced whereas only packet drop is reduced.

 

For the video broadcast, FHO-like forwarding will reduce/diminish packet loss in the presence of buffering (as you said). I consider this an advantage over the base solution, where - depending on the signaling delay to LMA - packets may go bust.

I don't understand your latency argument: Buffering at the nMAG will happen only until the MN has arrived and submitted its MLD report. This is the minimal HO delay, so no extra latency is introduced.

 

----

[Luis>>] I think that in reactive case the latency incurred by the FHO mechanism is not negligible. First, before triggering the FHO mechanism, you need to obtain the subscription information directly from the MN, and afterwards the nMAG have to trigger the FHO process. Before receiving the multicast flow forwarded by the pMAG, it is necessary to interexchange 4 messages, the HI/HACK couple and the MLD Query/Report pair. In the meanwhile, the nMAG has already triggered the subscription to the groups subscribed by the MN recently attached. So, if you want to serve both the forwarded traffic from pMAG and direct traffic arriving nMAG, you need some kind of buffering, at either MN or nMAG, to play out the multicast traffic conveniently, and this imposes some latency.

----

 

 

- Maybe CTX of multicast context is sufficient. Proactive CTX may help.
Whereas the benefit of reactive CTX needs to be compared against the
performance of the Multimob base approach for PMIPv6

 

I see two answers:

 * CTX-transfer (when aligned with unicast like in the FHO-type) without forwarding is as good as the topology supports it. It is very easy to come up with all type of results (depending on various routing distances that need to be traversed for signaling). It seems like a good idea to add a "cookbook-type of evaluation" in the appendix to evaluate the benefit of forwarding. We should add this.

* CTX-transfer without unicast alignment can lead to all sorts of weird results, one of which steering traffic to the wrong MAG in repeated handovers as was raised by Marshall in the last meeting.

 

----

[Luis>>] But FHO certainly decouples multicast from unicast when it is established that in case of HI/HACK messages for unicast have been already sent, new ones are sent for multicast. In my understanding this way of decoupling makes independent the unicast and the multicast HO. Of course they share a common way of transferring the information, a common syntax, but they are not tightly coupled.

----

 

 


- If forwarding between MAGs is not really beneficial, what is the right
way for CTX?
2 approaches are being discussed: inter-MAG CTX (as per RFC4067) and
CTX via LMA. Can we assume efficient paths between MAGs in operator
networks? CTX via LMA puts less assumptions on SAs between MAGs and
link characteristics between MAGs. In particular beneficial when LMA
stores some multicast context.

 

This comes back to the initial assumptions:

 1. If pMAG and nMAG both have a trust relation to the same LMA, it may be reasonable to assume a corresponding inter-MAG trust relation.

 2. MAGs are access routers in a provider network ... they should allow for a direct routing on the shortest available path. Btw., for the core argument it does not really matter whether this path is "the most direct connection we can think of". All it says is "the shortest path from pMAG to nMAG" (and thats where the traffic has to move).

Coming back to the CTX via LMA: This should not only always be the longer/slower way, but from my understanding the LMA is a very central entity concerned with very many MAGs / MNs. Managing the CTX via the LMA puts an additional burden onto this box (multiplied by thousands of customers), which much easier could be handled by the (less loaded) MAGs. This also is closer to the general paradigm of the Internet - where the intelligence sits at the edges, leaving the core with simple duties.

 

----

[Luis>>]There are ways to do that in a light way. We think RAMS proposal, for instance, does not impose too much to the LMA.

----



So long,

Thomas

----

[Luis>>] Regards,

Luis

----

 


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_7lWDkN5Vw0WCyUcTFjBPTw)-- From lmcm@tid.es Tue Sep 27 03:38:53 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EE021F8B67 for ; Tue, 27 Sep 2011 03:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=1.986, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WElfzkBNilSd for ; Tue, 27 Sep 2011 03:38:51 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id E3CA421F8B45 for ; Tue, 27 Sep 2011 03:38:49 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS6007Y2GD5GR@tid.hi.inet> for multimob@ietf.org; Tue, 27 Sep 2011 12:41:33 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 58.4C.02718.D58A18E4; Tue, 27 Sep 2011 12:41:33 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LS6007YMGD9GR@tid.hi.inet> for multimob@ietf.org; Tue, 27 Sep 2011 12:41:33 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Tue, 27 Sep 2011 12:41:33 +0200 Date: Tue, 27 Sep 2011 12:41:31 +0200 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: To: "schmidt@informatik.haw-hamburg.de" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NVe8mgCldX8CVllRGIoC2w)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [multimob] PMIP MC handover -- some thoughts Thread-index: Acx55DffRWbVtYXiQ3eTiI2cFJ3XkQDHEF3g acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7f146d000000a9e-ba-4e81a85d8011 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFKsWRmVeSWpSXmKPExsXCFe9nqBu7otHP4OEGWYsZH/tYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XL1draCWYkVPV0bGRsYf4V2MXJwSAiYSNxtEu9i5AQyxSQu 3FvP1sXIxSEksJ1RomHyT2YI5w+jxOre34wQTiOjxNe5zYwgLSwCqhLznjeygNhsAoYSs3ZO YgWxhQUsJe4vng5mcwoES3w79pgdxBYR8Ja4PGs1WJxZQFti2r9FzCA2r4CnxOFfO9kgbEGJ H5PvsUDU5Erc/H0Eql5cYs6viWA2o4CsxMrzpxkhZlpJrH72nxXCNpK40T6JGaJGRuL/8r0s EK8JSCzZc54ZwhaVePn4HyvEM/1MEk9ebGacwCg2C8nuWUh2z0KyG8LWkViw+xPbLKgfli18 zQxjnznwmAlZfAEj+ypGseKkosz0jJLcxMycdAMjvYxMvcy81JJNjJDIy9zBuHynyiFGAQ5G JR5exy0NfkKsiWXFlbmHGCU5mJREeSWWNvoJ8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuE1nASU 401JrKxKLcqHSclwcChJ8BYuB0oJFqWmp1akZeYA0wtMmomDE6SdB6jdB6SGt7ggMbc4Mx0i f4pRlaPv+dYTjEIsefl5qVLivJkgRQIgRRmleXBzXjGKAx0szJsFkuUBJki4Ca+AhjMBDf9a CDa8JBEhJdXAmCNqGfTk05Xz3QEln1gUds0J4Jw97119Q8nTspCAmz+a4nnYf7Jo7FV7vcVg m8NeJ7X/jrw8IrNu/P/LzxsQzjvZPCNnwZLCOOmQX5KXW5o4kg8/iHT8L8fwV2hf8q7ikFIO +Uz3g4vfBkxddapDo7bqUG3604OG9hmTyjTPH3b5/FXFOeSQEktxRqKhFnNRcSIAZ2O12k0D AAA= References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> <4E7BAFC2.5080503@informatik.haw-hamburg.de> Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 10:38:53 -0000 --Boundary_(ID_NVe8mgCldX8CVllRGIoC2w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Thomas, Please, find some comments inline. ---------- Forwarded message ---------- From: Thomas C. Schmidt > Date: 2011/9/22 Subject: Re: [multimob] PMIP MC handover -- some thoughts To: Dirk.von-Hugo@telekom.de Cc: multimob@ietf.org MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for current 3G topologies with large delays in the core w/o inter-MAG shortcuts): More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG delay ... and "pMAG-nMAG delay =< pMAG-LMA-nMAG delay" should always hold. ---- [Luis>>] I don't think so. In case of proactive RAMS HO, the pMAG-LMA and LMA-nMAG flows are part of the registration process, so no additional messages are needed. In case of reactive RAMS HO, the pMAG-LMA messages are specific of the HO optimization process, but LMA-nMAG messages are part of the registration process. In case of FHO, you need the HI/HACK messages, the MLD Query/Report messages for forwarding, and the LMA-nMAG messages for registering. So, in the best case, (no multicast forwarding) FHO and RAMS HO have the same number of messages flowing across the network. The different delay can be obtained from the paths among MAGs, or between LMA-MAG, not from the number of messages involved in the process. Don't forget the dependency of the radio part for some of the cases. ---- MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs communicate vie LMA): ???? I'm not an LTE expert, but as far as I know, the wireless link delay in LTE is small. I read "downlink below 1 ms". If true, this assumption seems artificial. ---- [Luis>>] Despite the radio access delay due to framing, we have to take into account the MLD processing by the MN, as well as no ideal conditions in the radio part (we are in a HO process where the MN is in the border of a cell, so it is hard to consider ideal conditions) ---- [Luis>>] Best regards, Luis ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_NVe8mgCldX8CVllRGIoC2w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Thomas,

 

Please, find some comments inline.

 

 

---------- Forwarded message ----------
From: Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de>
Date: 2011/9/22
Subject: Re: [multimob] PMIP MC handover -- some thoughts
To: Dirk.von-Hugo@telekom.de
Cc: multimob@ietf.org



 

MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for
current 3G topologies with large delays in the core w/o inter-MAG
shortcuts):

 

More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG delay ... and "pMAG-nMAG delay =< pMAG-LMA-nMAG delay" should always hold.

 

----

[Luis>>] I don’t think so. In case of proactive RAMS HO, the pMAG-LMA and LMA-nMAG flows are part of the registration process, so no additional messages are needed.

In case of reactive RAMS HO, the pMAG-LMA messages are specific of the HO optimization process, but LMA-nMAG messages are part of the registration process.

In case of FHO, you need the HI/HACK messages, the MLD Query/Report messages for forwarding, and the LMA-nMAG messages for registering.

So, in the best case, (no multicast forwarding) FHO and RAMS HO have the same number of messages flowing across the network.

The different delay can be obtained from the paths among MAGs, or between LMA-MAG, not from the number of messages involved in the process.

Don’t forget the dependency of the radio part for some of the cases.

----

 

MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in
future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs
communicate vie LMA):

 

???? I'm not an LTE expert, but as far as I know, the wireless link delay in LTE is small. I read "downlink below 1 ms". If true, this assumption seems artificial.

 

----

[Luis>>] Despite the radio access delay due to framing, we have to take into account the MLD processing by the MN, as well as no ideal conditions in the radio part (we are in a HO process where the MN is in the border of a cell, so it is hard to consider ideal conditions)

----

 

 

[Luis>>] Best regards,

Luis


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_NVe8mgCldX8CVllRGIoC2w)-- From Dirk.von-Hugo@telekom.de Tue Sep 27 08:41:37 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34C121F8E6D for ; Tue, 27 Sep 2011 08:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiefsdJoMKYR for ; Tue, 27 Sep 2011 08:41:36 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 99FDA21F8B32 for ; Tue, 27 Sep 2011 08:41:35 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 27 Sep 2011 14:02:44 +0200 Received: from HE111628.emea1.cds.t-internal.com (10.134.93.20) by HE111629.emea1.cds.t-internal.com (10.134.93.21) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 27 Sep 2011 14:02:44 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.49]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 27 Sep 2011 14:02:44 +0200 From: To: Date: Tue, 27 Sep 2011 14:02:42 +0200 Thread-Topic: [multimob] PMIP MC handover -- some thoughts Thread-Index: Acx5cuiLRsF/XrEsQGGg/n4Uc1uR5wDl8gYw Message-ID: <05C81A773E48DD49B181B04BA21A342A2646A7FF7B@HE113484.emea1.cds.t-internal.com> References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> <4E7BAFC2.5080503@informatik.haw-hamburg.de> In-Reply-To: <4E7BAFC2.5080503@informatik.haw-hamburg.de> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 15:41:37 -0000 Hi Thomas, Thanks for your immediate response ... And for your interest in our work - = it is still in first steps as you may have detected from the assumptions wh= ich partly may be very artificial ... We are working on that. And we will l= et you know asap ;-) Please see my other comments inline Thank you and best regards Dirk Von: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] Gesendet: Freitag, 23. September 2011 00:00 An: von Hugo, Dirk Cc: Marco.Liebsch@neclab.eu; multimob@ietf.org Betreff: Re: [multimob] PMIP MC handover -- some thoughts Hi Dirk, to start first with the last: We would be very interested to see your preliminary evaluation paper and discuss results. Some more comments inline: On 22.09.2011 18:54, Dirk.von-Hugo@telekom.de wrote: > The question of degree of HO delay improvement in different CTX > scenarios very much depends on the topology as was already stressed at > Quebec meeting. I did some rough estimations for inter-MAG CTX and > MAG-LMA CTX (aka RAMS) compared to base multimob approach for the > different scenarios: > MN-MAG delay << MAG-MAG delay < MAG-LMA delay (as may be typical for > current 3G topologies with large delays in the core, but allowing for > inter-MAG shortcuts): This assumption sounds reasonable to me. > Delay/loss rate: base Multimob, proactive RAMS < inter-MAG CTX < > reactiveRAMS Delay/loss rate looks like an odd metric to me. What shall we think of a network that experiences zero delay, but little to infinite loss? What is 0/0 then? =3D Dirk: Sorry for my mistyping (quick typing before thinking) - what I me= ant here was 'delay' _or_ (as it may be proportional) 'loss ratio' (rather = than loss rate). > MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for > current 3G topologies with large delays in the core w/o inter-MAG > shortcuts): More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG delay ... and "pMAG-nMAG delay =3D< pMAG-LMA-nMAG delay" should always hold= . =3D Dirk: That's what I meant with MAG-MAG > MAG-LMA, i.e. in worst case in= ter-MAG communication is via LMA (or some entity which is nearer to LMA tha= n to MAG). But since some messages are exchanged between nMAG and LMA, some= between pMAG and LMA and (for some approaches) some directly between nMAG = and pMAG I decided to split nMAG-LMA-pMAG into both parts ... > MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in > future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs > communicate vie LMA): ???? I'm not an LTE expert, but as far as I know, the wireless link delay in LTE is small. I read "downlink below 1 ms". If true, this assumption seems artificial. =3D Dirk: I just heard something about 3.5 ms between UE and eNodeB - but t= he main assumption was that wired links in core could be very fast thanks t= o still higher bandwidth (e.g. fibre) And assuming heterogeneous networks with WLAN completing LTE the wireless d= elay may be larger due to multiple hops to MAG and processing for e.g. CSMA= and so on. > Do you think the assumptions above make sense? As said, some of them do, some don't. > Concerning whether efficient paths between MAGs in operator networks can > be assumed IMO it depends: Whereas a direct interconnection (X2) between > eNodeBs in E-UTRAN can be assumed, MAGs may be also implemented further > up in the network (with even more probable direct links?) ... MAGs need to be the first hop routers, so below the MAG its all L2. Personally, the worst network I can think of builds a star topology starting from LMA - still some meshing in larger provider networks seems appropriate. But you'll never know - some people sell wireless access cables on Ebay. > I also agree with the existing MAG-LMA association and think a buffering > at LMA could be more beneficial (serving even more potential receivers > with intermediate outage ...). I think Carlos also agreed to that > feature ... Buffering on the LMA means buffering in the core network. This carries the (misleading) charm that the same packets could be replayed to different MAGs/MNs. However, this is not that simple, as MNs do not behave in a synchronized fashion. Even if subscribed to the same group, each MN performs its handover at a different position in the packet flow. So the LMA would need to keep track of that (for MN X select packets Y-Z from group buffer G_X). =3D Dirk: You are right - this needs more elaboration (the explicit trackin= g is on MAG, I assume). My counter picture would see the LMA keeping individual buffers for thousands of MNs ... which looks like a case for Avici. Unfortunately, Avici is gone. Best wishes, Thomas =3D Dirk: Thanks a lot again! > ------------------------------------------------------------------------ > *Von:* multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] *Im > Auftrag von *Marco Liebsch > *Gesendet:* Mittwoch, 7. September 2011 17:50 > *An:* multimob@ietf.org > *Betreff:* [multimob] PMIP MC handover -- some thoughts > > Hi, > > based on some discussion about multicast handover optimization during IET= F81 > in Quebec, I have been asked to send some thoughts to the list to foster > the discussion in this context. Please find below some quick thoughts and > questions which I write down. You may take them into account for the > PMIP MC handover discussion. Hope some of them make sense and are useful. > > marco > > - Why FHO-like forwarding between MAGs is beneficial for multicast? > It puts assumptions on inter-MAG operation and introduces overhead which > should be justified. > > - Does performance really benefit from forwarding? What's a typical use > case: > Video broadcast, for example. Streaming applications may have some > buffered packets on the player. How does packet drop during handover > impact QoE compared to FHO-like forwarded MC packets? I guess they > have to be buffered at the target MAG before they can be delivered to > the MN, so latency is introduced whereas only packet drop is reduced. > > - Is packet re-ordering an issue (forwarded packets between MAGs vs direc= t > packets)? Well, RTP may help on the player if it's used. Or is re-orderin= g > resolved on the MAG by means of scheduled delivery to the MN? > > - Maybe CTX of multicast context is sufficient. Proactive CTX may help. > Whereas the benefit of reactive CTX needs to be compared against the > performance of the Multimob base approach for PMIPv6 > > - If forwarding between MAGs is adopted, we may consider it optional > > > - If forwarding between MAGs is not really beneficial, what is the right > way for CTX? > 2 approaches are being discussed: inter-MAG CTX (as per RFC4067) and > CTX via LMA. Can we assume efficient paths between MAGs in operator > networks? CTX via LMA puts less assumptions on SAs between MAGs and > link characteristics between MAGs. In particular beneficial when LMA > stores some multicast context. > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt =B0 Hamburg University of Applied Sciences Berliner Tor 7= =B0 =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany= =B0 =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452= =B0 =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409= =B0 From sarikaya2012@gmail.com Tue Sep 27 15:17:13 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A2521F8F40 for ; Tue, 27 Sep 2011 15:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0FCX+1ZrjxQ for ; Tue, 27 Sep 2011 15:17:12 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B58C21F8F38 for ; Tue, 27 Sep 2011 15:17:12 -0700 (PDT) Received: by yic13 with SMTP id 13so6858578yic.31 for ; Tue, 27 Sep 2011 15:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bBiw5zFmBJRiD8oD8qm5qYom/iq7Mpa28QdRixQUYSU=; b=vhXXijp9+fkru312wOS8Yrc/BCOj1X2o2Y7QrBQPUBLm4nW0wX9hXuZyaZ71GlsL0M +29yx0aHXzx8lqs6wCWW1suXf01cYUt8tR8UbvBCrEl6jHr3u3kDvqEQQ64rLD5ZsIdu cdW1wTkIkdd/XmuAQF2BVoBX5zzNIJbeEGycA= MIME-Version: 1.0 Received: by 10.236.77.233 with SMTP id d69mr51145419yhe.84.1317161997244; Tue, 27 Sep 2011 15:19:57 -0700 (PDT) Received: by 10.236.108.180 with HTTP; Tue, 27 Sep 2011 15:19:57 -0700 (PDT) In-Reply-To: References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> <4E7BAFC2.5080503@informatik.haw-hamburg.de> Date: Tue, 27 Sep 2011 17:19:57 -0500 Message-ID: From: Behcet Sarikaya To: LUIS MIGUEL CONTRERAS MURILLO Content-Type: multipart/alternative; boundary=20cf30050e1ef51a0804adf3ac90 Cc: "multimob@ietf.org" , "schmidt@informatik.haw-hamburg.de" Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 22:17:13 -0000 --20cf30050e1ef51a0804adf3ac90 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, Sorry but I don't see anything in this mail relevant to what Marco posted (in the subject line), like: Why FHO-like forwarding between MAGs is beneficial for multicast? Does performance really benefit from forwarding? Is packet re-ordering an issue (forwarded packets between MAGs vs direct packets)? Or is re-ordering resolved on the MAG by means of scheduled delivery to the MN? Maybe CTX of multicast context is sufficient. Proactive CTX may help. Whereas the benefit of reactive CTX needs to be compared against the performance of the Multimob base approach for PMIPv6 If forwarding between MAGs is not really beneficial, what is the right way for CTX? Regards, Behcet On Tue, Sep 27, 2011 at 5:41 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > Hi Thomas,**** > > ** ** > > Please, find some comments inline.**** > > ** ** > > ** ** > > ---------- Forwarded message ---------- > From: *Thomas C. Schmidt* > Date: 2011/9/22 > Subject: Re: [multimob] PMIP MC handover -- some thoughts > To: Dirk.von-Hugo@telekom.de > Cc: multimob@ietf.org > > > > **** > > ** ** > > MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for > current 3G topologies with large delays in the core w/o inter-MAG > shortcuts):**** > > ** ** > > More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG delay > ... and "pMAG-nMAG delay =3D< pMAG-LMA-nMAG delay" should always hold.***= * > > * * > > *----* > > *[Luis>>] I don=92t think so. In case of proactive RAMS HO, the pMAG-LMA = and > LMA-nMAG flows are part of the registration process, so no additional > messages are needed.* > > *In case of reactive RAMS HO, the pMAG-LMA messages are specific of the H= O > optimization process, but LMA-nMAG messages are part of the registration > process.* > > *In case of FHO, you need the HI/HACK messages, the MLD Query/Report > messages for forwarding, and the LMA-nMAG messages for registering. * > > *So, in the best case, (no multicast forwarding) FHO and RAMS HO have the > same number of messages flowing across the network. * > > *The different delay can be obtained from the paths among MAGs, or betwee= n > LMA-MAG, not from the number of messages involved in the process.* > > *Don=92t forget the dependency of the radio part for some of the cases.* > > *----***** > > ** ** > > MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in > future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs > communicate vie LMA):**** > > ** ** > > ???? I'm not an LTE expert, but as far as I know, the wireless link delay > in LTE is small. I read "downlink below 1 ms". If true, this assumption > seems artificial.**** > > * * > > *----* > > *[Luis>>] Despite the radio access delay due to framing, we have to take > into account the MLD processing by the MN, as well as no ideal conditions= in > the radio part (we are in a HO process where the MN is in the border of a > cell, so it is hard to consider ideal conditions)* > > *----***** > > ** ** > > ** ** > > *[Luis>>] Best regards,* > > *Luis***** > > ------------------------------ > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el= enlace > situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > --20cf30050e1ef51a0804adf3ac90 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all,
=A0 Sorry but I don't see anything in this mail relevant to = what Marco posted (in the subject line), like:

Why FHO-like forwardi= ng between MAGs is beneficial for multicast?
Does performance really ben= efit from forwarding?
Is packet re-ordering an issue (forwarded packets between MAGs vs direct =A0 packets)? Or is re-ordering
=A0 resolved on the MAG by means of scheduled delivery to the MN?
Maybe = CTX of multicast context is sufficient. Proactive CTX may help.
=A0 Whereas the benefit of reactive CTX needs to be compared against the =A0 performance of the Multimob base approach for PMIPv6
If forwarding b= etween MAGs is not really beneficial, what is the right way for CTX?
Regards,

Behcet
On Tue, Sep 27, 2011 = at 5:41 AM, LUIS MIGUEL CONTRERAS MURILLO <lmcm@tid.es> wrote:

Hi Th= omas,

=A0

Pleas= e, find some comments inline.

=A0

=A0

---------- Forwarded message -= ---------
From: Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de> Date: 2011/9/22
Subject: Re: [multimob] PMIP MC handover -- some thoughts
To: Dirk.von-= Hugo@telekom.de
Cc: multimob@ietf.or= g



=A0

MN-MAG delay << MAG-LMA delay < MAG-MAG del= ay (as may be typical for
current 3G topologies with large delays in the core w/o inter-MAG
shortcuts):

=A0

More precisely, you should compare pMAG-LMA-nMAG del= ay to pMAG-nMAG delay ... and "pMAG-nMAG delay =3D< pMAG-LMA-nMAG d= elay" should always hold.

=A0

----

[Luis>>] I don=92t think so. In case of proactive RAMS HO, the pMAG-= LMA and LMA-nMAG flows are part of the registration process, so no addition= al messages are needed.

In case of reactive RAMS HO, the pMAG-LMA messages are specific of the HO = optimization process, but LMA-nMAG messages are part of the registration pr= ocess.

In case of FHO, you need the HI/HACK messages, the MLD Query/Report messag= es for forwarding, and the LMA-nMAG messages for registering.

So, in the best case, (no multicast forwarding) FHO and RAMS HO have the s= ame number of messages flowing across the network.

The different delay can be obtained from the paths among MAGs, or between = LMA-MAG, not from the number of messages involved in the process.=

Don=92t forget the dependency of the radio part for some of the cases.<= /u>

----<= u>

=A0

MN/MAG delay > MAG-MAG delay > MAG-LMA delay (= as could be achieved in
future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs communicate vie LMA):

=A0

???? I'm not an LTE expert, but as far as I know= , the wireless link delay in LTE is small. I read "downlink below 1 ms= ". If true, this assumption seems artificial.

=A0

----

[Luis>>] Despite the radio access delay due to framing, we have to t= ake into account the MLD processing by the MN, as well as no ideal conditio= ns in the radio part (we are in a HO process where the MN is in the border of a cell= , so it is hard to consider ideal conditions)<= /p>

----<= u>

=A0

=A0

[Luis>>] Best regards,

Luis<= u>


Este mensaje se dirige exclu= sivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo = y recepci=F3n de correo electr=F3nico en el enlace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at.
= http://www.tid.es/ES/PAGINAS/disclaimer.aspx

_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob


--20cf30050e1ef51a0804adf3ac90-- From schmidt@informatik.haw-hamburg.de Tue Sep 27 17:04:58 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB15F21F8DE8 for ; Tue, 27 Sep 2011 17:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2Ge+8xPJV2N for ; Tue, 27 Sep 2011 17:04:58 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD4A21F847E for ; Tue, 27 Sep 2011 17:04:57 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dslc-082-083-140-121.pools.arcor-ip.net ([82.83.140.121] helo=[192.168.2.66]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1R8hgd-000Ljb-QS; Wed, 28 Sep 2011 02:07:44 +0200 Message-ID: <4E826551.5080209@informatik.haw-hamburg.de> Date: Wed, 28 Sep 2011 02:07:45 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: sarikaya@ieee.org References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> <4E7BAFC2.5080503@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: "multimob@ietf.org" , Behcet Sarikaya Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 00:04:59 -0000 Hi Behcet, hi Luis, On 28.09.2011 00:19, Behcet Sarikaya wrote: > Sorry but I don't see anything in this mail relevant to what Marco > posted (in the subject line), like: > This is probably true ... anyway, please see answers inline. > On Tue, Sep 27, 2011 at 5:41 AM, LUIS MIGUEL CONTRERAS MURILLO > > wrote: > > Hi Thomas,____ > > __ __ > > Please, find some comments inline.____ > > __ __ > > __ __ > > ---------- Forwarded message ---------- > From: *Thomas C. Schmidt* > > Date: 2011/9/22 > Subject: Re: [multimob] PMIP MC handover -- some thoughts > To: Dirk.von-Hugo@telekom.de > Cc: multimob@ietf.org > > > > ____ > > __ __ > > MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for > current 3G topologies with large delays in the core w/o inter-MAG > shortcuts):____ > > __ __ > > More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG > delay ... and "pMAG-nMAG delay =< pMAG-LMA-nMAG delay" should always > hold.____ > > */__ __/* > > */----____/* > > */[Luis>>] I don’t think so. In case of proactive RAMS HO, the > pMAG-LMA and LMA-nMAG flows are part of the registration process, so > no additional messages are needed.____/* > Well, you need to signal the HO - if this happens a priory (in a predictive mode), then re-directions happens asynchronously, possibly in parallel to the Phy handover. This is the same in FHO. If RAMs anchors signaling at the LMA, then signaling is either pMAG-LMA-nMAG or nMAG-LMA-nMAG, both being of the same delay magnitude. > */----/*____ > > __ __ > > MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be > achieved in > future LTE/EPC topologies without direct inter-MAG connection, > i.e. MAGs > communicate vie LMA):____ > > __ __ > > ???? I'm not an LTE expert, but as far as I know, the wireless link > delay in LTE is small. I read "downlink below 1 ms". If true, this > assumption seems artificial.____ > > */__ __/* > > */----____/* > > */[Luis>>] Despite the radio access delay due to framing, we have to > take into account the MLD processing by the MN, as well as no ideal > conditions in the radio part (we are in a HO process where the MN is > in the border of a cell, so it is hard to consider ideal > conditions)____/* > > */----/*____ > For the radio, I guess we can assume normal behavior which is only slightly slower than a normal 100 Mbit LAN link. For the MLD processing: in FHO we don't have an MLD processing at MN in the normal predictive mode and no signaling on the wireless link. So these possible issues don't apply. In the reactive mode, one could do without the MN-local MLD processing ... this is only applied for the sake of acceleration. The key comparison is not the wireless link, but the routing distances pMAG/pAR <-> nMAG/nAR versus MAG <-> LMA ... in addition of course FHO is not bound to PMIP. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From Dirk.von-Hugo@telekom.de Wed Sep 28 05:43:25 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F262521F8D4F for ; Wed, 28 Sep 2011 05:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiFTEZKXO1lf for ; Wed, 28 Sep 2011 05:43:23 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id D66C421F8D4D for ; Wed, 28 Sep 2011 05:43:21 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 28 Sep 2011 14:43:13 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.201]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 28 Sep 2011 14:43:13 +0200 From: To: , Date: Wed, 28 Sep 2011 14:43:11 +0200 Thread-Topic: [multimob] PMIP MC handover -- some thoughts Thread-Index: Acx9Y55Y5lHuh8OHQHSVYkK2QXNSBgAdnC6w Message-ID: <05C81A773E48DD49B181B04BA21A342A2650EAE486@HE113484.emea1.cds.t-internal.com> References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> <4E7BAFC2.5080503@informatik.haw-hamburg.de> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2650EAE486HE113484emea1_" MIME-Version: 1.0 Cc: multimob@ietf.org, schmidt@informatik.haw-hamburg.de Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 12:43:25 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2650EAE486HE113484emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Behcet, referring to your comment of course not all issues raised by Marco (e.g. re= -ordering) are covered but I see at least the following points: FHO-like forwarding between MAGs includes CTX initiation - and we might eva= luate whether or for which scenarios (topologies,i.e. delays on different p= aths _and/or_ applications, i.e. real-time or full content delivery) there = are benefits compared to LMA-MAG based forwarding. And regarding the benefit of Proactive CTX and Reactive CTX compared to Ba= se Multimob: This should be focus of some calculations described earlier wh= ich of course need refinements ... ... and questions of delay on radio part or between MAGs/LMAs and the requi= red messages there are driving the delay and thus the performance IMHO. Or what is the point which I missed? Best regards Dirk ________________________________ Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftra= g von Behcet Sarikaya Gesendet: Mittwoch, 28. September 2011 00:20 An: LUIS MIGUEL CONTRERAS MURILLO Cc: multimob@ietf.org; schmidt@informatik.haw-hamburg.de Betreff: Re: [multimob] PMIP MC handover -- some thoughts Hi all, Sorry but I don't see anything in this mail relevant to what Marco posted= (in the subject line), like: Why FHO-like forwarding between MAGs is beneficial for multicast? Does performance really benefit from forwarding? Is packet re-ordering an issue (forwarded packets between MAGs vs direct packets)? Or is re-ordering resolved on the MAG by means of scheduled delivery to the MN? Maybe CTX of multicast context is sufficient. Proactive CTX may help. Whereas the benefit of reactive CTX needs to be compared against the performance of the Multimob base approach for PMIPv6 If forwarding between MAGs is not really beneficial, what is the right way = for CTX? Regards, Behcet On Tue, Sep 27, 2011 at 5:41 AM, LUIS MIGUEL CONTRERAS MURILLO > wrote: Hi Thomas, Please, find some comments inline. ---------- Forwarded message ---------- From: Thomas C. Schmidt > Date: 2011/9/22 Subject: Re: [multimob] PMIP MC handover -- some thoughts To: Dirk.von-Hugo@telekom.de Cc: multimob@ietf.org MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for current 3G topologies with large delays in the core w/o inter-MAG shortcuts): More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG delay .= .. and "pMAG-nMAG delay =3D< pMAG-LMA-nMAG delay" should always hold. ---- [Luis>>] I don't think so. In case of proactive RAMS HO, the pMAG-LMA and L= MA-nMAG flows are part of the registration process, so no additional messag= es are needed. In case of reactive RAMS HO, the pMAG-LMA messages are specific of the HO o= ptimization process, but LMA-nMAG messages are part of the registration pro= cess. In case of FHO, you need the HI/HACK messages, the MLD Query/Report message= s for forwarding, and the LMA-nMAG messages for registering. So, in the best case, (no multicast forwarding) FHO and RAMS HO have the sa= me number of messages flowing across the network. The different delay can be obtained from the paths among MAGs, or between L= MA-MAG, not from the number of messages involved in the process. Don't forget the dependency of the radio part for some of the cases. ---- MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs communicate vie LMA): ???? I'm not an LTE expert, but as far as I know, the wireless link delay i= n LTE is small. I read "downlink below 1 ms". If true, this assumption seem= s artificial. ---- [Luis>>] Despite the radio access delay due to framing, we have to take int= o account the MLD processing by the MN, as well as no ideal conditions in t= he radio part (we are in a HO process where the MN is in the border of a ce= ll, so it is hard to consider ideal conditions) ---- [Luis>>] Best regards, Luis ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --_000_05C81A773E48DD49B181B04BA21A342A2650EAE486HE113484emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Behcet,
referring to your comment of course not all issues ra= ised by=20 Marco (e.g. re-ordering) are covered but I see at least the following=20 points:
 
FHO-like forwarding between MAGs includes CTX in= itiation=20 - and we might evaluate whether or for which scenarios (topologies,i.e. del= ays=20 on different paths _and/or_ applications, i.e. real-time or full content=20 delivery) there are benefits compared to LMA-MAG based=20 forwarding.
 And regarding the benefit of Proactive CTX and Reacti= ve CTX=20 compared to Base Multimob: This should be focus of some calculations descri= bed=20 earlier which of course need refinements ...
... and questions of delay on radio part or between M= AGs/LMAs=20 and the required messages there are driving the delay and thus the performa= nce=20 IMHO.
Or what is the point which I=20 missed?
 

Best regards
Dirk <= /FONT>

Von: multimob-bounces@ietf.org=20 [mailto:multimob-bounces@ietf.org] Im Auftrag von Behcet=20 Sarikaya
Gesendet: Mittwoch, 28. September 2011 00:20
An:=20 LUIS MIGUEL CONTRERAS MURILLO
Cc: multimob@ietf.org;=20 schmidt@informatik.haw-hamburg.de
Betreff: Re: [multimob] PMIP MC= =20 handover -- some thoughts

Hi all,
  Sorry but I don't see anything in this mail=20 relevant to what Marco posted (in the subject line), like:

Why FHO-l= ike=20 forwarding between MAGs is beneficial for multicast?
Does performance re= ally=20 benefit from forwarding?
Is packet re-ordering an issue (forwarded packe= ts=20 between MAGs vs direct
  packets)? Or is re-ordering
  reso= lved=20 on the MAG by means of scheduled delivery to the MN?
Maybe CTX of multic= ast=20 context is sufficient. Proactive CTX may help.
  Whereas the benefi= t of=20 reactive CTX needs to be compared against the
  performance of the= =20 Multimob base approach for PMIPv6
If forwarding between MAGs is not real= ly=20 beneficial, what is the right way for CTX?

Regards,

Behcet
On Tue, Sep 27, 2011 at 5:41 AM, LUIS MIGUEL CONTR= ERAS=20 MURILLO <lmcm@tid.es> wrote:

Hi=20 Thomas,

 

Plea= se, find=20 some comments inline.

 

 

---------- Forwarded message ----------
From: Thoma= s C.=20 Schmidt <schmidt@informatik.haw-hamburg.de>
Date:=20 2011/9/22
Subject: Re: [multimob] PMIP MC handover -- some thoughts=
To:=20 Dirk.von-Hugo@telekom.de
Cc: multimob@ietf.org



 =

MN-MAG delay << MAG-LMA delay < MAG-MAG d= elay=20 (as may be typical for
current 3G topologies with large delays in th= e=20 core w/o inter-MAG
shortcuts):

 

More precisely, you should compare pMAG-LMA-nMAG del= ay to=20 pMAG-nMAG delay ... and "pMAG-nMAG delay =3D< pMAG-LMA-nMAG delay" sho= uld=20 always hold.

&n= bsp;

----

[Luis>>] I don=92t think = so. In=20 case of proactive RAMS HO, the pMAG-LMA and LMA-nMAG flows are part of th= e=20 registration process, so no additional messages are=20 needed.

----

 =

MN/MAG delay > MAG-MAG delay > MAG-LMA delay= (as=20 could be achieved in
future LTE/EPC topologies without direct inter-= MAG=20 connection, i.e. MAGs
communicate vie LMA):

 

???? I'm not an LTE expert, but as far as I know, th= e=20 wireless link delay in LTE is small. I read "downlink below 1 ms". If tru= e,=20 this assumption seems artificial.

&n= bsp;

----

[Luis>>] Despite the radi= o=20 access delay due to framing, we have to take into account the MLD process= ing=20 by the MN, as well as no ideal conditions in the radio part (we are in a = HO=20 process where the MN is in the border of a cell, so it is hard to conside= r=20 ideal conditions)

----

 

 

[Luis>>] Best=20 regards,

Luis


Este mensaje se dirige exclusiva= mente a su=20 destinatario. Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n= de correo=20 electr=F3nico en el enlace situado m=E1s abajo.
This message is intend= ed=20 exclusively for its addressee. We only send and receive email on the basi= s of=20 the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

_______________________________________________
multim= ob=20 mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--_000_05C81A773E48DD49B181B04BA21A342A2650EAE486HE113484emea1_-- From lmcm@tid.es Thu Sep 29 00:29:19 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522EE21F8CED for ; Thu, 29 Sep 2011 00:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.909 X-Spam-Level: X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[AWL=2.689, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTTeO6XgQehz for ; Thu, 29 Sep 2011 00:29:18 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 12A2621F8CE4 for ; Thu, 29 Sep 2011 00:29:16 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS9000V2WXCTF@tid.hi.inet> for multimob@ietf.org; Thu, 29 Sep 2011 09:32:05 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 4E.44.02718.4FE148E4; Thu, 29 Sep 2011 09:32:05 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LS9000VJWXGTF@tid.hi.inet> for multimob@ietf.org; Thu, 29 Sep 2011 09:32:04 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Thu, 29 Sep 2011 09:32:05 +0200 Date: Thu, 29 Sep 2011 09:32:04 +0200 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: To: "sarikaya@ieee.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_EkXyMSVvG1g04y2GPB4tvQ)" Accept-Language: es-ES, en-US Thread-topic: [multimob] PMIP MC handover -- some thoughts Thread-index: Acx9ZMDiv7Euv33DQ/KXAveC+/1//gBE8rDy acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7f146d000000a9e-66-4e841ef47ee4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsXCFe9nqPtVrsXP4OQ6NosZH/tYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8frkZeaCox2MFWfeTGNqYJxd2sXIySEhYCIx/8R9FghbTOLC vfVsXYxcHEIC2xkl3r39ywqSEBL4wyix+1gChN3IKLFibyiIzSKgKjHh/jZGEJtNwFBi1s5J YPXCApYS9xdPB7M5BYIlpj9/yQ5iiwhoS+w4tAOsnlmgTOJ2/0M2EJtXwFPiesdlFghbUOLH 5HssEDW5Eq+bFzCD2IwCshIrz59mhJhjJbH62X9WCNtIYtnClewQNTIS/5fvhXpGQGLJnvPM ELaoxMvH/1ghHpvGLDHpz2fGCYyis5Dsm4VkH4RtIPH+3HwoWxtox2soW19i45ezjMjiCxjZ VjGKFScVZaZnlOQmZuakGxjpZWTqZeallmxihERS5g7G5TtVDjEKcDAq8fD+SGr2E2JNLCuu zD3EKMnBpCTKe0m2xU+ILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO+vdUDlvCmJlVWpRfkwKRkO DiUJ3k/iQG2CRanpqRVpmTnAdAGTZuLgBGnnAWp/AjKat7ggMbc4Mx0if4pRlePl76cnGIVY 8vLzUqXEeRWAaUhIAKQoozQPbs4rRnGgg4V52UCyPMCEBzfhFdBwJqDhXwsbQYaXJCKkpBoY 999/zMo4XWLdwVr3jZv0H7clKzMyzj1Tn/hGOJr/qvIZzwwv+0sMdeG/3T7JXFfs9g0KKhYt UmJ/kfx7jliaq1l5lXxmhoq2wvf5u+ZePr1fS7S4aJX6Swu2BQWK5Req5lta8P8z7fM4r91c 93PPxrDNc3zZxPYINi370XA6s3X9xH2LmduUWIozEg21mIuKEwH8MlwtNQMAAA== References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> <4E7BAFC2.5080503@informatik.haw-hamburg.de> Cc: "multimob@ietf.org" , "schmidt@informatik.haw-hamburg.de" Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 07:29:19 -0000 --Boundary_(ID_EkXyMSVvG1g04y2GPB4tvQ) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Hi Behcet, find my opinion below. Regards, Luis ________________________________ De: Behcet Sarikaya [sarikaya2012@gmail.com] Enviado el: mi=E9rcoles, 28 de septiembre de 2011 0:19 Para: LUIS MIGUEL CONTRERAS MURILLO CC: schmidt@informatik.haw-hamburg.de; multimob@ietf.org Asunto: Re: [multimob] PMIP MC handover -- some thoughts Hi all, Sorry but I don't see anything in this mail relevant to what Marco posted= (in the subject line), like: Why FHO-like forwarding between MAGs is beneficial for multicast? [Luis>>] The multicast content forwarding can be beneficial for either stri= ct-real time services or networks with long handover time Does performance really benefit from forwarding? [Luis>>] In the situations above the forwarding can mitigate the service di= sruption, so the performance (QoE) can be improved Is packet re-ordering an issue (forwarded packets between MAGs vs direct packets)? Or is re-ordering resolved on the MAG by means of scheduled delivery to the MN? [Luis>>] There will be probably buffering at both MAG and MN (some dejitter= ing buffer), so reordering would be done probably in both points Maybe CTX of multicast context is sufficient. Proactive CTX may help. Whereas the benefit of reactive CTX needs to be compared against the performance of the Multimob base approach for PMIPv6 [Luis>>] I think there are two dimensions: one is the way the subscription = information is knowledge by the MAG, and the other one is the multicast tra= ffic forwarding. The first one is strictly necessary to optimize the handov= er, while the other helps to imporve it. As you proposed, it makes sense to= implement it as an option, because not all the application take benefit of= it, so an operator can skip it, looking for a more easy to manage access n= etwork. If forwarding between MAGs is not really beneficial, what is the right way = for CTX? [Luis>>] In my opinion you have already provided the way: context transfer = (i.e., multicast subscription info) as mandatory, multicast traffic forward= ing as an option. Regards, Behcet On Tue, Sep 27, 2011 at 5:41 AM, LUIS MIGUEL CONTRERAS MURILLO > wrote: Hi Thomas, Please, find some comments inline. ---------- Forwarded message ---------- From: Thomas C. Schmidt > Date: 2011/9/22 Subject: Re: [multimob] PMIP MC handover -- some thoughts To: Dirk.von-Hugo@telekom.de Cc: multimob@ietf.org MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for current 3G topologies with large delays in the core w/o inter-MAG shortcuts): More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG delay .= .. and "pMAG-nMAG delay =3D< pMAG-LMA-nMAG delay" should always hold. ---- [Luis>>] I don=92t think so. In case of proactive RAMS HO, the pMAG-LMA and= LMA-nMAG flows are part of the registration process, so no additional mess= ages are needed. In case of reactive RAMS HO, the pMAG-LMA messages are specific of the HO o= ptimization process, but LMA-nMAG messages are part of the registration pro= cess. In case of FHO, you need the HI/HACK messages, the MLD Query/Report message= s for forwarding, and the LMA-nMAG messages for registering. So, in the best case, (no multicast forwarding) FHO and RAMS HO have the sa= me number of messages flowing across the network. The different delay can be obtained from the paths among MAGs, or between L= MA-MAG, not from the number of messages involved in the process. Don=92t forget the dependency of the radio part for some of the cases. ---- MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs communicate vie LMA): ???? I'm not an LTE expert, but as far as I know, the wireless link delay i= n LTE is small. I read "downlink below 1 ms". If true, this assumption seem= s artificial. ---- [Luis>>] Despite the radio access delay due to framing, we have to take int= o account the MLD processing by the MN, as well as no ideal conditions in t= he radio part (we are in a HO process where the MN is in the border of a ce= ll, so it is hard to consider ideal conditions) ---- [Luis>>] Best regards, Luis ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_EkXyMSVvG1g04y2GPB4tvQ) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable
Hi Behcet,
 
find my opinion below.
 
Regards,
 
Luis
=  
De: Behcet Sarika= ya [sarikaya2012@gmail.com]
Enviado el: mi=E9rcoles, 28 de septiembre de 2011 0:19
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: schmidt@informatik.haw-hamburg.de; multimob@ietf.org
Asunto: Re: [multimob] PMIP MC handover -- some thoughts

Hi all,
  Sorry but I don't see anything in this mail relevant to what Marco p= osted (in the subject line), like:

Why FHO-like forwarding between MAGs is beneficial for multicast?
[Luis>>] The multicast content = forwarding can be beneficial for either strict-real time services or n= etworks with long handover time
Does performance really benefit from forwarding?
[Luis>>] In the si= tuations above the forwarding can mitigate the service disruption, so the p= erformance (QoE) can be improved
Is packet re-ordering an issue (forwarded packets between MAGs vs direct   packets)? Or is re-ordering
  resolved on the MAG by means of scheduled delivery to the MN?
[Luis>>] There will be probably= buffering at both MAG and MN (some dejittering buffer), so reordering woul= d be done probably in both points
Maybe CTX of multicast context is sufficient. Proactive CTX may help.
  Whereas the benefit of reactive CTX needs to be compared against the=
  performance of the Multimob base approach for PMIPv6
[Luis>>] I think there are two = dimensions: one is the way the subscription information is knowledge by the= MAG, and the other one is the multicast traffic forwarding. The first one = is strictly necessary to optimize the handover, while the other helps to imporve it. As you proposed, it makes sense to im= plement it as an option, because not all the application take benefit of it= , so an operator can skip it, looking for a more easy to manage access netw= ork.
If forwarding between MAGs is not really beneficial, what is the right way = for CTX?
[Luis>>] In my opinion you have= already provided the way: context transfer (i.e., multicast subscription i= nfo) as mandatory, multicast traffic forwarding as an option.

Regards,

Behcet
On Tue, Sep 27, 2011 at 5:41 AM, LUIS MIGUEL CON= TRERAS MURILLO <lmcm@tid.es> wrote:

Hi T= homas,

<= /u> 

Plea= se, find some comments inline.

=  

=  

---------- Forwarded message ----------
From: Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de>
Date: 2011/9/22
Subject: Re: [multimob] PMIP MC handover -- some thoughts=
To: Dirk.von-Hugo@telekom.de
Cc: multimob@ietf.org



 

MN-MAG delay << MAG-LMA delay < MAG-MAG del= ay (as may be typical for
current 3G topologies with large delays in the core w/o inter-MAG
shortcuts):

 

More precisely, you should compare pMAG-LMA-nMAG del= ay to pMAG-nMAG delay ... and "pMAG-nMAG delay =3D< pMAG-LMA-nMAG d= elay" should always hold.

 

MN/MAG delay > MAG-MAG delay > MAG-LMA delay (= as could be achieved in
future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs communicate vie LMA):

 

???? I'm not an LTE expert, but as far as I know, th= e wireless link delay in LTE is small. I read "downlink below 1 ms&quo= t;. If true, this assumption seems artificial.

 

=  


Este mensaje se dirige exclu= sivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo = y recepci=F3n de correo electr=F3nico en el enlace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at.
= http://www.tid.es/ES/PAGINAS/disclaimer.aspx

_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob



Este mensaje se dirige exclu= sivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo = y recepci=F3n de correo electr=F3nico en el enlace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_EkXyMSVvG1g04y2GPB4tvQ)-- From lmcm@tid.es Thu Sep 29 00:52:32 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F328A21F8B09 for ; Thu, 29 Sep 2011 00:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIlie8TEt432 for ; Thu, 29 Sep 2011 00:52:31 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB421F8B0A for ; Thu, 29 Sep 2011 00:52:30 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS90032LY08WM@tid.hi.inet> for multimob@ietf.org; Thu, 29 Sep 2011 09:55:20 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id AE.2B.08217.864248E4; Thu, 29 Sep 2011 09:55:20 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LS90032DY08WM@tid.hi.inet> for multimob@ietf.org; Thu, 29 Sep 2011 09:55:20 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Thu, 29 Sep 2011 09:55:20 +0200 Date: Thu, 29 Sep 2011 09:55:20 +0200 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <4E826551.5080209@informatik.haw-hamburg.de> To: "Thomas C. Schmidt" , "sarikaya@ieee.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: [multimob] PMIP MC handover -- some thoughts Thread-index: Acx9cqeZDAhhLLcQT+Glc68NQx2fWgBCMXVH acceptlanguage: es-ES, en-US X-AuditID: 0a5f4068-b7f816d000002019-b8-4e842468fda4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42Lhinfg0s1QafEzeDBV3mLGxz4WB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlHLp2kbXgjHjF9d1GDYxbhboYOTkkBEwkZj28zgRhi0lcuLee rYuRi0NIYCOjxMIJS1ggnD+MEjvO9jBDOI2MErs+L2cHaWERUJU4uvERI4jNJmAoMWvnJFYQ W1jAUuL+4ulANgcHJ5A9+501SFhEIE3iafsOFhCbWSBc4s7/G2BjeAU8JW4t2MgMYQtK/Jh8 D6pGT+Ljn9uMELa2xJN3F8DGMwrISqw8f5oRYqaVxOpn/1khbCOJ95vmQNXISPxfvpcF4jMB iSV7zjND2KISLx//Y4X45SizRMPsE8wTGMVmIdk9C8nuWUh2L2BkXsUoVpxUlJmeUZKbmJmT bmCol5Gpl5mXWrKJERIXGTsYl+9UOcQowMGoxMP7I6nZT4g1say4MvcQoyQHk5Io7w+lFj8h vqT8lMqMxOKM+KLSnNTiQ4wSHMxKIry/1gGV86YkVlalFuXDpGQ4OJQkeD+JA7UJFqWmp1ak ZeYAox8mzcTBCdLOA9QuqAxUw1tckJhbnJkOkT/FqMrx8vfTE4xCLHn5ealS4ry/QfYLgBRl lObBzXnFKA50sDDvJ5AsDzB9wU14BTScCWj418JGkOEliQgpqQZGXh9OiZNe8yUlLoqVeO8t jArUvpamqWtsW/BCsWkVE/+EH3NK1/qs/FZ1pM7l7vb+dToTJedNYAu8r8sUne/hNHHjNb5f cYs2nRCY7CN7e8qlhEhrq00Hfmo13BaMlno0PV+haMm6dV9NXh1pe37z6dq9RlfSQyvzlJfM quwT7bI4VmN/7egHJZbijERDLeai4kQAVGuMTxwDAAA= References: <69756203DDDDE64E987BC4F70B71A26D1CE5C498@DAPHNIS.office.hd> <05C81A773E48DD49B181B04BA21A342A26469FFD35@HE113484.emea1.cds.t-internal.com> <4E7BAFC2.5080503@informatik.haw-hamburg.de> <4E826551.5080209@informatik.haw-hamburg.de> Cc: "multimob@ietf.org" , Behcet Sarikaya Subject: Re: [multimob] PMIP MC handover -- some thoughts X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 07:52:32 -0000 Hi Thomas, some additional comments (I'm not sure if I understand correctly your comme= nts) Best regards, Luis ________________________________________ > > */[Luis>>] I don=92t think so. In case of proactive RAMS HO, the > pMAG-LMA and LMA-nMAG flows are part of the registration process, so > no additional messages are needed.____/* > Well, you need to signal the HO - if this happens a priory (in a predictive mode), then re-directions happens asynchronously, possibly in parallel to the Phy handover. This is the same in FHO. If RAMs anchors signaling at the LMA, then signaling is either pMAG-LMA-nMAG or nMAG-LMA-nMAG, both being of the same delay magnitude. [Luis>>] What I mean is that the HO in proactive RAMS is embedded in the de= -registration process, so no additional messages are there. The info is pig= gybacked. > > */[Luis>>] Despite the radio access delay due to framing, we have to > take into account the MLD processing by the MN, as well as no ideal > conditions in the radio part (we are in a HO process where the MN is > in the border of a cell, so it is hard to consider ideal > conditions)____/* > > */----/*____ > For the radio, I guess we can assume normal behavior which is only slightly slower than a normal 100 Mbit LAN link. For the MLD processing: in FHO we don't have an MLD processing at MN in the normal predictive mode and no signaling on the wireless link. So these possible issues don't apply. In the reactive mode, one could do without the MN-local MLD processing ... this is only applied for the sake of acceleration. [Luis>>] But the MAGs needs to know what are the channels the MN is subscri= bed to before asking for them to the pMAG, so you are forced to wait for th= e MLD Report coming from the MN, otherwise the MAG even does nto know if th= e MN has any active subscription (you don't have the multicast context at n= MAG, so, what can the nMAG request to the pMAG?) The key comparison is not the wireless link, but the routing distances pMAG/pAR <-> nMAG/nAR versus MAG <-> LMA ... in addition of course FHO is not bound to PMIP. [Luis>>] I don't think so by reason above, for sure in the case of reactive= HO. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt =B0 Hamburg University of Applied Sciences Berliner Tor 7= =B0 =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452= =B0 =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409= =B0 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx