Hello all,
=A0 The messag= e below was sent on Sept. 15. Since then we have not received any reviews.<= br> This mail is a call to Multimob and all potential presenters in IETF 82 to = please take some time and make a review of our WG draft. Remember Multimob = is not just for pushing your own draft. We need reviews of WG drafts. Certa= inly we need reviews of potential WG drafts as well.

Call to action!

Behcet

Hello Mboned Folks,

=A0 = In Multimob we have a WG draft on tuning MLD-IGMP in mobile environments.

Can you please take some time and review this document and give us= some good feedback?

You can post your review on either or both Mboned and Multimob lists.<= /div>

Regards,

Behcet

--20cf3005128081b8d904b021d360-- From contreras.uc3m@gmail.com Thu Oct 27 02:10: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 5E99221F891D for ; Thu, 27 Oct 2011 02:10:35 -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 8UHmw1z9EvY3 for ; Thu, 27 Oct 2011 02:10:34 -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 E686121F886A for ; Thu, 27 Oct 2011 02:10:33 -0700 (PDT) Received: by vws5 with SMTP id 5so2621711vws.31 for ; Thu, 27 Oct 2011 02:10:21 -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 :content-type; bh=q4uNjKKhT5QzfrcMz6dwvMxntHiTP3iz8F0pyvWSEl4=; b=PSFcbnhPIgSNoHmENXwWGNGBzgNHNnKkMc/ybKbl7EFG35Ipi79pp+jfJTZpJEhFm1 aQ1dLYma1s7ul04hVKJCYB23/SMhdYkkYDske2xNDcFf8RYdO4IuMtVwe+bAsjyIOLXq PWaCZxDClNUAT9+o+bj3f1lVEzXbHFf8ICSVU= MIME-Version: 1.0 Received: by 10.52.21.71 with SMTP id t7mr746869vde.131.1319706621370; Thu, 27 Oct 2011 02:10:21 -0700 (PDT) Received: by 10.52.109.4 with HTTP; Thu, 27 Oct 2011 02:10:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Oct 2011 11:10:21 +0200 Message-ID: From: "Luis M. Contreras" To: multimob@ietf.org Content-Type: multipart/alternative; boundary=20cf307abe0b5fe3be04b0442474 Subject: Re: [multimob] 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, 27 Oct 2011 09:10:35 -0000 --20cf307abe0b5fe3be04b0442474 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Please find below a number of comments regarding draft-ietf-multimob-igmp-mld-tuning-01. Comment #1.- In chapter 1 (Introduction), on the first paragraph you state the following: "However, wireless access technologies operate on a shared medium or a point-to-point link with limited frequency and bandwidth." The word "frequency" in the sentence is not appropriate, in my opinion. I think it is more adequate to talk about "spectral capacity" or simply "spectrum". Comment #2.- In chapter 1 (Introduction), on the first paragraph you state the following: "Slow multicast service activation following a join may incur additional delay in receiving multicast packets and degrade reception quality". Instead of the term "reception quality" in my opinion, it would be more adequate to talk about "quality perception", because the reception could be good (from the signal point of view) but the quality poor (from the content point of view). Comment #3.- In chapter 1 (Introduction), on the second paragraph you state the following: "For example, when bi-directional tunnel is used with the mobility entities described in [14][11] in place, the mobile host experiences additional latency, because the round-trip time using bi-directional tunnel between mobility entities is larger comparing to the case that a host and an upstream router attach to a LAN." However, the case of PMIPv6 described in ref [11] in your draft is a little bit special. Due that the MAG is a MLD proxy, in case of the content demanded by the MN is already demanded by another MN attached to the MAG, the biderectional tunnel does not participate on the latency perceived by the mobile, because the content is already available on MAG; but the MN could yet experiencing long delay (due to radio issues, for instance). Comment #4.- In chapter 1 (Introduction), on the third paragraph you quote two sentences but there is not reference to the source where the sentences come from. Comment #5.- In chapter 3 (Explicit tracking), on the third paragraph you mention: "Enabling the explicit tracking function is advantageous for mobile multicast, but the function requires additional processing capability and a possibly large memory for routers to keep all membership status." In the PMIPv6 case, the point-to-point nature of the link seems to simplify this. Due that the MAG will maintain the multicast status refered to the p-t-p link, it seems easy to check the subscription of a certain MN just checking the multicast status of the associated link. So, there are not strong requirements on it. Could you confirm this assumption? Comment #6.- In chapter 3 (Explicit tracking), on the third paragraph you mention: "Therefore, in this document, we propose that adjacent upstream multicast routers SHOULD enable the explicit tracking function...". It is not clear to me if you are referring here to the MAG or to the LMA. When I read this sentence I think on the LMA. But, if so, I don't know why the LMA should maintain an explicit tracking of thier downstream interfaces, because the LMA has only the vision of the MLD proxies (MAGs), not the vision of the end users. Comment #7.- Regarding the general query interval, you propose in some case a timer higher than the default (150s instead of 125). If the MAG asks the MN every 150s, but the LMA is asking the MAG each 125s, we are wasting resources at MAG. This assymetry is not good from my point of view. I would suggest to align the LMA-MAG query interval to the highest value of the MAG-MN timer.Take into account that the variability in the multicast channels subscription among LMA and MAG will be less than the one among MAG and MN. Comment #8.- In section 4.2 (Tuning the MLD Query response interval), you differientate values for wireless links according to their characteristics. One value is assigned to lossy links. However, for every kind of link, when the MN moves and it makes a handover, the link will be necessarily lossy because the MN is at the border of a cell, probably with not optimial conditions. Additionally, as the MN moves, the wireless link characteristics can changed from good to bad. So, do you suggest to dynamically change this parameter as function of transmission properties, or situations (HO vs no-HO) as stated at the end of section 4.6? Comment#9.- In section 4.4 (Tuning Startup Query interval), you mention: "The default value is 1/4 of [Query Interval]". I would include the value in seconds for completeness. Comment#10.- About the Startup Query interval behavior in the base solution: in RFC 6224 two MLD Queries are triggered, one by the kernel, once the MN is attaches and the p-tp link is up, and one by the MLD proxy instance associated by the MAG for that MN. Due that the MN will answer one of them (either the one of the kernel or the one of the instance), what would be the behavior for the other one? Should either the kernel or the instance re-sending the General Query as much times as determined by the startup query interval? Comment #11.- In Appendix A, second paragraph you talk about unicast queries. I think that this is not a great advantage for PMIPv6 because of the p-t-p nature of the link (only one MN wil be queried either by unicas or multicast). Maybe this could be clarified in the text. Comment #12.- In Appendix A, at the end of the page you put in brackets:"(See Appendix A <#appendix-A> for the detail)" This should be deleted, I guess. Best regards, Luis 2011/10/25 Behcet Sarikaya > Hello all, > The message below was sent on Sept. 15. Since then we have not received > any reviews. > This mail is a call to Multimob and all potential presenters in IETF 82 to > please take some time and make a review of our WG draft. Remember Multimob > is not just for pushing your own draft. We need reviews of WG drafts. > Certainly we need reviews of potential WG drafts as well. > > Call to action! > > Behcet > > Hello Mboned Folks, > In Multimob we have a WG draft on tuning MLD-IGMP in mobile environments. > Can you please take some time and review this document and give us some > good feedback? > You can post your review on either or both Mboned and Multimob lists. > > Regards, > > Behcet > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > --20cf307abe0b5fe3be04b0442474 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Please find below a number of comments regarding dra= ft-ietf-multimob-igmp-mld-tuning-01.

