From owner-malloc@catarina.usc.edu Tue Apr 17 05:23:20 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04628 for ; Tue, 17 Apr 2001 05:23:20 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id BAA65410 for malloc-list; Tue, 17 Apr 2001 01:50:34 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id BAA65405 for ; Tue, 17 Apr 2001 01:50:33 -0700 (PDT) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id BAA29865 for ; Tue, 17 Apr 2001 01:50:32 -0700 (PDT) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id KAA13833 for ; Tue, 17 Apr 2001 10:46:46 +0200 (MET DST) Message-ID: <3ADC02F5.CE3D5C5@irisa.fr> Date: Tue, 17 Apr 2001 10:46:45 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: malloc@catarina.usc.edu Subject: time to wait Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit hello, In MASC isnt 48 hours a long time for a time to wait??? what does time to wait mean exactly?? is 48 h mean that if we want to use multicast adresses , we have at startup to wait 48 hours to begin use the multicast or what ?? Thanx From owner-malloc@catarina.usc.edu Tue Apr 17 05:56:29 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04770 for ; Tue, 17 Apr 2001 05:56:28 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA66043 for malloc-list; Tue, 17 Apr 2001 02:38:55 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA66038; Tue, 17 Apr 2001 02:38:52 -0700 (PDT) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id CAA42894; Tue, 17 Apr 2001 02:38:52 -0700 (PDT) Message-Id: <200104170938.CAA42894@rumi.usc.edu> To: Ali Boudani cc: malloc@catarina.usc.edu Subject: Re: time to wait In-reply-to: Your message of "Tue, 17 Apr 2001 10:46:45 +0200." <3ADC02F5.CE3D5C5@irisa.fr> Date: Tue, 17 Apr 2001 02:38:52 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk > In MASC isnt 48 hours a long time for a time to wait??? > what does time to wait mean exactly?? This large value is for robustness. Because MASC is designed to be used in an environment with non-negligible probability for network partitioning, its claim period has the conservative value of 48 hours. In most cases it takes less than 24 hours for an Internet Service Provider to fix a network-related problem such as intra or inter-domain partitioning. Hence, waiting for 48 hours should be long enough to ensure the end-to-end claim propagation, and therefore the uniqueness of the allocation. > is 48 h mean that if we want to use multicast adresses , we have at > startup to wait 48 hours to begin use the multicast or what ?? Only when you start MASC for a very first time in your domain. After that the allocation to the application should not be affected by the MASC operation. MASC is inter-domain allocation; within a domain there are AAP/MADCAP which are much faster. After a prefix is allocated to a domain (MASC always tries to stay ahead of the usage by allocating the prefix(es) in advance), then AAP+MADCAP use this prefix to allocate the particular addresses to the application. MADCAP is a DHCP-style protocol, and it will allocate the mcast address(es) to the application with similar latency (within few seconds, if not faster). Pavlin From owner-malloc@catarina.usc.edu Tue Apr 17 06:08:30 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04871 for ; Tue, 17 Apr 2001 06:08:28 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA66102 for malloc-list; Tue, 17 Apr 2001 02:49:39 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA66096; Tue, 17 Apr 2001 02:49:38 -0700 (PDT) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA18379; Tue, 17 Apr 2001 02:49:37 -0700 (PDT) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id LAA19946; Tue, 17 Apr 2001 11:45:51 +0200 (MET DST) Message-ID: <3ADC10CF.4E7FEAE@irisa.fr> Date: Tue, 17 Apr 2001 11:45:51 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: Pavlin Ivanov Radoslavov CC: malloc@catarina.usc.edu Subject: Re: time to wait References: <200104170938.CAA42894@rumi.usc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit ok I understood But care should take now of how much time the adresses are allocated to the same domain. if an address is allocated to a domain and after a while we didnt use this adress, of course the domain will loose the allocated domain address so in this case we have also to wait 48 hours again ??? is that true? thanx Pavlin Ivanov Radoslavov wrote: > > In MASC isnt 48 hours a long time for a time to wait??? > > what does time to wait mean exactly?? > > This large value is for robustness. > Because MASC is designed to be used in an environment with > non-negligible probability for network partitioning, its claim > period has the conservative value of 48 hours. In most cases it > takes less than 24 hours for an Internet Service Provider to fix a > network-related problem such as intra or inter-domain partitioning. > Hence, waiting for 48 hours should be long enough to ensure the > end-to-end claim propagation, and therefore the uniqueness of the > allocation. > > > is 48 h mean that if we want to use multicast adresses , we have at > > startup to wait 48 hours to begin use the multicast or what ?? > > Only when you start MASC for a very first time in your domain. After > that the allocation to the application should not be affected > by the MASC operation. MASC is inter-domain allocation; within a > domain there are AAP/MADCAP which are much faster. After a prefix is > allocated to a domain (MASC always tries to stay ahead of the usage > by allocating the prefix(es) in advance), then AAP+MADCAP use this > prefix to allocate the particular addresses to the > application. MADCAP is a DHCP-style protocol, and it will allocate > the mcast address(es) to the application with similar latency > (within few seconds, if not faster). > > Pavlin From owner-malloc@catarina.usc.edu Tue Apr 17 06:24:13 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05023 for ; Tue, 17 Apr 2001 06:24:11 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id DAA66147 for malloc-list; Tue, 17 Apr 2001 03:02:24 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id DAA66142; Tue, 17 Apr 2001 03:02:20 -0700 (PDT) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id DAA42979; Tue, 17 Apr 2001 03:02:20 -0700 (PDT) Message-Id: <200104171002.DAA42979@rumi.usc.edu> To: Ali Boudani cc: malloc@catarina.usc.edu Subject: Re: time to wait In-reply-to: Your message of "Tue, 17 Apr 2001 11:45:51 +0200." <3ADC10CF.4E7FEAE@irisa.fr> Date: Tue, 17 Apr 2001 03:02:20 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk > ok I understood > But care should take now of how much time the adresses are allocated to > the same domain. > if an address is allocated to a domain and after a while we didnt use > this adress, of course the domain will loose the allocated domain address > so in this case we have also to wait 48 hours again ??? If the allocated prefix is under-utilised (e.g., under 50%), when it is close to expire, MASC will reclain only some part of the original prefix such that the renewed prefix will be reasonably utilised. If after time the usage of mcast addresses in this domain goes to zero (and is zero for long amount of time, to say few months), then MASC may "return" (by not reclaiming it) the original prefix, and will keep renewing only a small prefix for that domain (to say, of the order of 256 addresses or even smaller). If the demand for addresses increases, then MASC will try to allocate a larger prefix before it is really needed. BTW, the above description is not part of the MASC protocol, but is one possible algorithm of how to keep the address space reasonably utilised, and at the same time to "stay ahead" of the demand for addresses (and therefore avoid the application waiting for 48 hours). Pavlin > is that true? > thanx > > > Pavlin Ivanov Radoslavov wrote: > > > > In MASC isnt 48 hours a long time for a time to wait??? > > > what does time to wait mean exactly?? > > > > This large value is for robustness. > > Because MASC is designed to be used in an environment with > > non-negligible probability for network partitioning, its claim > > period has the conservative value of 48 hours. In most cases it > > takes less than 24 hours for an Internet Service Provider to fix a > > network-related problem such as intra or inter-domain partitioning. > > Hence, waiting for 48 hours should be long enough to ensure the > > end-to-end claim propagation, and therefore the uniqueness of the > > allocation. > > > > > is 48 h mean that if we want to use multicast adresses , we have at > > > startup to wait 48 hours to begin use the multicast or what ?? > > > > Only when you start MASC for a very first time in your domain. After > > that the allocation to the application should not be affected > > by the MASC operation. MASC is inter-domain allocation; within a > > domain there are AAP/MADCAP which are much faster. After a prefix is > > allocated to a domain (MASC always tries to stay ahead of the usage > > by allocating the prefix(es) in advance), then AAP+MADCAP use this > > prefix to allocate the particular addresses to the > > application. MADCAP is a DHCP-style protocol, and it will allocate > > the mcast address(es) to the application with similar latency > > (within few seconds, if not faster). > > > > Pavlin From owner-malloc@catarina.usc.edu Thu Apr 26 06:18:24 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27233 for ; Thu, 26 Apr 2001 06:18:23 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA17138 for malloc-list; Thu, 26 Apr 2001 02:55:58 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA17133 for ; Thu, 26 Apr 2001 02:55:55 -0700 (PDT) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA10185 for ; Thu, 26 Apr 2001 02:55:54 -0700 (PDT) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id LAA11274 for ; Thu, 26 Apr 2001 11:52:03 +0200 (MET DST) Message-ID: <3AE7EFC4.C23C1BCA@irisa.fr> Date: Thu, 26 Apr 2001 11:52:04 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: malloc@catarina.usc.edu Subject: sdr Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit hello, sdr is used to announce an address for an application and that address is used taking into account different parameters (region, ...). so what is the difference in general with Malloc and MASC?? thanx From owner-malloc@catarina.usc.edu Fri Apr 27 17:44:41 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17108 for ; Fri, 27 Apr 2001 17:44:41 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA24839 for malloc-list; Fri, 27 Apr 2001 14:17:02 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA24834; Fri, 27 Apr 2001 14:16:58 -0700 (PDT) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id OAA40076; Fri, 27 Apr 2001 14:16:58 -0700 (PDT) Message-Id: <200104272116.OAA40076@rumi.usc.edu> To: Ali Boudani cc: malloc@catarina.usc.edu Subject: Re: sdr In-reply-to: Your message of "Thu, 26 Apr 2001 11:52:04 +0200." <3AE7EFC4.C23C1BCA@irisa.fr> Date: Fri, 27 Apr 2001 14:16:58 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk > sdr is used to announce an address for an application and that address > is used taking into account different parameters (region, ...). so what > is the difference in general with Malloc and MASC?? sdr is here and works (assuming that everybody uses sdr to allocate mcast addresses). However, sdr will not scale to a large number of groups, therefore the need for malloc. Both MASC and AAP, which are part of the malloc arcitecture, use the same principle for address allocation as sdr, except that it has been adapted for the particular requrements for MASC or AAP. Pavlin From owner-malloc@catarina.usc.edu Mon Apr 30 11:48:12 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16234 for ; Mon, 30 Apr 2001 11:48:11 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA37772 for malloc-list; Mon, 30 Apr 2001 08:20:00 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA37767 for ; Mon, 30 Apr 2001 08:19:59 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id IAA52725 for malloc@catarina.usc.edu; Mon, 30 Apr 2001 08:19:58 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id EAA37091 for ; Mon, 30 Apr 2001 04:10:21 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id EAA09563 for ; Mon, 30 Apr 2001 04:10:19 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04714; Mon, 30 Apr 2001 07:06:57 -0400 (EDT) Message-Id: <200104301106.HAA04714@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: malloc@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-malloc-ipv6-guide-02.txt Date: Mon, 30 Apr 2001 07:06:56 -0400 Sender: owner-malloc@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast-Address Allocation Working Group of the IETF. Title : Dynamic Allocation Guidelines for IPv6 Multicast Addresses Author(s) : B. Haberman Filename : draft-ietf-malloc-ipv6-guide-02.txt Pages : 5 Date : 27-Apr-01 This document specifies guidelines to be used when allocating IPv6 multicast addresses. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the MAC layer of media that utilizes IEEE 802 addressing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-ipv6-guide-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-malloc-ipv6-guide-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-malloc-ipv6-guide-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010427152750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-ipv6-guide-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-ipv6-guide-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010427152750.I-D@ietf.org> --OtherAccess-- --NextPart--