From owner-malloc@catarina.usc.edu Fri May 4 08:58:50 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11415 for ; Fri, 4 May 2001 08:58:48 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id FAA57620 for malloc-list; Fri, 4 May 2001 05:35:53 -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]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id FAA57614; Fri, 4 May 2001 05:35:52 -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 FAA02273; Fri, 4 May 2001 05:35:51 -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 OAA25448; Fri, 4 May 2001 14:32:05 +0200 (MET DST) Message-ID: <3AF2A147.257D9F2@irisa.fr> Date: Fri, 04 May 2001 14:32:07 +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 , malloc@catarina.usc.edu Subject: Re: sdr References: <200104272116.OAA40076@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 hello again, 1- If we think that the problem is that SDR dont scale, then can we say that with sdr there is no collision problem ?? 2- the collision is made by whom , the application?? how does an aplication choose an address group ?? thanx Pavlin Ivanov Radoslavov wrote: > > 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 Fri May 4 12:40:31 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16427 for ; Fri, 4 May 2001 12:40:29 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA58596 for malloc-list; Fri, 4 May 2001 09:15:16 -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 JAA58586; Fri, 4 May 2001 09:14:41 -0700 (PDT) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id JAA35112; Fri, 4 May 2001 09:14:41 -0700 (PDT) Message-Id: <200105041614.JAA35112@rumi.usc.edu> To: Ali Boudani cc: malloc@catarina.usc.edu Subject: Re: sdr In-reply-to: Your message of "Fri, 04 May 2001 14:32:07 +0200." <3AF2A147.257D9F2@irisa.fr> Date: Fri, 04 May 2001 09:14:41 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk > hello again, > 1- If we think that the problem is that SDR dont scale, then can we say that > with sdr there is no collision problem ?? Just the opposite. If too many people use sdr to allocate addresses, this solution will not scale for two major reasons: a) There will be too much control traffic. b) The probability for collision will be very high and therefore for practical purposes it will take very long time to allocate an address. > 2- the collision is made by whom , the application?? > how does an aplication choose an address group ?? sdr chooses the address(es) and all collisions happen at the sdr level. If the allocation succeedes, then sdr will provide the address to the application(s) (only those applications that are explicitly supported by sdr for auto-launch) . BTW, please note that sdr does not have real API so it cannot be used directly by any application; instead it is more like a GUI-based interface. Regards, Pavlin > Pavlin Ivanov Radoslavov wrote: > > > > 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 Fri May 4 12:52:39 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16776 for ; Fri, 4 May 2001 12:52:38 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA58678 for malloc-list; Fri, 4 May 2001 09:29:52 -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 JAA58673 for ; Fri, 4 May 2001 09:29:52 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id JAA35180 for malloc@catarina.usc.edu; Fri, 4 May 2001 09:29:51 -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 JAA58657; Fri, 4 May 2001 09:26:31 -0700 (PDT) Received: from purple.east.isi.edu ([192.12.209.178]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA05413; Fri, 4 May 2001 09:26:31 -0700 (PDT) Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id MAA10603; Fri, 4 May 2001 12:25:29 -0400 Message-Id: <200105041625.MAA10603@purple.east.isi.edu> To: Pavlin Ivanov Radoslavov cc: Ali Boudani , malloc@catarina.usc.edu Subject: Re: sdr In-Reply-To: Message from Pavlin Ivanov Radoslavov of "Fri, 04 May 2001 09:14:41 PDT." <200105041614.JAA35112@rumi.usc.edu> Date: Fri, 04 May 2001 12:25:29 -0400 From: Colin Perkins Sender: owner-malloc@catarina.usc.edu Precedence: bulk --> Pavlin Ivanov Radoslavov writes: >> hello again, >> 1- If we think that the problem is that SDR dont scale, then can we say that >> with sdr there is no collision problem ?? > >Just the opposite. If too many people use sdr to allocate addresses, >this solution will not scale for two major reasons: > a) There will be too much control traffic. > b) The probability for collision will be very high and therefore > for practical purposes it will take very long time to allocate an > address. I'd say that b) is probably the main issue: SAP traffic should back-off to avoid the problem of too much control traffic, but the time taken to allocate an address will become large very quickly. >> 2- the collision is made by whom , the application?? >> how does an aplication choose an address group ?? > >sdr chooses the address(es) and all collisions happen at the sdr >level. If the allocation succeedes, then sdr will provide the >address to the application(s) (only those applications that are >explicitly supported by sdr for auto-launch) . BTW, please note that >sdr does not have real API so it cannot be used directly by any >application; instead it is more like a GUI-based interface. Sure, but an application could run the SAP protocol directly (or one could use another means to communicate with a long-running SAP agent). This is much the same as running a single global allocation domain with the MALLOC protocols though. Colin From owner-malloc@catarina.usc.edu Wed May 9 17:54:33 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26476 for ; Wed, 9 May 2001 17:54:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA82192 for malloc-list; Wed, 9 May 2001 14:33:08 -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 OAA82187 for ; Wed, 9 May 2001 14:33:06 -0700 (PDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA03914 for ; Wed, 9 May 2001 14:33:06 -0700 (PDT) Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00145; Wed, 9 May 2001 14:32:57 -0700 (PDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27723; Wed, 9 May 2001 17:32:56 -0400 (EDT) Message-ID: <3AF9B682.6B6148B7@sun.com> Date: Wed, 09 May 2001 17:28:34 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: malloc , mboned@network-services.uoregon.edu Subject: The Future of AAP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit The Address Allocation Protocol (AAP) was designed to fill Layer 2 in the Internet Multicast Address Allocation Architecture (RFC 2908), allowing Multicast Address Allocation Servers (MAAS's) within an allocation domain to coordinate their allocations. The latest AAP specification is available from: http://www.aciri.org/malloc/draft-ietf-malloc-aap-04.txt Last summer, this specification passed Working Group Last Call in the MALLOC Working Group and was sent to the IESG for consideration as a Proposed Standard. Since that time, several issues have been raised with the protocol, especially scaling concerns. An alternative protocol (ZMAAP) has been developed for use within Zero Configuration networks. At this time, there seems to be little interest in updating the AAP protocol specification to address the issues that have been raised. Several people have stated that if multiple MAAS's need to coordinate, they can use a proprietary mechanism (as is often done with DHCP servers). The MALLOC Working Group Chairs would like to ask the multicast community: 1) Do people think that the AAP protocol is still needed? 2) If so, are there any volunteers to help revise the document and address the issues that have been raised? Unless we receive an affirmative answer to both of these questions, we will withdraw the document from IESG consideration. Steve Hanna Dave Thaler MALLOC WG Chairs From owner-malloc@catarina.usc.edu Thu May 17 15:33:12 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 PAA25545 for ; Thu, 17 May 2001 15:33:11 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA30223 for malloc-list; Thu, 17 May 2001 12:03: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 MAA30218 for ; Thu, 17 May 2001 12:03:32 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA21954 for ; Thu, 17 May 2001 12:03:31 -0700 (PDT) Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02917; Thu, 17 May 2001 12:03:23 -0700 (PDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09890; Thu, 17 May 2001 15:03:21 -0400 (EDT) Message-ID: <3B041F6C.E412B16F@sun.com> Date: Thu, 17 May 2001 14:58:52 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Bradner , Allison Mankin CC: Thomas Narten , malloc , ietf-secretariat@ietf.org, mboned@network-services.uoregon.edu Subject: Please withdraw AAP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit The Multicast Address Allocation working group has determined that there is not at this time sufficient interest in progressing the Address Allocation Protocol (AAP) specification (draft-ietf-malloc-aap-04.txt) to Proposed Standard status. Please remove this document from your queue. We will also request that it be removed from the list of work items for our working group. Thanks, Steve Hanna MALLOC WG Co-Chair From owner-malloc@catarina.usc.edu Wed May 23 08:02:45 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 IAA01670 for ; Wed, 23 May 2001 08:02:43 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id EAA62575 for malloc-list; Wed, 23 May 2001 04:34:12 -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 EAA62570 for ; Wed, 23 May 2001 04:34:08 -0700 (PDT) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id EAA05864 for ; Wed, 23 May 2001 04:34:07 -0700 (PDT) Received: from alceste (alceste.enst.fr [137.194.160.88]) by infres.enst.fr (Postfix) with SMTP id 5731F18AD; Wed, 23 May 2001 13:27:21 +0200 (MET DST) Message-ID: <009501c0e37b$6c9599c0$58a0c289@enst.fr> From: "Meddour Djamal Eddine" To: Cc: , , , "Meraihi Rabah" Subject: Any News about Malloc work group Date: Wed, 23 May 2001 13:28:00 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01C0E38C.2FCA7D60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-malloc@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C0E38C.2FCA7D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello After the last mail of malloc work groupe about AAP, is there any = protocol that will replaced AAP ? Or there is a new architecture of = Multicast address allocation ? regards=20 Djamal Eddine ---- Djamal Eddine Meddour ENST - D=E9partement Informatique et R=E9seaux 46, rue Barrault - 75634 Paris Cedex 13 - France Web: http://www.enst.fr/~meddour Mail: meddour@enst.fr ------=_NextPart_000_0092_01C0E38C.2FCA7D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello
 