Comment #1.- In chapter = 1 (Introduction), on the first paragraph you state the following: "How= ever, wireless access technologies operate on a shared medium or a point-to= -point link with limited frequency and bandwidth." The word "freq= uency"=A0 in the sentence is not appropriate, in my opinion. I think i= t is more adequate to talk about "spectral capacity" or simply &q= uot;spectrum".

Comment #2.- In chap= ter 1 (Introduction), on the first paragraph you state the following: "= ;Slow multicast service activation following a join may incur additional de= lay in receiving multicast packets and degrade reception quality". Ins= tead of the term "reception quality" in my opinion, it would be m= ore adequate to talk about "quality perception", because the rece= ption could be good (from the signal point of view) but the quality poor (f= rom the content point of view).

Comment #3.- In chapter 1 (Introduction), on the second paragraph= you state the following: "For example, when bi-directional tunnel is = used with the mobility entities described in [14][11] in place, the mobile = host experiences additional latency, because the round-trip time using bi-d= irectional tunnel between mobility entities is larger comparing to the case= that a host and an upstream router attach to a LAN."

However, the case of PMIPv6 described in ref [11] in= your draft is a little bit special. Due that the MAG is a MLD proxy, in ca= se of the content demanded by the MN is already demanded by another MN atta= ched to the MAG, the biderectional tunnel does not participate on the laten= cy perceived by the mobile, because the content is already available on MAG= ; but the MN could yet experiencing long delay (due to radio issues, for in= stance).

Comment #4.- In chap= ter 1 (Introduction), on the third paragraph you=20 quote two sentences but there is not reference to the source where the=20 sentences come from.

Comment #5.-=A0 In chapter 3 (Explici= t tracking), on the third paragraph you mention: "Enabling the explici= t tracking function is advantageous for mobile multicast, but the function requires additional processing capability and a possibly large memory for routers to keep all membership status." In the PMIPv6 case, the point-to-point nature of the link = seems to simplify this. Due that the MAG will maintain the multicast status= refered to the p-t-p link, it seems easy to check the subscription of a ce= rtain MN just checking the multicast status of the associated link. So, the= re are not strong requirements on it. Could you confirm this assumption?
Comment #6.- In chapter 3 (Explicit tracking), on the third paragraph = you mention: "Therefore, in this document, we propose that adjacent up= stream multicast routers SHOULD enable the explicit tracking function...".= It is not clear to me if you are referring here to the MAG or to the LMA. = When I read this sentence I think on the LMA. But, if so, I don't know = why the LMA should maintain an explicit tracking of thier downstream interf= aces, because the LMA has only the vision of the MLD proxies (MAGs), not th= e vision of the end users.

Comment #7.- Regarding the general query interval, you propose in some = case a timer higher than the default (150s instead of 125). If the MAG asks= the MN every 150s, but the LMA is asking the MAG each 125s, we are wasting= resources at MAG. This assymetry is not good from my point of view. I woul= d suggest to align the LMA-MAG query interval to the highest value of the M= AG-MN timer.Take into account that the variability in the multicast channel= s subscription among LMA and MAG will be less than the one among MAG and MN= .

Comment #8.- In section 4.2 (Tuning the MLD Query response interval), y= ou differientate values for wireless links according to their characteristi= cs. One value is assigned to lossy links. However, for every kind of link, = when the MN moves and it makes a handover, the link will be necessarily los= sy because the MN is at the border of a cell, probably with not optimial co= nditions. Additionally, as the MN moves, the wireless link characteristics = can changed from good to bad. So, do you suggest to dynamically change this= parameter as function of transmission properties, or situations (HO vs no-= HO) as stated at the end of section 4.6?

