From sarikaya2012@gmail.com Wed Feb 1 09:10:41 2012 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 15F5B11E8128 for ; Wed, 1 Feb 2012 09:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 x9UN-vCA-aoU for ; Wed, 1 Feb 2012 09:10:37 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E29011E8126 for ; Wed, 1 Feb 2012 09:10:37 -0800 (PST) Received: by yenm3 with SMTP id m3so747875yen.31 for ; Wed, 01 Feb 2012 09:10:29 -0800 (PST) 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=jt7orbuwveIrRLlbdgzLeSbc6FSNO2Bv0Tm5hqtf4E8=; b=NzFL3wZv+CG9q3+0FVsg6mJZai5xqTAYXLJZzyhaOGeAXWLqPiHnhsro25kQ3c6qx0 Vb+pZ3iRx763MNnGLFv6NQWKqzWXk37oWSpNFJPZU3ZVclXUc4aDgmQiFFp6FuiEzq1S fSbmWTa4Q3u3TeG6Nolcn4ySQiD/0RW6YMp0c= MIME-Version: 1.0 Received: by 10.236.161.103 with SMTP id v67mr41852065yhk.87.1328116229339; Wed, 01 Feb 2012 09:10:29 -0800 (PST) Received: by 10.236.108.165 with HTTP; Wed, 1 Feb 2012 09:10:29 -0800 (PST) Date: Wed, 1 Feb 2012 11:10:29 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multimob] New draft:draft-liu-multimob-pmipv6-multicast-ro 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: Wed, 01 Feb 2012 17:10:42 -0000 A new draft has been posted, at http://datatracker.ietf.org/doc/draft-liu-multimob-pmipv6-multicast-ro/ . Please take a look at it and comment. Behcet From Marco.Liebsch@neclab.eu Mon Feb 6 09:27:52 2012 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 2617B21F86CA for ; Mon, 6 Feb 2012 09:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 XP6-iYweOgq7 for ; Mon, 6 Feb 2012 09:27:51 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id EB36521F863E for ; Mon, 6 Feb 2012 09:27:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4D95C280000F8; Mon, 6 Feb 2012 18:27:50 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) 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 SJz7u310j+FT; Mon, 6 Feb 2012 18:27:50 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 2E5B128000084; Mon, 6 Feb 2012 18:27:35 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.103]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 6 Feb 2012 18:27:35 +0100 From: Marco Liebsch To: "Dirk.von-Hugo@telekom.de" , "sarikaya@ieee.org" , "multimob@ietf.org" Thread-Topic: [multimob] PMIP MC handover -- some thoughts Thread-Index: AQHM1sfp/9+sxZdDv0+MAKx2rjNJnZYmq50AgAmCzVA= Date: Mon, 6 Feb 2012 17:27:35 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D24D51B00@PALLENE.office.hd> References: <05C81A773E48DD49B181B04BA21A342A27423D8247@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A27423D8247@HE113484.emea1.cds.t-internal.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Mon, 06 Feb 2012 17:27:52 -0000 Hi Dirk, some additional points inline. > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Dirk.von-Hugo@telekom.de > Sent: Dienstag, 31. Januar 2012 17:26 > To: sarikaya@ieee.org; multimob@ietf.org > Subject: Re: [multimob] PMIP MC handover -- some thoughts >=20 > Hi Behcet, > I think you have already summarized some comments from our discussion in > September (e.g. by Luis). Good point added regarding required MLD > extension ... Thanks! > I'll try to add my thoughts - hopefully not doubling too much from last y= ear's > arguments - please see below: >=20 > Best regards > Dirk >=20 > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im > Auftrag von Behcet Sarikaya > Gesendet: Donnerstag, 19. Januar 2012 17:32 > An: multimob@ietf.org > Betreff: [multimob] PMIP MC handover -- some thoughts >=20 > Hi all, >=20 > It is time to discuss our fast handover charter item and the proposed > approaches. >=20 > I copied below what Marco wrote on the list on Sept. 7, 2011. > To Marco's points, I am adding one more as the last one below. >=20 > I think that there is consensus on these points. >=20 >=20 > - Why FHO-like forwarding between MAGs is beneficial for multicast? > It puts assumptions on inter-MAG operation and introduces overhead > which > should be justified. >=20 > > Dirk: Right - the expected performance improvement is not for free in > > terms of complexity and protocol extensions (incl. MLD). Thus we have > > to argue with dedicated services which benefit from disruption-free > > mobile multicast receiption and may be asked for in large amount so > > that multicast will be economically viable >=20 >=20 > - 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. >=20 > > Dirk: Agreed - the buffered content is received with delay, but since i= n pure > multicast it would be lost to the mobile receiver otherwise, this is a ga= in. > Thanks to increased processing power and storage capacity at handhelds th= e > streamed IP Video is either already buffered at the terminal so a medium > delay might be unnoticeable to the consumer (or he is anyway storing the > video content for later consumption since on the move he cannot focus on > viewing). I am not really buying the use case of storing streamed video for watching = it later. AFAIK, if RTP is used in real-time streaming, which I see as main application of MC, the player may drop packets if they arrive delayed and continues playback of newer packets to keep the real-time notion. Maybe my view is outdated ;-), but just take it into account when selling the value of MC forwarding. > But other broad- or multicast services like large scale synchronisation (= social > network data, anti virus sw updates, newsfeed distribution, ...) demand > mainly error-free delivery rather than real-time character Ok, so you say that forwarding should be used to avoid packet loss in software updates which rely on MC for distribution? True, this is not a real-time service anymore. But if reliability is the main objective, I'd expect other transport mechanisms, such as reliable multicast, to recover from packet losses. Not sure forwarding outperforms reliable MC. In particular for software distribution with MC,=20 reordering and packet dup may be an issue to resolve if MC forwarding is used. >=20 > - 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-order= ing > resolved on the MAG by means of scheduled delivery to the MN? >=20 > > Dirk: Yes, and if the actual serving MAG is controling forwarding from > > previous one the direct packets will be correspondingly postponed >=20 > - 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 >=20 > > Dirk: Again this depends on the application/use case - base Multimob do= es > not care for lost packets during handover, right? >=20 > - If forwarding between MAGs is adopted, we may consider it optional >=20 > > Dirk: I tend to agree with Luis - subscription forwarding is more > > important than content forwarding With subscription forwarding you mean transfer of the MN's subscription con= text, right? I agree. This is really valuable if it can be done proactively. So we have = two cases here: In case the nMAG has subscribed to the MC group already, the stream i= s received at the nMAG before the MN's handover. Having the MN's listener st= ate through proactive CTX, the nMAG can buffer these packets for later retrieva= l and I don't see a benefit in MC forwarding from the pMAG. Forwarding could be o= f advantage if the nMAG is not yet subscribed to the MC groups of interest to= the MN, as the subscription may take long. Such information could be exchanged during CTX, which can be used as key to enable or disable forwarding for th= is handover session.=20 marco >=20 > - 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. >=20 > > Dirk: agree that LMA-MAG can already be assumed as established whereas > for inter-MAG tunnel we need to set up. But if MAGs are owned by same > operator and we think of a future scenario: LMAs may be quite centralized= to > save deployment and operational costs - so the delay and burden of > processing all multicast contexts might be great. On the other hand futur= e > base stations (e.g. 3GPPs LTE-Advanced, but perhaps also 802.11..?) need > direct links to synchronize and exchange link state information anyway (e= .g. > for Coordinated multi-point (CoMP), Multicell MIMO) so they could be re- > used ... >=20 >=20 > - Transferring context assumes that multicast state can be established at= the > proxy/querier without receiving corresponding join messages from MNs. > This is an extension to MLD. >=20 > > Dirk: I am afraid you are right - unless it is possible for the pMAG > > or LMA to act on behalf the MN and kind of 'spoof the MN join message' > > ...? ;-) >=20 > Regards, >=20 > Behcet > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From Dirk.von-Hugo@telekom.de Wed Feb 8 06:18:37 2012 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 B9FD821F861D for ; Wed, 8 Feb 2012 06:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 Txr-CEryuK9S for ; Wed, 8 Feb 2012 06:18:31 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 679B121F8616 for ; Wed, 8 Feb 2012 06:18:27 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 08 Feb 2012 15:13:48 +0100 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.228]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Wed, 8 Feb 2012 15:13:48 +0100 From: To: , , Date: Wed, 8 Feb 2012 15:13:55 +0100 Thread-Topic: [multimob] PMIP MC handover -- some thoughts Thread-Index: AQHM1sfp/9+sxZdDv0+MAKx2rjNJnZYmq50AgAmCzVCAArp+0A== Message-ID: <05C81A773E48DD49B181B04BA21A342A27425B6D8E@HE113484.emea1.cds.t-internal.com> References: <05C81A773E48DD49B181B04BA21A342A27423D8247@HE113484.emea1.cds.t-internal.com> <69756203DDDDE64E987BC4F70B71A26D24D51B00@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D24D51B00@PALLENE.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Wed, 08 Feb 2012 14:18:38 -0000 Hi Marco, Thanks for the comments. Please see inline ... Best regards Dirk von Hugo Deutsche Telekom AG T-Labs (Research & Development) Dirk von Hugo Deutsche-Telekom-Allee 7, 64295 Darmstadt Germany +49 6151 937-2536 (Tel.) +49 6151 937-4611 (Fax) +49 151 14620590 (Mobile) E-Mail: dirk.von-hugo@telekom.de www.telekom.com Life is for sharing Deutsche Telekom AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: Ren=E9 Obermann (Chairman), Dr. Manfred Balz, Reinhard= Clemens, Niek Jan van Damme, Timotheus H=F6ttges, Claudia Nemat, Thomas Sa= ttelberger Commercial Register: District Court Bonn HRB 6794 Registered Office: Bonn WEEE reg. no.: DE50478376 Big changes start small - conserve resources by not printing every e-mail. -----Urspr=FCngliche Nachricht----- Von: Marco Liebsch [mailto:Marco.Liebsch@neclab.eu] Gesendet: Montag, 6. Februar 2012 18:28 An: von Hugo, Dirk; sarikaya@ieee.org; multimob@ietf.org Betreff: RE: [multimob] PMIP MC handover -- some thoughts Hi Dirk, some additional points inline. > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Dirk.von-Hugo@telekom.de > Sent: Dienstag, 31. Januar 2012 17:26 > To: sarikaya@ieee.org; multimob@ietf.org > Subject: Re: [multimob] PMIP MC handover -- some thoughts > > Hi Behcet, > I think you have already summarized some comments from our discussion in > September (e.g. by Luis). Good point added regarding required MLD > extension ... Thanks! > I'll try to add my thoughts - hopefully not doubling too much from last y= ear's > arguments - please see below: > > Best regards > Dirk > > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im > Auftrag von Behcet Sarikaya > Gesendet: Donnerstag, 19. Januar 2012 17:32 > An: multimob@ietf.org > Betreff: [multimob] PMIP MC handover -- some thoughts > > Hi all, > > It is time to discuss our fast handover charter item and the proposed > approaches. > > I copied below what Marco wrote on the list on Sept. 7, 2011. > To Marco's points, I am adding one more as the last one below. > > I think that there is consensus on these points. > > > - Why FHO-like forwarding between MAGs is beneficial for multicast? > It puts assumptions on inter-MAG operation and introduces overhead > which > should be justified. > > > Dirk: Right - the expected performance improvement is not for free in > > terms of complexity and protocol extensions (incl. MLD). Thus we have > > to argue with dedicated services which benefit from disruption-free > > mobile multicast receiption and may be asked for in large amount so > > that multicast will be economically viable > > > - 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. > > > Dirk: Agreed - the buffered content is received with delay, but since i= n pure > multicast it would be lost to the mobile receiver otherwise, this is a ga= in. > Thanks to increased processing power and storage capacity at handhelds th= e > streamed IP Video is either already buffered at the terminal so a medium > delay might be unnoticeable to the consumer (or he is anyway storing the > video content for later consumption since on the move he cannot focus on > viewing). I am not really buying the use case of storing streamed video for watching = it later. AFAIK, if RTP is used in real-time streaming, which I see as main application of MC, the player may drop packets if they arrive delayed and continues playback of newer packets to keep the real-time notion. Maybe my view is outdated ;-), but just take it into account when selling the value of MC forwarding. |Dirk: At least RTP in RFC 3550 allows 'considering that the receiver buffe= r must accommodate' delay and jitter variation ... So why not also store co= ntent for VCR-like replay and pause in case of live transmission (I think c= ommercial IPTV already offers this within the set top box) BTW, the dropout parameter in RFC 3550 can be as long as 1 minute i.e. (AFA= IUIC) for forwarded packets up to such a delay it could still work ... > But other broad- or multicast services like large scale synchronisation (= social > network data, anti virus sw updates, newsfeed distribution, ...) demand > mainly error-free delivery rather than real-time character Ok, so you say that forwarding should be used to avoid packet loss in software updates which rely on MC for distribution? True, this is not a real-time service anymore. But if reliability is the main objective, I'd expect other transport mechanisms, such as reliable multicast, to recover from packet losses. Not sure forwarding outperforms reliable MC. In particular for software distribution with MC, reordering and packet dup may be an issue to resolve if MC forwarding is used. |Dirk: I see that RMT specified both a 'NACK-Oriented Reliable Multicast (N= ORM) Transport Protocol' (RFC 5740) tolerating lossy conditions occurring i= n many mobile networks and also RFC 5775 'Asynchronous Layered Coding (ALC)= Protocol Instantiation' (with FEC) which however introduce additional dela= y and bandwidth demand. Which one performs better surely depends on the exact scenario ... > > - 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-order= ing > resolved on the MAG by means of scheduled delivery to the MN? > > > Dirk: Yes, and if the actual serving MAG is controling forwarding from > > previous one the direct packets will be correspondingly postponed > > - 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 > > > Dirk: Again this depends on the application/use case - base Multimob do= es > not care for lost packets during handover, right? > > - If forwarding between MAGs is adopted, we may consider it optional > > > Dirk: I tend to agree with Luis - subscription forwarding is more > > important than content forwarding With subscription forwarding you mean transfer of the MN's subscription con= text, right? I agree. This is really valuable if it can be done proactively. So we have = two cases here: In case the nMAG has subscribed to the MC group already, the stream i= s received at the nMAG before the MN's handover. Having the MN's listener st= ate through proactive CTX, the nMAG can buffer these packets for later retrieva= l and I don't see a benefit in MC forwarding from the pMAG. Forwarding could be o= f advantage if the nMAG is not yet subscribed to the MC groups of interest to= the MN, as the subscription may take long. Such information could be exchanged during CTX, which can be used as key to enable or disable forwarding for th= is handover session. marco |Dirk: Yes, so we agree that proctive multicast subscription support can re= duce delay and loss without requiring additional re-ordering and forwarding= effort. Thanks! > > - 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. > > > Dirk: agree that LMA-MAG can already be assumed as established whereas > for inter-MAG tunnel we need to set up. But if MAGs are owned by same > operator and we think of a future scenario: LMAs may be quite centralized= to > save deployment and operational costs - so the delay and burden of > processing all multicast contexts might be great. On the other hand futur= e > base stations (e.g. 3GPPs LTE-Advanced, but perhaps also 802.11..?) need > direct links to synchronize and exchange link state information anyway (e= .g. > for Coordinated multi-point (CoMP), Multicell MIMO) so they could be re- > used ... > > > - Transferring context assumes that multicast state can be established at= the > proxy/querier without receiving corresponding join messages from MNs. > This is an extension to MLD. > > > Dirk: I am afraid you are right - unless it is possible for the pMAG > > or LMA to act on behalf the MN and kind of 'spoof the MN join message' > > ...? ;-) > > Regards, > > Behcet > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From sarikaya2012@gmail.com Mon Feb 13 04:27:15 2012 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 7F0D421F85AF for ; Mon, 13 Feb 2012 04:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, 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 zQALaohEmQNi for ; Mon, 13 Feb 2012 04:27:15 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E599221F8550 for ; Mon, 13 Feb 2012 04:27:14 -0800 (PST) Received: by yenm3 with SMTP id m3so2623925yen.31 for ; Mon, 13 Feb 2012 04:27:14 -0800 (PST) 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=PLVXN3VVWxxd65WAV5r8LP/4vd6ZJGfWeKt1sK7KSyk=; b=KGY9kRuyefuB5A38fjJB2PnsT4sf65aW5x+z1LlVZjoHLEgB+AFg0b5Gh9pNSbWyWd 6ZVT2WWo/LtiFydkIO81mEyDJAVhh5Avqczm7GisdhDF0JMmSbwdPCt+QbyRka5V6DBz 2xgQgMS/gMjdgQRqAQW10x2LWKwf8jv8lW3Ak= MIME-Version: 1.0 Received: by 10.236.46.193 with SMTP id r41mr19226416yhb.123.1329136034099; Mon, 13 Feb 2012 04:27:14 -0800 (PST) Received: by 10.236.9.73 with HTTP; Mon, 13 Feb 2012 04:27:14 -0800 (PST) Date: Mon, 13 Feb 2012 06:27:14 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multimob] draft-ietf-multimob-igmp-mld-tuning-03 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: Mon, 13 Feb 2012 12:27:15 -0000 Folks, This message starts a one week Multimob Working Group last call on advancing: Title :Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks Author(s) :H. Asaeda H. Liu Q. Wu Filename : draft-ietf-multimob-igmp-mld-tuning-03 Pages : 13 Date : 2012-02-13 as Informational. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on February 20, 2012. Regards, Chairs From zehn.cao@gmail.com Thu Feb 16 01:27:18 2012 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 5953B21F86F6 for ; Thu, 16 Feb 2012 01:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, 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 oX5NJQJ6h9Hv for ; Thu, 16 Feb 2012 01:27:14 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0028021F86F4 for ; Thu, 16 Feb 2012 01:27:13 -0800 (PST) Received: by iagf6 with SMTP id f6so3187670iag.31 for ; Thu, 16 Feb 2012 01:27:13 -0800 (PST) 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:content-transfer-encoding; bh=juVApyjnib5FtfZeXGAxomnDzevlmNsfN2rqlrCq17Q=; b=KR7TP91BFZFmO9pV3db5/xPNUHLro+cyENr2V5g/VOl3onNSjOsXgmqm5f85cBYD07 p4qaaomw966RNBVoau9kmvGCxujpWI/tvYXLsadXwsIOo4h0Bcs12bjfk1Ov9RFDOBjB 4MtY9gfw5MZnSOt6CD308hsOsoqJOTCgFJS8g= MIME-Version: 1.0 Received: by 10.50.181.134 with SMTP id dw6mr16895405igc.11.1329384433661; Thu, 16 Feb 2012 01:27:13 -0800 (PST) Received: by 10.43.130.129 with HTTP; Thu, 16 Feb 2012 01:27:13 -0800 (PST) In-Reply-To: References: Date: Thu, 16 Feb 2012 17:27:13 +0800 Message-ID: From: Zhen Cao To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] draft-ietf-multimob-igmp-mld-tuning-03 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, 16 Feb 2012 09:27:18 -0000 I do think this document is ready for the WGLC. Best regards, Zhen On Mon, Feb 13, 2012 at 8:27 PM, Behcet Sarikaya w= rote: > Folks, > =A0 =A0 This message starts a one week Multimob Working Group last call > on advancing: > > =A0 =A0 Title =A0 =A0 :Tuning the Behavior of IGMP and MLD for Routers in > Mobile and Wireless Networks > =A0 =A0 Author(s) :H. Asaeda > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 H. Liu > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Q. Wu > > =A0 =A0 Filename =A0: draft-ietf-multimob-igmp-mld-tuning-03 > =A0 =A0 Pages =A0 =A0 : 13 > =A0 =A0 Date =A0 =A0 =A0: 2012-02-13 > > as Informational. =A0Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. =A0This last call will > end on February 20, 2012. > > Regards, > Chairs > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob --=20 Best regards, Zhen From Dirk.von-Hugo@telekom.de Mon Feb 20 08:17:56 2012 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 520C021F8738 for ; Mon, 20 Feb 2012 08:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 J-J0zV3mprim for ; Mon, 20 Feb 2012 08:17:52 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id E85B521F8795 for ; Mon, 20 Feb 2012 08:17:51 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 20 Feb 2012 17:17:47 +0100 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.228]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 20 Feb 2012 17:17:46 +0100 From: To: , Date: Mon, 20 Feb 2012 17:17:45 +0100 Thread-Topic: [multimob] draft-ietf-multimob-igmp-mld-tuning-03 Thread-Index: AczqStSMFIcO/SikTLWXWrjXEc0BZQFnKROA Message-ID: <05C81A773E48DD49B181B04BA21A342A27427538B8@HE113484.emea1.cds.t-internal.com> References: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multimob] draft-ietf-multimob-igmp-mld-tuning-03 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, 20 Feb 2012 16:17:56 -0000 Dear all, Sorry for late reply! I also think the draft is in a good shape to represen= t the WGs outcome and be forwarded to IESG. Just some detected nits On p.4: routers enables the explicit tracking function =3D> routers enable the exp= licit tracking function On p.8: set to a smaller value since the number of foreign router =3D> set to a sma= ller value since the number of foreign routers Perhaps here we can add the argument that in this scenario of LMA-MAG tunne= l the power consumption due to a lower query interval is not as critical si= nce MAGs are usually not battry-powered such as mobiles. Best regards Dirk Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftra= g von Behcet Sarikaya Gesendet: Montag, 13. Februar 2012 13:27 An: multimob@ietf.org Betreff: [multimob] draft-ietf-multimob-igmp-mld-tuning-03 Folks, This message starts a one week Multimob Working Group last call on advancing: Title :Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks Author(s) :H. Asaeda H. Liu Q. Wu Filename : draft-ietf-multimob-igmp-mld-tuning-03 Pages : 13 Date : 2012-02-13 as Informational. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on February 20, 2012. Regards, Chairs _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From sarikaya2012@gmail.com Tue Feb 21 15:57:09 2012 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 687F821F8738 for ; Tue, 21 Feb 2012 15:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, 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 km1ttxm3a5sz for ; Tue, 21 Feb 2012 15:57:09 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8819A21F8735 for ; Tue, 21 Feb 2012 15:57:07 -0800 (PST) Received: by yenm3 with SMTP id m3so3665257yen.31 for ; Tue, 21 Feb 2012 15:57:07 -0800 (PST) Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.195.97 as permitted sender) client-ip=10.236.195.97; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.195.97 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com Received: from mr.google.com ([10.236.195.97]) by 10.236.195.97 with SMTP id o61mr39424974yhn.129.1329868627192 (num_hops = 1); Tue, 21 Feb 2012 15:57:07 -0800 (PST) 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:content-type:content-transfer-encoding; bh=Q4YE37jLcUY7LXE2TxqTKXs3nvQbTXhu4DtQcAtiNVg=; b=E5IVOzto6LHicSlirqVLR4/ncq0+GQV6LTr5pjtgxFfgfym01vjJrHXkZIt/K0hZA7 LZVxqMSZvTAv78Jz8x8LcvsusKhhfarrlpyrwuscA2PZ8u00K7za87Q8rFH4OOlr8OIx uOXjoC5Dkz32TIvgrRlD/kysgihXl9EfwBxn8= MIME-Version: 1.0 Received: by 10.236.195.97 with SMTP id o61mr30725903yhn.129.1329868627137; Tue, 21 Feb 2012 15:57:07 -0800 (PST) Received: by 10.236.9.73 with HTTP; Tue, 21 Feb 2012 15:57:07 -0800 (PST) In-Reply-To: References: Date: Tue, 21 Feb 2012 17:57:07 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] draft-ietf-multimob-igmp-mld-tuning-03 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, 21 Feb 2012 23:57:09 -0000 Hi all, WGLC has successfully ended. Authors, please submit your revised draft. Regards, Behcet On Mon, Feb 13, 2012 at 6:27 AM, Behcet Sarikaya w= rote: > Folks, > =A0 =A0 This message starts a one week Multimob Working Group last call > on advancing: > > =A0 =A0 Title =A0 =A0 :Tuning the Behavior of IGMP and MLD for Routers in > Mobile and Wireless Networks > =A0 =A0 Author(s) :H. Asaeda > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 H. Liu > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Q. Wu > > =A0 =A0 Filename =A0: draft-ietf-multimob-igmp-mld-tuning-03 > =A0 =A0 Pages =A0 =A0 : 13 > =A0 =A0 Date =A0 =A0 =A0: 2012-02-13 > > as Informational. =A0Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. =A0This last call will > end on February 20, 2012. > > Regards, > Chairs From sarikaya2012@gmail.com Wed Feb 22 08:22:34 2012 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 11E6A21F8878 for ; Wed, 22 Feb 2012 08:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, 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 QC+XNImxB0n7 for ; Wed, 22 Feb 2012 08:22:33 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5855021F8868 for ; Wed, 22 Feb 2012 08:22:30 -0800 (PST) Received: by yenm3 with SMTP id m3so143054yen.31 for ; Wed, 22 Feb 2012 08:22:30 -0800 (PST) Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.173.132 as permitted sender) client-ip=10.236.173.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.173.132 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com Received: from mr.google.com ([10.236.173.132]) by 10.236.173.132 with SMTP id v4mr43451716yhl.78.1329927750057 (num_hops = 1); Wed, 22 Feb 2012 08:22:30 -0800 (PST) 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=4kZvWbryflKcBcgg3FLG8Yf5P0xchJyJ1fIKbdmmiok=; b=MLdAT3HgJvqXjU8W8HrciuNkhxMqM3nnG32hapBlWuSp4K59bDnr0b85HSpzhDY6x1 sfqHCCF5trs70Q1Nh24Po8kc2T1/3ypuxto6flLaMS7nu12O6HIljzOin/UvO/J7solq rVeRmmR8n1tvExWk4zit/7nZzbSNa9tAyYfqo= MIME-Version: 1.0 Received: by 10.236.173.132 with SMTP id v4mr33994114yhl.78.1329927749893; Wed, 22 Feb 2012 08:22:29 -0800 (PST) Received: by 10.236.9.73 with HTTP; Wed, 22 Feb 2012 08:22:29 -0800 (PST) Date: Wed, 22 Feb 2012 10:22:29 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multimob] Session requests for IETF-83 in Paris 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: Wed, 22 Feb 2012 16:22:34 -0000 Hi all, We expect to meet in IETF-83 in Paris. If you wish to make a presentation, please send your request(s) to the chairs. Behcet & Stig, From prvs=3921bb744=schmidt@informatik.haw-hamburg.de Wed Feb 22 08:43:43 2012 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 AB56821F88AB for ; Wed, 22 Feb 2012 08:43:43 -0800 (PST) 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 y0X7d93NmQDy for ; Wed, 22 Feb 2012 08:43:39 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2F49421F88AD for ; Wed, 22 Feb 2012 08:43:39 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 22 Feb 2012 17:43:34 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 6D0A0104EB79; Wed, 22 Feb 2012 17:43:34 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28866-02; Wed, 22 Feb 2012 17:43:34 +0100 (CET) Received: from [141.22.26.184] (unknown [141.22.26.184]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 1D4D8104EB78; Wed, 22 Feb 2012 17:43:34 +0100 (CET) Message-ID: <4F451B38.4050605@informatik.haw-hamburg.de> Date: Wed, 22 Feb 2012 17:43:36 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sarikaya@ieee.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: "multimob@ietf.org" Subject: Re: [multimob] Session requests for IETF-83 in Paris 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, 22 Feb 2012 16:43:43 -0000 Hi chairs, we would like to present the source draft status. Regarding the fast handover, I don't think a new presentation is of much help - this has been presented continuously and the document is actually in a pre-final status, but stuck for "political" reasons. What seems to require clarification is the charter story: As became evident in recent offlist discussions about handover optimization, the charter is inconsistent. We should at least come to a common interpretation of "what is meant" - otherwise discussions about solutions get stuck with questioning the charter - and hamper decent work. Best, Thomas On 22.02.2012 17:22, Behcet Sarikaya wrote: > Hi all, > > We expect to meet in IETF-83 in Paris. > > If you wish to make a presentation, please send your request(s) to the chairs. > > Behcet& Stig, > _______________________________________________ > 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 internet-drafts@ietf.org Mon Feb 27 00:27:08 2012 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 0DF3321F8542; Mon, 27 Feb 2012 00:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 Z7KHowmumVjq; Mon, 27 Feb 2012 00:27:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9976C21F8503; Mon, 27 Feb 2012 00:27:07 -0800 (PST) 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: 4.00 Message-ID: <20120227082707.22118.54420.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 00:27:07 -0800 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-igmp-mld-tuning-04.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, 27 Feb 2012 08:27:08 -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-04.txt Pages : 13 Date : 2012-02-27 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 tuning of IGMPv3/ MLDv2 Queries and timer and counter values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-04.= 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-04.t= xt From Dirk.von-Hugo@telekom.de Mon Feb 27 01:52:02 2012 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 730AF21F861C for ; Mon, 27 Feb 2012 01:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 LXgamupltiJ3 for ; Mon, 27 Feb 2012 01:52:01 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7DF21F862A for ; Mon, 27 Feb 2012 01:52:00 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 27 Feb 2012 10:51:53 +0100 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.228]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 27 Feb 2012 10:51:53 +0100 From: To: , Date: Mon, 27 Feb 2012 10:51:53 +0100 Thread-Topic: [multimob] Session requests for IETF-83 in Paris Thread-Index: AczxfjbaFPfirrjzQFiB3miZXJtS2QDtrF7A Message-ID: <05C81A773E48DD49B181B04BA21A342A2742859B88@HE113484.emea1.cds.t-internal.com> References: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] Session requests for IETF-83 in Paris 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, 27 Feb 2012 09:52:02 -0000 Hello Behcet and Stig, I plan to submit a draft on Multimob for DMM end of this week and would lik= e to present it if you think it fits into charter and time frame. Thanks! Best regards Dirk Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftra= g von Behcet Sarikaya Gesendet: Mittwoch, 22. Februar 2012 17:22 An: multimob@ietf.org Betreff: [multimob] Session requests for IETF-83 in Paris Hi all, We expect to meet in IETF-83 in Paris. If you wish to make a presentation, please send your request(s) to the chai= rs. Behcet & Stig, _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From bill.wu@huawei.com Mon Feb 27 01:12:00 2012 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 56D9221F8595 for ; Mon, 27 Feb 2012 01:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.505 X-Spam-Level: X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=1.094, 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 q0KRXgrDBujR for ; Mon, 27 Feb 2012 01:11:59 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2D40021F8593 for ; Mon, 27 Feb 2012 01:11:59 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M01003N4NV01W@szxga04-in.huawei.com> for multimob@ietf.org; Mon, 27 Feb 2012 17:04:12 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M01007QSNV0YF@szxga04-in.huawei.com> for multimob@ietf.org; Mon, 27 Feb 2012 17:04:12 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHB81334; Mon, 27 Feb 2012 17:04:11 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Feb 2012 17:03:44 +0800 Received: from w53375q (10.138.41.149) by szxeml416-hub.china.huawei.com (10.82.67.155) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Feb 2012 17:04:10 +0800 Date: Mon, 27 Feb 2012 17:04:09 +0800 From: Qin Wu X-Originating-IP: [10.138.41.149] To: sarikaya@ieee.org, multimob@ietf.org Message-id: <0FD9836D31DD4834B12ECE04D56DB0F7@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: X-Mailman-Approved-At: Mon, 27 Feb 2012 08:45:30 -0800 Subject: Re: [multimob] draft-ietf-multimob-igmp-mld-tuning-03 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, 27 Feb 2012 09:12:00 -0000 Chairs: We have done. The new version is available at: http://www.ietf.org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-04.txt The diff is: http://tools.ietf.org/rfcdiff?url2=draft-ietf-multimob-igmp-mld-tuning-04 Regards! -Qin ----- Original Message ----- From: "Behcet Sarikaya" To: Sent: Wednesday, February 22, 2012 7:57 AM Subject: Re: [multimob] draft-ietf-multimob-igmp-mld-tuning-03 Hi all, WGLC has successfully ended. Authors, please submit your revised draft. Regards, Behcet On Mon, Feb 13, 2012 at 6:27 AM, Behcet Sarikaya wrote: > Folks, > This message starts a one week Multimob Working Group last call > on advancing: > > Title :Tuning the Behavior of IGMP and MLD for Routers in > Mobile and Wireless Networks > Author(s) :H. Asaeda > H. Liu > Q. Wu > > Filename : draft-ietf-multimob-igmp-mld-tuning-03 > Pages : 13 > Date : 2012-02-13 > > as Informational. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call will > end on February 20, 2012. > > Regards, > Chairs _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From sarikaya2012@gmail.com Mon Feb 27 11:58:55 2012 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 7CAB521F87F5; Mon, 27 Feb 2012 11:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, 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 zAOLkfep0zLR; Mon, 27 Feb 2012 11:58:54 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40FC821F87F4; Mon, 27 Feb 2012 11:58:54 -0800 (PST) Received: by ggnp2 with SMTP id p2so587697ggn.31 for ; Mon, 27 Feb 2012 11:58:53 -0800 (PST) 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:cc :content-type; bh=dKfp7nB+7yI/MLzeG5kuVSCX/7aPKQnCD5liELquz+0=; b=tKluOBqFpZRAySr+7zN6ZHRaR8w1rzJtJq9KZSpkDwZjyGkEm381cfLnfmUiPclay8 6G4NA2TU4EmD9zptZaBxvsDP6x3nb/GQbHQyleaDyGVv+Z4O9z+FiuKYpj5rmQ1j5DvI 1hhvlGofJwtqZ+ssniXTynKMowG+7t+Utg6v8= MIME-Version: 1.0 Received: by 10.236.79.202 with SMTP id i50mr17863927yhe.61.1330372733797; Mon, 27 Feb 2012 11:58:53 -0800 (PST) Received: by 10.236.9.73 with HTTP; Mon, 27 Feb 2012 11:58:53 -0800 (PST) Date: Mon, 27 Feb 2012 13:58:53 -0600 Message-ID: From: Behcet Sarikaya To: iesg-secretary@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: multimob@ietf.org, draft-ietf-multimob-igmp-mld-tuning@tools.ietf.org Subject: [multimob] Request to progress Multimob WG I-D draft-ietf-multimob-igmp-mld-tuning 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: Mon, 27 Feb 2012 19:58:55 -0000 Dear IESG, The Multimob WG I-D. draft-ietf-multimob-igmp-mld-tuning-04 on Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks has successfully completed working group last call and is ready to be progressed. Please consider this as a request for review and approval for publication of this I-D by the IESG. The shepherd document follows. Regards, Behcet (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational Yes Yes (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The abstract is OK Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd is Behcet Sarikaya Responsible Area Director is Jari Arkko (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The chairs have reviewed the document and it is ready for publication (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I have no concerns on the document (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. There have been no IPR disclosures filed on this document (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There have been no IPR disclosures filed on this document (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a strong consensus behind this solution (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Nobody has threatened to appeal and the document has the backing of the WG as a whole (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nit errors/warnings are present on the document (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document meets the review criteria (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no actions for IANA in this document. However, an IANA considerations section stating that does exist. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language segments exist From sarikaya2012@gmail.com Wed Feb 29 08:42:43 2012 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 827BB21F867A for ; Wed, 29 Feb 2012 08:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 BiReFHoy3mQo for ; Wed, 29 Feb 2012 08:42:43 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E459621F8799 for ; Wed, 29 Feb 2012 08:42:42 -0800 (PST) Received: by yenm5 with SMTP id m5so1645450yen.31 for ; Wed, 29 Feb 2012 08:42:42 -0800 (PST) Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.100.212.4 as permitted sender) client-ip=10.100.212.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.100.212.4 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com Received: from mr.google.com ([10.100.212.4]) by 10.100.212.4 with SMTP id k4mr491557ang.35.1330533762538 (num_hops = 1); Wed, 29 Feb 2012 08:42:42 -0800 (PST) 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=CMuTMXf84k8DjhcuT2DEGYDCGoAXCNCCU8l1EwplFag=; b=VxytvJd0sqc6+wATFQvVAa+Cu2uCYKOCO3/DmZ29+e7TL9zrPQ/x5SNIHFhGYV3gO6 OgvIS0+aAY27bh5itIh63Tt/qLSNs/UfyFLKMmds6s1uSzh+FekQRv+r62nsYdy2O/kq Klu9NRApu8MMvaFNBhe1vFTGeeQ2UFizWuxEI= MIME-Version: 1.0 Received: by 10.100.212.4 with SMTP id k4mr387561ang.35.1330533762486; Wed, 29 Feb 2012 08:42:42 -0800 (PST) Received: by 10.236.9.73 with HTTP; Wed, 29 Feb 2012 08:42:42 -0800 (PST) Date: Wed, 29 Feb 2012 10:42:42 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multimob] Draft agenda 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: Wed, 29 Feb 2012 16:42:43 -0000 is posted at http://www.ietf.org/proceedings/83/agenda/agenda-83-multimob.html please take a look. Behcet