After the last mail of malloc work = groupe about=20 AAP, is there any protocol that will replaced AAP ? Or there is a new architecture of Multicast address = allocation=20 ?
 
regards 
 
Djamal Eddine
----
Djamal Eddine=20 Meddour
ENST - D=E9partement Informatique et R=E9seaux
46, rue = Barrault -=20 75634 Paris Cedex 13 - France
Web: http://www.enst.fr/~meddour
M= ail: =20 meddour@enst.fr
------=_NextPart_000_0092_01C0E38C.2FCA7D60-- From owner-malloc@catarina.usc.edu Wed May 23 08:36: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 IAA02728 for ; Wed, 23 May 2001 08:36:28 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id FAA62709 for malloc-list; Wed, 23 May 2001 05:18:10 -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 FAA62704 for ; Wed, 23 May 2001 05:18:09 -0700 (PDT) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id FAA09553 for ; Wed, 23 May 2001 05:18:08 -0700 (PDT) Received: from horla.enst.fr (horla.enst.fr [137.194.161.1]) by infres.enst.fr (Postfix) with ESMTP id 3C1EE189F; Wed, 23 May 2001 14:11:22 +0200 (MET DST) Received: (from dax@localhost) by horla.enst.fr (8.9.3+Sun/8.9.3) id OAA11166; Wed, 23 May 2001 14:11:20 +0200 (MEST) Date: Wed, 23 May 2001 14:11:20 +0200 From: Philippe Dax To: Meddour Djamal Eddine Cc: malloc@catarina.usc.edu, dax@enst.fr, demeure@enst.fr, parmentier@enst.fr, Meraihi Rabah Subject: Re: Any News about Malloc work group Message-ID: <20010523141120.A11108@horla.enst.fr> References: <009501c0e37b$6c9599c0$58a0c289@enst.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us In-Reply-To: Meddour Djamal Eddine on Wed, May 23, 2001 at 01:28:00PM +0200 X-Organization: ENST X-WWW: http://www.infres.enst.fr/~dax/ X-Whois: whois -h whois.ripe.net PD97 Sender: owner-malloc@catarina.usc.edu Precedence: bulk On 23/05, Meddour Djamal Eddine wrote: | Hello | | After the last mail of malloc work groupe about AAP, ~~~~~~~~~~~~~~~~~~ Malloc Working Group | is there any protocol that will replaced AAP ? ~~~~~~~~ replace Is there an alternative for AAP or a new direction of MAAP ? Or can we undertand that the MAAP is reduced to only MADCAP and MASC ? | Or there is a new architecture of Multicast address allocation ? | | regards