Comment#9.- In section 4.4 (Tuning Startup Query interval), you mention= : "The default value is 1/4 of [Query Interval]". I would include the value in seconds for completeness.<= br>
Comment#10.- About the Startup Query interval behavior in the base s= olution: in RFC 6224 two MLD Queries are triggered, one by the kernel, once= the MN is attaches and the p-tp link is up, and one by the MLD proxy insta= nce associated by the MAG for that MN. Due that the MN will answer one of t= hem (either the one of the kernel or the one of the instance), what would b= e the behavior for the other one? Should either the kernel or the instance = re-sending the General Query as much times as determined by the startup que= ry interval?

Comment #11.- In Appendix A, second paragraph you talk about unicast qu= eries. I think that this is not a great advantage for PMIPv6 because of the= p-t-p nature of the link (only one MN wil be queried either by unicas or m= ulticast). Maybe this could be clarified in the text.

Comment #12.- In Appendix A, at the end of the page you put in brackets= :"(See Appendix A for the detail)" Th= is should be deleted, I guess.

Best regards,

Luis

2011/10/25 Behcet Sarikaya <sarikaya2012@gmail.com>

Hello all,
=A0 The message = below was sent on Sept. 15. Since then we have not received any reviews. This mail is a call to Multimob and all potential presenters in IETF 82 to = please take some time and make a review of our WG draft. Remember Multimob = is not just for pushing your own draft. We need reviews of WG drafts. Certa= inly we need reviews of potential WG drafts as well.

Call to action!

Behcet

Hello Mboned Folks,
=A0 = In Multimob we have a WG draft on tuning MLD-IGMP in mobile environments.
Can you please take some time and review this document and give us= some good feedback?

You can post your review on either or both Mboned and Multimob lists.<= /div>

Regards,

Behcet

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

--20cf307abe0b5fe3be04b0442474-- From lmcm@tid.es Sun Oct 30 03:28: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 4E96221F8AC9 for ; Sun, 30 Oct 2011 03:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.995 X-Spam-Level: X-Spam-Status: No, score=-3.995 tagged_above=-999 required=5 tests=[AWL=2.604, BAYES_00=-2.599, 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 JILTCLqaS+ux for ; Sun, 30 Oct 2011 03:28:47 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1BC21F87D3 for ; Sun, 30 Oct 2011 03:28:47 -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 <0LTV00NJIJRW0Y@tid.hi.inet> for multimob@ietf.org; Sun, 30 Oct 2011 11:28:44 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 75.67.02652.CD62DAE4; Sun, 30 Oct 2011 11:28:44 +0100 (CET) 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 <0LTV00NJBJRV0Y@tid.hi.inet> for multimob@ietf.org; Sun, 30 Oct 2011 11:28:44 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Sun, 30 Oct 2011 11:28:43 +0100 Date: Sun, 30 Oct 2011 11:24:40 +0100 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <20111030102418.32581.15008.idtracker@ietfa.amsl.com> To: "multimob@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: New Version Notification for draft-zuniga-multimob-pmipv6-ropt-01.txt Thread-index: AcyW7haWBnyKQKlWTjmTUm4a+UMmHAAAAtpo acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7f2b6d000000a5c-dc-4ead26dcba04 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42Lhivcz1L2jttbPYOp3HosZH/tYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXfmNcaCMyIVv1vnszQwdoh0MXJwSAiYSFw/ZNDFyAlkiklc uLeeDcQWEtjGKHF6gVEXIxeQ/ZtR4uPrr+wQTiOjxJUnO1lAmlkEVCV2XWIGaWATMJSYtXMS K0hYWCBEYs2ZUpAwp4CTxOd721hAbBEBbYk3L/8wgYxhFjjAJLG+bz07SD2vgKfEpqv6IDW8 AoISPybfA5vOLKAuMWVKLkiYWUBRYtqiBkYQm1FAVmLl+dOMECNDJXa3tDFD2EYS836fY4Go kZH4v3wvC8RbAhJL9pxnhrBFJV4+/scK8aKjxNuXv5gmMIrNQrJ5FsLmWUg2L2BkXsUoVpxU lJmeUZKbmJmTbmCkl5Gpl5mXWrKJERINmTsYl+9UOcQowMGoxMP74uEqPyHWxLLiytxDjJIc TEqivC9U1/oJ8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuFdtXeNnxBvSmJlVWpRPkxKhoNDSYJX HRi5QoJFqempFWmZOcCYh0kzcXCCtPMAtauA1PAWFyTmFmemQ+RPMapyHN+24BSjEEtefl6q lDivAUiRAEhRRmke3JxXjOJABwvzaoJkeYBJC27CK6DhTEDD+16B3FZckoiQkmpgZH/zZoZx w7bbOhLR0WuvKUe6HeR9J8KmqpbwV4qB06mgzVRrnrBU06kzrZeKa9oWVBeftMmVCnJwW7Dk xR+9zFk/9kxQXfPD0/b2punPVix8feG6tNate3N/896s+m+xtUpsn9HKn11lvm8VGvf8s6g/ VviMP8hhZnt8+1rld3dalz5yEtk9SYmlOCPRUIu5qDgRAAlI6RsXAwAA References: <20111030102418.32581.15008.idtracker@ietfa.amsl.com> Cc: "isoto@dit.upm.es" , "sijeon@dcn.ssu.ac.kr" , "yhkim@dcn.ssu.ac.kr" Subject: [multimob] RV: New Version Notification for draft-zuniga-multimob-pmipv6-ropt-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: Sun, 30 Oct 2011 10:28:48 -0000 RGVhciBjb2xsZWFndWVzLA0KDQpJIGp1c3Qgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBv ZiBkcmFmdC16dW5pZ2EtbXVsdGltb2ItcG1pcHY2LXJvcHQsIHdpdGggb25seSBtaW5vciBlZGl0 b3JpYWwgY2hhbmdlcy4NCg0KUmVnYXJkcywNCg0KTHVpcw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkRlOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2lu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCkVudmlhZG8gZWw6IGRvbWluZ28sIDMwIGRlIG9jdHVi cmUgZGUgMjAxMSAxMToyNA0KUGFyYTogTFVJUyBNSUdVRUwgQ09OVFJFUkFTIE1VUklMTE8NCkND OiBzaWplb25AZGNuLnNzdS5hYy5rcjsgeWhraW1AZGNuLnNzdS5hYy5rcjsganVhbmNhcmxvcy56 dW5pZ2FAaW50ZXJkaWdpdGFsLmNvbTsgY2piY0BpdC51YzNtLmVzOyBMVUlTIE1JR1VFTCBDT05U UkVSQVMgTVVSSUxMTw0KQXN1bnRvOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXp1bmlnYS1tdWx0aW1vYi1wbWlwdjYtcm9wdC0wMS50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LXp1bmlnYS1tdWx0aW1vYi1wbWlwdjYtcm9wdC0wMS50eHQgaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMdWlzIENvbnRyZXJhcyBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtenVuaWdhLW11bHRpbW9i LXBtaXB2Ni1yb3B0DQpSZXZpc2lvbjogICAgICAgIDAxDQpUaXRsZTogICAgICAgICAgIE11bHRp Y2FzdCBNb2JpbGl0eSBSb3V0aW5nIE9wdGltaXphdGlvbnMgZm9yIFByb3h5IE1vYmlsZSBJUHY2 DQpDcmVhdGlvbiBkYXRlOiAgIDIwMTEtMTAtMzANCldHIElEOiAgICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDI5DQoNCkFic3RyYWN0Og0KICAgVGhlIE1V TFRJTU9CIGdyb3VwIGhhcyBzcGVjaWZpZWQgYSBiYXNlIHNvbHV0aW9uIHRvIHN1cHBvcnQgSVAN CiAgIG11bHRpY2FzdGluZyBpbiBhIFBNSVB2NiBkb21haW4gW1JGQzYyMjRdLiBJbiB0aGlzIGRv Y3VtZW50LCBzb21lDQogICBlbmhhbmNlbWVudHMgYXJlIHByb3Bvc2VkIHRvIHRoZSBiYXNlIHNv bHV0aW9uLiBUaGVzZSBlbmhhbmNlbWVudHMNCiAgIGluY2x1ZGUgdGhlIHVzZSBvZiBhIG11bHRp Y2FzdCB0cmVlIG1vYmlsaXR5IGFuY2hvciBhcyB0aGUNCiAgIHRvcG9sb2dpY2FsIGFuY2hvciBw b2ludCBmb3IgbXVsdGljYXN0IHRyYWZmaWMsIGFzIHdlbGwgYXMgYSBkaXJlY3QNCiAgIHJvdXRp bmcgb3B0aW9uIHdoZXJlIHRoZSBNQUcgY2FuIHByb3ZpZGUgYWNjZXNzIHRvIG11bHRpY2FzdCBj b250ZW50DQogICBpbiB0aGUgbG9jYWwgbmV0d29yay4gVGhlc2UgZW5oYW5jZW1lbnRzIHByb3Zp ZGUgYmVuZWZpdHMgc3VjaCBhcw0KICAgcmVkdWNpbmcgbXVsdGljYXN0IHRyYWZmaWMgcmVwbGlj YXRpb24gYW5kIHN1cHBvcnRpbmcgZGlmZmVyZW50DQogICBQTUlQdjYgZGVwbG95bWVudHMgc2Nl bmFyaW9zLg0KDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCkVzdGUgbWVuc2FqZSBz ZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRh ciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVj dHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBp cyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFu ZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdC4NCmh0 dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From lmcm@tid.es Sun Oct 30 05:46:55 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 582AE21F8770 for ; Sun, 30 Oct 2011 05:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.863 X-Spam-Level: X-Spam-Status: No, score=-4.863 tagged_above=-999 required=5 tests=[AWL=1.736, BAYES_00=-2.599, 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 tTUNEbnQJpuY for ; Sun, 30 Oct 2011 05:46:54 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1B63821F84E5 for ; Sun, 30 Oct 2011 05:46:54 -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 <0LTV00IYTQ65DR@tid.hi.inet> for multimob@ietf.org; Sun, 30 Oct 2011 13:46:53 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 00.B7.02652.D374DAE4; Sun, 30 Oct 2011 13:46:53 +0100 (CET) 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 <0LTV00IYOQ64DR@tid.hi.inet> for multimob@ietf.org; Sun, 30 Oct 2011 13:46:52 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Sun, 30 Oct 2011 13:46:52 +0100 Date: Sun, 30 Oct 2011 13:46:51 +0100 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <20111030124004.31491.73379.idtracker@ietfa.amsl.com> To: "multimob@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: New Version Notification for draft-contreras-multimob-rams-02.txt Thread-index: AcyXAQ1Q4tEg6G38QO63w5xQ0Vq7YAAAA3MS acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7f2b6d000000a5c-a6-4ead473d236e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42Lhivcz1LV1X+tnsOIvp8WMj30sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+LP1JGvBIYmK+zuaWRoYP4h3MXJySAiYSDxfvpMVwhaTuHBv PVsXIxeHkMA2RonWpyeYIJzfjBLbHn9ih3AaGSWeT/nIDNLCIqAqMePxTCYQm03AUGLWzklg o4QF/CSO7e8Ai3MKOElMmjqPEcQWEdCWePPyD1icGajmysp/YPW8Ap4Suy72MEPYghI/Jt9j 6WLkAKpRl5gyJReiXFFi2qIGsDGMArISK8+fhhrpL/Fi53ImCNtI4t+XncwQNTIS/5fvZYH4 TEBiyZ7zzBC2qMTLxyBrOYB+cZT48TF6AqPYLCSLZyEsnoVk8QJG5lWMYsVJRZnpGSW5iZk5 6QZGehmZepl5qSWbGCExkbmDcflOlUOMAhyMSjy8Lx6u8hNiTSwrrsw9xCjJwaQkyivlttZP iC8pP6UyI7E4I76oNCe1+BCjBAezkgjvqr1r/IR4UxIrq1KL8mFSMhwcShK8U0HaBItS01Mr 0jJzgJEPk2bi4ARp5wFqv+gKVMNbXJCYW5yZDpE/xajKcWzd4lOMQix5+XmpUuK8SSCDBECK Mkrz4Oa8YhQHOliYtxskywNMXXATXgENZwIa3vcK5LbikkSElFQD44oAh+ub4/c3ndtoc/NJ 8sRDC65amcrvaLlmffVldF/3hBoV5pnCoV9m8P5bfTDIVUhqw72GUOuI61N5b15jaLopl1/W e+Pztxn85XoLtwc979h06cLS+ScNjtsHsvMq1abNyqyqVi9KmuwzZRanboqW18k5Fc90VP3W pfP8e+701X9BRInRVCWW4oxEQy3mouJEAAVbn7EaAwAA References: <20111030124004.31491.73379.idtracker@ietfa.amsl.com> Cc: "isoto@dit.upm.es" Subject: [multimob] RV: New Version Notification for draft-contreras-multimob-rams-02.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: Sun, 30 Oct 2011 12:46:55 -0000 RGVhciBjb2xsZWFndWVzLA0KDQp3ZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRo ZSBkcmFmdCBlbnRpdGxlZCAiUmFwaWQgYWNxdWlzaXRpb24gb2YgdGhlIE1OIG11bHRpY2FzdCBz dWJzY3JpcHRpb24gYWZ0ZXIgaGFuZG92ZXIiLg0KDQpUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGlu IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtY29udHJlcmFzLW11bHRpbW9iLXJhbXMtMDIu dHh0Lg0KDQpBcyBuZXcgY29udGVudCB3ZSBoYXZlIGludHJvZHVjZSBhIHNlY3Rpb24gZGVzY3Jp YmluZyB0aGUgYmVuZWZpdHMgdGhhdCBjYW4gYmUgZXhwZWN0ZWQgaW4gY2FzZSB0aGUgcmFkaW8g YWNjZXNzIHRlY2hub2xvZ3kgcHJvdmlkZXMgbGF5ZXItMiB0cmlnZ2VycyB0byBkZXRlY3QgTU4n cyBtb3ZlbWVudC4gU29tZSBvdGhlciBtaW5vciBlZGl0b3JpYWwgY2hhbmdlcyBoYXMgYmVlbiBp bnRyb2R1Y2VkIGFsb25nIHRoZSB0ZXh0Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkx1aXMNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRlOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCkVudmlhZG8gZWw6IGRvbWluZ28s IDMwIGRlIG9jdHVicmUgZGUgMjAxMSAxMzo0MA0KUGFyYTogTFVJUyBNSUdVRUwgQ09OVFJFUkFT IE1VUklMTE8NCkNDOiBpc290b0BkaXQudXBtLmVzOyBjamJjQGl0LnVjM20uZXM7IExVSVMgTUlH VUVMIENPTlRSRVJBUyBNVVJJTExPDQpBc3VudG86IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtY29udHJlcmFzLW11bHRpbW9iLXJhbXMtMDIudHh0DQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1jb250cmVyYXMtbXVsdGltb2ItcmFtcy0wMi50eHQgaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMdWlzIENvbnRyZXJhcyBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtY29udHJlcmFzLW11bHRp bW9iLXJhbXMNClJldmlzaW9uOiAgICAgICAgMDINClRpdGxlOiAgICAgICAgICAgUmFwaWQgYWNx dWlzaXRpb24gb2YgdGhlIE1OIG11bHRpY2FzdCBzdWJzY3JpcHRpb24gYWZ0ZXIgaGFuZG92ZXIN CkNyZWF0aW9uIGRhdGU6ICAgMjAxMS0xMC0zMA0KV0cgSUQ6ICAgICAgICAgICBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMzENCg0KQWJzdHJhY3Q6DQogICBBIG5ldyBw cm9wb3NhbCBpcyBwcmVzZW50ZWQgZm9yIHNwZWVkaW5nIHVwIHRoZSBhY3F1aXNpdGlvbiBieSB0 aGUNCiAgIE1BRyBvZiB0aGUgTU4mIzM5O3MgYWN0aXZlIG11bHRpY2FzdCBzdWJzY3JpcHRpb24g aW5mb3JtYXRpb24sIGluIG9yZGVyDQogICB0byBhY2NlbGVyYXRlIHRoZSBtdWx0aWNhc3QgZGVs aXZlcnkgdG8gdGhlIE1OIGFmdGVyIGEgaGFuZG92ZXIuIFRvDQogICBkbyB0aGF0LCBhbiBleHRl bnNpb24gdG8gdGhlIGN1cnJlbnQgUE1JUHY2IHByb3RvY29sIGlzIHByb3Bvc2VkLiBUaGUNCiAg IHNvbHV0aW9uIGRlc2NyaWJlZCBpbiB0aGlzIG1lbW8gaXMgbm90IG9ubHkgYXBwbGljYWJsZSB0 byB0aGUgYmFzZQ0KICAgc29sdXRpb24gZm9yIG11bHRpY2FzdCBzdXBwb3J0IGluIFBNSVB2Niwg YnV0IGFsc28gaXQgY2FuIGJlIGFwcGxpZWQNCiAgIHRvIG90aGVyIHNvbHV0aW9ucyBlbnZpc2lv bmVkIGFzIHBvc3NpYmxlIGFyY2hpdGVjdHVyYWwgZXZvbHV0aW9ucyBvZg0KICAgaXQuIEZ1cnRo ZXJtb3JlLCBpdCBpcyBhbHNvIGluZGVwZW5kZW50IG9mIHRoZSByb2xlIHBsYXllZCBieSB0aGUg TUFHDQogICB3aXRoaW4gdGhlIG11bHRpY2FzdCBuZXR3b3JrIChlaXRoZXIgYWN0aW5nIGFzIE1M RCBwcm94eSBvciBtdWx0aWNhc3QNCiAgIHJvdXRlcikuDQoNCg0KDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0 aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSBy ZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOh cyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFk ZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0 aGUgdGVybXMgc2V0IG91dCBhdC4NCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xh aW1lci5hc3B4DQo= From asaeda@sfc.wide.ad.jp Sun Oct 30 23:01:09 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 8DCB121F8484 for ; Sun, 30 Oct 2011 23:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 4dWlexDNkOok for ; Sun, 30 Oct 2011 23:01:08 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 485C021F8C75 for ; Sun, 30 Oct 2011 23:00:44 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:200:1c0:2014:5a55:caff:fef6:4c5]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5EBAB278075; Mon, 31 Oct 2011 15:00:43 +0900 (JST) Date: Mon, 31 Oct 2011 15:00:39 +0900 (JST) Message-Id: <20111031.150039.127407828.asaeda@sfc.wide.ad.jp> To: contreras.uc3m@gmail.com From: Hitoshi Asaeda In-Reply-To: References: 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] 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: Mon, 31 Oct 2011 06:01:09 -0000 Hi Luis, Thank you for your comments. > Please find below a number of comments regarding > draft-ietf-multimob-igmp-mld-tuning-01. > > Comment #1.- In chapter 1 (Introduction), on the first paragraph you state > the following: "However, wireless access technologies operate on a shared > medium or a point-to-point link with limited frequency and bandwidth." The > word "frequency" in the sentence is not appropriate, in my opinion. I think > it is more adequate to talk about "spectral capacity" or simply "spectrum". Ok, we'll change to "spectrum". > Comment #2.- In chapter 1 (Introduction), on the first paragraph you state > the following: "Slow multicast service activation following a join may incur > additional delay in receiving multicast packets and degrade reception > quality". Instead of the term "reception quality" in my opinion, it would be > more adequate to talk about "quality perception", because the reception > could be good (from the signal point of view) but the quality poor (from the > content point of view). I assume you are saying "playback quality", but improving playback quality is not the target of this draft. I think "reception quality" is hence appropriate. > Comment #3.- In chapter 1 (Introduction), on the second paragraph you state > the following: "For example, when bi-directional tunnel is used with the > mobility entities described in [14][11] in place, the mobile host > experiences additional latency, because the round-trip time using > bi-directional tunnel between mobility entities is larger comparing to the > case that a host and an upstream router attach to a LAN." > > However, the case of PMIPv6 described in ref [11] in your draft is a little > bit special. Due that the MAG is a MLD proxy, in case of the content > demanded by the MN is already demanded by another MN attached to the MAG, > the biderectional tunnel does not participate on the latency perceived by > the mobile, because the content is already available on MAG; but the MN > could yet experiencing long delay (due to radio issues, for instance). The paragraph mentions that the consideration of long delay due to the tunnel link condition, not a radio link. I don't think a bad radio condition will give long delay of IGMP/MLD message transmission. Doesn't it just drop the message? > Comment #4.- In chapter 1 (Introduction), on the third paragraph you quote > two sentences but there is not reference to the source where the sentences > come from. Right, I remove this. > Comment #5.- In chapter 3 (Explicit tracking), on the third paragraph you > mention: "Enabling the explicit tracking function is advantageous for mobile > multicast, but the function requires additional processing capability and a > possibly large memory for routers to keep all membership status." In the > PMIPv6 case, the point-to-point nature of the link seems to simplify this. > Due that the MAG will maintain the multicast status refered to the p-t-p > link, it seems easy to check the subscription of a certain MN just checking > the multicast status of the associated link. So, there are not strong > requirements on it. Could you confirm this assumption? This draft does not only focus on PMIPv6. As its title, it's for "Mobile and Wireless Networks". Furthermore, even with PMIPv6, p-t-p link does not give any information about multicast membership status. The explicit tracking function is the suitable way to do it. I'll mention that this draft also covers non-PMIPv6 in the paragraphs that include ambiguities. > Comment #6.- In chapter 3 (Explicit tracking), on the third paragraph you > mention: "Therefore, in this document, we propose that adjacent upstream > multicast routers SHOULD enable the explicit tracking function...". It is > not clear to me if you are referring here to the MAG or to the LMA. When I > read this sentence I think on the LMA. But, if so, I don't know why the LMA > should maintain an explicit tracking of thier downstream interfaces, because > the LMA has only the vision of the MLD proxies (MAGs), not the vision of the > end users. This sentence does not mention whether "adjacent upstream multicast routers" are LMA or MAG. It is a general discussion that the explicit tracking function is advantageous to reduce the number of transmitted IGMP/MLD messages when adjacent upstream multicast routers evable it. According to your assumption, LMA is a router and MAG is a proxy. Even in this case, if both LMA and MAG enable the function, they less transmit IGMP/MLD *-specific query messages. BTW, I admit "SHOULD" is too strong here. I replace it to "recommend". > Comment #7.- Regarding the general query interval, you propose in some case > a timer higher than the default (150s instead of 125). If the MAG asks the > MN every 150s, but the LMA is asking the MAG each 125s, we are wasting > resources at MAG. This assymetry is not good from my point of view. I would > suggest to align the LMA-MAG query interval to the highest value of the > MAG-MN timer.Take into account that the variability in the multicast > channels subscription among LMA and MAG will be less than the one among MAG > and MN. I will consider this point. Thanks. > Comment #8.- In section 4.2 (Tuning the MLD Query response interval), you > differientate values for wireless links according to their characteristics. > One value is assigned to lossy links. However, for every kind of link, when > the MN moves and it makes a handover, the link will be necessarily lossy > because the MN is at the border of a cell, probably with not optimial > conditions. Additionally, as the MN moves, the wireless link characteristics > can changed from good to bad. So, do you suggest to dynamically change this > parameter as function of transmission properties, or situations (HO vs > no-HO) as stated at the end of section 4.6? This draft does not include such dynamic coordination as it requires protocol changes, which is not our target. This draft is a guideline for the protocol tuning; it is difficult to define the precise or perfect value when the link is changed to a good or bad condition. I expect that operators will be able to tune the values by referring this document. > Comment#9.- In section 4.4 (Tuning Startup Query interval), you mention: > "The default value is 1/4 of [Query Interval]". I would include the value in > seconds for completeness. [Query Interval] is variable value. This draft however recommends 1 second regardless of its value. > Comment#10.- About the Startup Query interval behavior in the base solution: > in RFC 6224 two MLD Queries are triggered, one by the kernel, once the MN is > attaches and the p-tp link is up, and one by the MLD proxy instance > associated by the MAG for that MN. Due that the MN will answer one of them > (either the one of the kernel or the one of the instance), what would be the > behavior for the other one? Should either the kernel or the instance > re-sending the General Query as much times as determined by the startup > query interval? I cannot understand this. What does "one by the kernel, and one by the MLD proxy instance" mean? Kernel does not trigger MLD general query. > Comment #11.- In Appendix A, second paragraph you talk about unicast > queries. I think that this is not a great advantage for PMIPv6 because of > the p-t-p nature of the link (only one MN wil be queried either by unicas or > multicast). Maybe this could be clarified in the text. This draft is not only for PMIPv6. > Comment #12.- In Appendix A, at the end of the page you put in > brackets:"(See Appendix A <#appendix-A> for the detail)" This should be > deleted, I guess. Done. Regards, -- Hitoshi Asaeda From internet-drafts@ietf.org Mon Oct 31 10:38: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 761811F0C8E; Mon, 31 Oct 2011 10:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 Bms7APy-hD3L; Mon, 31 Oct 2011 10:38:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D951F0C67; Mon, 31 Oct 2011 10:38:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031173846.1666.13885.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 10:38:46 -0700 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-igmp-mld-tuning-02.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: Mon, 31 Oct 2011 17:38:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of t= he IETF. Title : Tuning the Behavior of IGMP and MLD for Routers in Mobil= e and Wireless Networks Author(s) : Hitoshi Asaeda Hui Liu Qin Wu Filename : draft-ietf-multimob-igmp-mld-tuning-02.txt Pages : 18 Date : 2011-10-31 IGMP and MLD are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other. This document describes the ways of IGMPv3 and MLDv2 protocol optimization for mobility, and aims to become a guideline for query and other timers and values tuning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-02.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-02.t= xt From lmcm@tid.es Mon Oct 31 15:19:39 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 CFA2111E8287 for ; Mon, 31 Oct 2011 15:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=-0.698, 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 C4UhwDrvph46 for ; Mon, 31 Oct 2011 15:19:39 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18811E8134 for ; Mon, 31 Oct 2011 15:19:31 -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 <0LTY00IK0BCH4M@tid.hi.inet> for multimob@ietf.org; Mon, 31 Oct 2011 23:19:29 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id B8.C7.02602.1FE1FAE4; Mon, 31 Oct 2011 23:19:29 +0100 (CET) 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 <0LTY00IJVBCH4M@tid.hi.inet> for multimob@ietf.org; Mon, 31 Oct 2011 23:19:29 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Mon, 31 Oct 2011 23:19:30 +0100 Date: Mon, 31 Oct 2011 23:19:29 +0100 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <20111031221342.31874.43402.idtracker@ietfa.amsl.com> To: "multimob@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: New Version Notification for draft-contreras-multimob-rams-03.txt Thread-index: AcyYGluSLVYnI+HjSLaRSsYKblOCMQAAA3Fd acceptlanguage: es-ES, en-US X-AuditID: 0a5f4068-b7fdd6d000000a2a-e0-4eaf1ef14051 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42Lhinfg0v0ot97P4OlJA4sZH/tYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsf/7d9aCN6IVP2+vYmxgXCLaxcjJISFgIvGv7ysjhC0mceHe erYuRi4OIYENjBJnp+9ih3B+M0r8WnUWKtPIKHHs52s2kBYWAVWJ1deXsoPYbAKGErN2TmIF sYUF/CT+3bnBBGJzCjhJnHs4D2yFiIC2xJuXf8DizEA1V1b+A6vnFfCU+LTjHxuELSjxY/I9 li5GDqAadYkpU3IhyhUlpi1qABvDKCArsfL8aaiR/hI3W/4xgZSLCBhJHLtiD1EiI/F/+V4W iMcEJJbsOc8MYYtKvHwMspUD6BVHiSsbJSYwis1CsncWwt5ZSPYuYGRexShWnFSUmZ5RkpuY mZNuYKiXkamXmZdasokREhEZOxiX71Q5xCjAwajEwxvAs95PiDWxrLgy9xCjJAeTkigvhzhQ iC8pP6UyI7E4I76oNCe1+BCjBAezkgiv/7J1fkK8KYmVValF+TApGQ4OJQneQGD0CgkWpaan VqRl5gDjHibNxMEJ0s4D1H5KFqiGt7ggMbc4Mx0if4pRlePYusWnGIVY8vLzUqXEed1BBgmA FGWU5sHNecUoDnSwMO8ZkBE8wMQFN+EV0HAmoOHql0FuKy5JREhJNTC6Trs7izFq22LNYMnb qw6VdGfENLcWNbnbhSzcP2HdQ6fkFZd+hOw4Zr3loFpWylfdOQW3rP75JRbUz/8sWfZGarVS aGtWztxDjocqr291fftJMd3t4dT4v00Mr31+sHwNyj7p8GnNYS3GzwcmPMlVWp7REbO30Iw1 Pdma/dxXqUCOhsDg/8ZKLMUZiYZazEXFiQBQkiELGQMAAA== References: <20111031221342.31874.43402.idtracker@ietfa.amsl.com> Cc: "isoto@dit.upm.es" Subject: [multimob] RV: New Version Notification for draft-contreras-multimob-rams-03.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: Mon, 31 Oct 2011 22:19:39 -0000 SGkgYWxsLA0KDQpwbGVhc2UgZmluZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWNvbnRyZXJhcy1t dWx0aW1vYi1yYW1zIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jb250cmVyYXMt bXVsdGltb2ItcmFtcy0wMykgd2hpY2ggYSBtaW5vciBhbWVuZG1lbnQgaW4gdGhlIEFjayBzZWN0 aW9uLCBhbmQgc29tZSBvdGhlciBmZXcgdHlwb3MuDQoNClNvcnJ5IGZvciBhbnkgaW5jb252ZW5p ZW5jZSwNCg0KQmVzdCByZWdhcmRzLA0KDQpMdWlzDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpEZTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddDQpFbnZpYWRvIGVsOiBsdW5lcywgMzEgZGUgb2N0dWJyZSBkZSAyMDEx IDIzOjEzDQpQYXJhOiBMVUlTIE1JR1VFTCBDT05UUkVSQVMgTVVSSUxMTw0KQ0M6IGlzb3RvQGRp dC51cG0uZXM7IGNqYmNAaXQudWMzbS5lczsgTFVJUyBNSUdVRUwgQ09OVFJFUkFTIE1VUklMTE8N CkFzdW50bzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1jb250cmVyYXMtbXVs dGltb2ItcmFtcy0wMy50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNvbnRyZXJh cy1tdWx0aW1vYi1yYW1zLTAzLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IEx1aXMgQ29udHJlcmFzIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmls ZW5hbWU6ICAgICAgICBkcmFmdC1jb250cmVyYXMtbXVsdGltb2ItcmFtcw0KUmV2aXNpb246ICAg ICAgICAwMw0KVGl0bGU6ICAgICAgICAgICBSYXBpZCBhY3F1aXNpdGlvbiBvZiB0aGUgTU4gbXVs dGljYXN0IHN1YnNjcmlwdGlvbiBhZnRlciBoYW5kb3Zlcg0KQ3JlYXRpb24gZGF0ZTogICAyMDEx LTEwLTMxDQpXRyBJRDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9m IHBhZ2VzOiAzMQ0KDQpBYnN0cmFjdDoNCiAgIEEgbmV3IHByb3Bvc2FsIGlzIHByZXNlbnRlZCBm b3Igc3BlZWRpbmcgdXAgdGhlIGFjcXVpc2l0aW9uIGJ5IHRoZQ0KICAgTUFHIG9mIHRoZSBNTiYj Mzk7cyBhY3RpdmUgbXVsdGljYXN0IHN1YnNjcmlwdGlvbiBpbmZvcm1hdGlvbiwgaW4gb3JkZXIN CiAgIHRvIGFjY2VsZXJhdGUgdGhlIG11bHRpY2FzdCBkZWxpdmVyeSB0byB0aGUgTU4gYWZ0ZXIg YSBoYW5kb3Zlci4gVG8NCiAgIGRvIHRoYXQsIGFuIGV4dGVuc2lvbiB0byB0aGUgY3VycmVudCBQ TUlQdjYgcHJvdG9jb2wgaXMgcHJvcG9zZWQuIFRoZQ0KICAgc29sdXRpb24gZGVzY3JpYmVkIGlu IHRoaXMgbWVtbyBpcyBub3Qgb25seSBhcHBsaWNhYmxlIHRvIHRoZSBiYXNlDQogICBzb2x1dGlv biBmb3IgbXVsdGljYXN0IHN1cHBvcnQgaW4gUE1JUHY2LCBidXQgYWxzbyBpdCBjYW4gYmUgYXBw bGllZA0KICAgdG8gb3RoZXIgc29sdXRpb25zIGVudmlzaW9uZWQgYXMgcG9zc2libGUgYXJjaGl0 ZWN0dXJhbCBldm9sdXRpb25zIG9mDQogICBpdC4gRnVydGhlcm1vcmUsIGl0IGlzIGFsc28gaW5k ZXBlbmRlbnQgb2YgdGhlIHJvbGUgcGxheWVkIGJ5IHRoZSBNQUcNCiAgIHdpdGhpbiB0aGUgbXVs dGljYXN0IG5ldHdvcmsgKGVpdGhlciBhY3RpbmcgYXMgTUxEIHByb3h5IG9yIG11bHRpY2FzdA0K ICAgcm91dGVyKS4NCg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KRXN0ZSBtZW5zYWpl IHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3Vs dGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVs ZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdl IGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQg YW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Lg0K aHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg==