From owner-malloc@catarina.usc.edu Mon Aug 7 16:25:58 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14279 for ; Mon, 7 Aug 2000 16:25:57 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA49730 for malloc-list; Mon, 7 Aug 2000 13:15:04 -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 NAA49725 for ; Mon, 7 Aug 2000 13:15:03 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id NAA07444 for malloc@catarina.usc.edu; Mon, 7 Aug 2000 13:15:03 -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 LAA48902 for ; Mon, 7 Aug 2000 11:06:17 -0700 (PDT) Received: from ziggy.stardust.com (root@ns.stardust.com [205.184.205.34]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA20477 for ; Mon, 7 Aug 2000 11:06:16 -0700 (PDT) Received: from pleiades (dhcp204-96.stardust.com [205.184.204.96]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA27720 for ; Mon, 7 Aug 2000 11:03:47 -0700 Message-Id: <3.0.5.32.20000807110349.014345f0@stardust.com> X-Sender: jasonu@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Aug 2000 11:03:49 -0700 To: malloc@catarina.usc.edu From: Jason Utz Subject: Call for multicast papers - iBAND at ISPCON Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id LAA48903 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Greetings! IP Multicast is one of the core technologies covered at the iBAND events. We would like to continue its progress at the upcoming iBAND at ISPCON Conference on November 8-10, 2000, in San Jose, CA. iBAND at ISPCON is a gathering place for key industry people to come together and learn about developments in the new Internet technologies: * Service Provisioning * Traffic Management * Performance Measurement * Your iBAND at ISPCON participation will help expose network engineers and other technology savvy professionals to the latest and greatest in IP Multicast technology. My name is Jason Utz, conference manager for iBAND at ISPCON Conference. Stardust.com's CTO Martin Hall and I would like to invite you to share you progress and ideas with other relevant professionals in one or more ways: · Speaker Proposal * BOF Proposal * Showcase Participation * We value your expertise and look forward to receiving your speaker proposals to reflect the state of the art in IP Multicast technology. Proposals are due no later than Friday, August 18, 2000. To find guidance and more information, please visit http://www.stardust.com/iband5/speakers.htm http://www.stardust.com for network engineers offers additional opportunities to supply information and progress for IP Multicast updates and technologies: - conference sessions available in MP3 format, - live interviews on Stardust.com TalkRadio, - provide white papers and have them maintained in a Stardust.com Web library. All these options provide you with a large arena to deliver your working group's information and other updates. Please visit http://www.stardust.com to see what our site offers to its visitors. We want to help you drive this technology area forward so please let me know how you'd like to participate. Please contact me via email with any questions. Best regards, Jason Utz Conference Manager Stardust.com Jasonu@stardust.com www.stardust.com ***************** Stardust.com********************* Visit Stardust.com http://www.stardust.com Making sense of new Internet stuff Visit Stardust Talkradio Mondays in MP3 Format! *************************************************** Home of the IP Multicast Initiative (IPMI) the QoS Forum (QOSF) and the Wireless Multimedia Forum (WMF) NEW! *************************************************** UPCOMING EVENTS: *iBAND at ISPCON - Nov. 8-10, 2000, San Jose, CA *WISE, The Wireless Internet Services Event - Nov. 6-7, San Jose, CA ***************************************************** Jason Utz Conference Manager 15575 Los Gatos Blvd Suite C Fax 408/402-0567 Los Gatos, CA 95032 From owner-malloc@catarina.usc.edu Mon Aug 21 16:18:16 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08434 for ; Mon, 21 Aug 2000 16:18:16 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA17607 for malloc-list; Mon, 21 Aug 2000 13:03:00 -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 NAA17602 for ; Mon, 21 Aug 2000 13:02:59 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA24049 for ; Mon, 21 Aug 2000 13:02:59 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA20576 for ; Mon, 21 Aug 2000 16:01:05 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA28808 for ; Mon, 21 Aug 2000 16:01:06 -0400 Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA12163 for ; Mon, 21 Aug 2000 16:00:01 -0400 Message-Id: <200008212000.QAA12163@rotala.raleigh.ibm.com> To: malloc@catarina.usc.edu Subject: AAP: comments coming In-Reply-To: Message from Steve Hanna of "Thu, 06 Jul 2000 11:13:24 EDT." <3964A214.2AF658FE@sun.com> Date: Mon, 21 Aug 2000 16:00:01 -0400 From: Thomas Narten Sender: owner-malloc@catarina.usc.edu Precedence: bulk As part of the IESG's consideration of this document, I made a detailed review of draft-ietf-malloc-aap-04.txt. I have a number of comments, some of which may be just questions, some of which will be requests for wording clarification, etc. Rather than dump a long list of comments to the list in a single message, I'll attempt to start a number of threads. Note also that all that I know about the AAP protocol is what I have read in the draft. I have not been following the technical discussion closely, so I don't know which issues were contentious, etc. On the other hand, it should be considered a feature that I don't have surrounding context, as it means my input comes from someone who has only read the spec. Specific comments to follow... Thomas From owner-malloc@catarina.usc.edu Mon Aug 21 16:22:25 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08521 for ; Mon, 21 Aug 2000 16:22:24 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA17680 for malloc-list; Mon, 21 Aug 2000 13:12:49 -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 NAA17675 for ; Mon, 21 Aug 2000 13:12:48 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA02680 for ; Mon, 21 Aug 2000 13:12:48 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA21658 for ; Mon, 21 Aug 2000 16:10:57 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA25390 for ; Mon, 21 Aug 2000 16:11:00 -0400 Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA12211 for ; Mon, 21 Aug 2000 16:09:54 -0400 Message-Id: <200008212009.QAA12211@rotala.raleigh.ibm.com> To: malloc@catarina.usc.edu Subject: AAP: Rebroadcasting second-hand information In-Reply-To: Message from Steve Hanna of "Thu, 06 Jul 2000 11:13:24 EDT." <3964A214.2AF658FE@sun.com> Date: Mon, 21 Aug 2000 16:09:54 -0400 From: Thomas Narten Sender: owner-malloc@catarina.usc.edu Precedence: bulk This protocol has the characteristic that a node that receives information (e.g., address X is allocated) will in some circumstances resend that information. For example, in the case of a network partition, one wants a MAAS with knowledge of an allocation made by another MAAS (one that is currently unreachable due to network partitioning) to resend that information in some cases so that duplicate allocations are avoided. Likewise, the document explicitely says a Prefix Coordinator doesn't have to maintain stable storage, and can "relearn" information that it was the original source for because other MAASes will continue advertising that information in its absence. I worry that this particular model will lead to serious debugging and operational problems. For example, if bogus information gets into the system (either through misconfiguration, bad implemenations, data corruption, etc.) it will be quite difficult to stamp it out. If you kill it in one place, it will pop up again from some other source. Likewise, the way the protocol is currently defined, it will be very difficult to determine the source of the bad information. This is because the messages don't include information about the original source of information, rather, it includes only the minimal information needed to determine that an address is allocated. Here are some things that I think should be thought about: 1) for AIU messages, it might make sense for an address that is marked in-use to include information indicating who (i.e., which MAAS) has it in-use. That way, if MAAS A is simply repeating information that MAAS B has address X in use, the AIU message A sends outs will say "A is using X". Note that the current protocol sends out messages of the form "someone (but it might not be me) is using address X". 2) I'm concerned that the rules regarding which messages supercede which previous messages are complex and may not handle all the cases properly. From a protocol perspective, it would be much cleaner if a MAAS could look at a message, determine the original sender of that message (in the case where the information is actually a resending of sorts), and then do a simple check to determine whether that information is older or newer than something it already has. For example, if an AIU record for address X included the owning MAAS (say A) and a timestamp indicating when A sent out the AIU for X, it would be easy for a receiver to determine whether to accept or reject a particular message. The analogy I have is to routing protocols, where the change from "old arpanet" to "new arpanent" algorithms went to a model in which raw data was propogated unchanged so as to be sure that all receivers acted on the same and most-up-to-date information. As an example of a specific concern I have, Section 3.2.8 includes some rules for handling partitioned networks, reductions in the expiration time, etc.: > Note that if some MAAS's are partitioned from the network during the > time when this deletion is being announced, they may defend the > earlier allocation when they are later reconnected. In this case, the > MAAS that deleted the allocation SHOULD advertise the allocation > again with the correct end time (now in the past) so that it is > deleted from the Allocation Records of the MAAS's that were > partitioned. The above seem quite complex, and I'm not sure its even correct. How does the MAAS that deleted the allocation earlier even know that the current allocation actually refers to the allocation it made earlier? It *could* be an entirely new allocation made by some other node, in which case the above advertisement would be incorrect. I think this sort of thing can be easily addressed by making it more clear who actually is owning an address allocation. That way, the owner herself can always step in and say "hey, that's old, here is the correct information". Thomas From owner-malloc@catarina.usc.edu Mon Aug 21 16:29:09 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08616 for ; Mon, 21 Aug 2000 16:29:07 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA17663 for malloc-list; Mon, 21 Aug 2000 13:11:23 -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 NAA17658 for ; Mon, 21 Aug 2000 13:11:22 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA01484 for ; Mon, 21 Aug 2000 13:11:22 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA30380 for ; Mon, 21 Aug 2000 16:09:32 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA31686 for ; Mon, 21 Aug 2000 16:09:33 -0400 Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA12200 for ; Mon, 21 Aug 2000 16:08:27 -0400 Message-Id: <200008212008.QAA12200@rotala.raleigh.ibm.com> To: malloc@catarina.usc.edu Subject: AAP: Chattiness of protocol In-Reply-To: Message from Steve Hanna of "Thu, 06 Jul 2000 11:13:24 EDT." <3964A214.2AF658FE@sun.com> Date: Mon, 21 Aug 2000 16:08:27 -0400 From: Thomas Narten Sender: owner-malloc@catarina.usc.edu Precedence: bulk This protocol seems fairly "chatty" to me, and I wonder how well it will scale in practice. Things to note: 0) All MAAS messages are multicast to a multicast group, so they are transmitted throughout a administrative network. 1) All MAASes send periodic multicast AIU messages every 30 seconds. This is to cover the entire state of the Allocation Record (I believe). 2) Whenever a MAAS allocates an address (e.g., from its preallocated set), it immediately sends out an AIU for those addresses, following up with retransmissions for reliability. 3) For non-preallocated addresses, a MAAS sends sequence of ACLM messages (including retransmissions for reliability) when a request to allocate an address is made. Result: for a moderately large site, it seems like the protocol could generate quite a lot of traffic. This especially true if a large number of addresses are allocated. I have concerns as to how large an environment this will scale to. Given the time scales involved (shouldn't addresses be allocated for relatively long periods of time?), it seems like the protocol could relax some of its timing constraints, especially with regards to periodic multicast. Or to delay sending out AIU for pre-allocated addresses in order to batch them up. It also seems like the model could do more to encourage pre-allocation, so that becomes the normal way to assign addresses. Right now, I don't read the spec as suggesting this is required. Finally, what size of environment is this protocol expected to scale to? Is their consensus that the protocol will do so? Thomas From owner-malloc@catarina.usc.edu Tue Aug 22 03:55:21 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29073 for ; Tue, 22 Aug 2000 03:55:20 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id AAA19542 for malloc-list; Tue, 22 Aug 2000 00:45:23 -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 AAA19537 for ; Tue, 22 Aug 2000 00:45:22 -0700 (PDT) Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id AAA10903 for ; Tue, 22 Aug 2000 00:45:21 -0700 (PDT) Received: from sigma2.sm.luth.se (sigma2.sm.luth.se [130.240.2.9]) by sm.luth.se (8.10.0/8.10.0) with ESMTP id e7M7fgC11428; Tue, 22 Aug 2000 09:41:42 +0200 (MET DST) Date: Tue, 22 Aug 2000 09:41:46 +0200 (MET DST) From: Adam Dunkels To: Thomas Narten cc: malloc@catarina.usc.edu Subject: Re: AAP: Rebroadcasting second-hand information In-Reply-To: <200008212009.QAA12211@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk On Mon, 21 Aug 2000, Thomas Narten wrote: > Here are some things that I think should be thought about: > > 1) for AIU messages, it might make sense for an address that is marked > in-use to include information indicating who (i.e., which MAAS) has > it in-use. That way, if MAAS A is simply repeating information that > MAAS B has address X in use, the AIU message A sends outs will say > "A is using X". Note that the current protocol sends out messages > of the form "someone (but it might not be me) is using address X". This problem also pertains to AAP management and logging in that it is impossible to correctly log the owner of each allocation. In our experimental AAP implementation made for Telia (avaliable from http://extwww.lulea.trab.se/i-lab/malloc) we used the IP level source address of the sender of the AIU messsages to log the owner of each allocation, but this crude mechanism may, as stated, be misleading. Also, in a typical environment, the AAP nodes are likely to be central servers for other services such as NIS, NFS and mail. There is a good chance such servers are multihomed, and may thus send AIU messages (or ACLM messages, or any type of message, for that matter) with different source IP addresses (depending on the outgoing interface), which might lead to even more administrative and logging problems. Each message might also be duplicated on the different interfaces, resulting in duplicate messages with different source IP addresses. In such a case, every received message must be checked against a list of the hosts own IP addresses to determine that a message did not come from oneself. Also, for other hosts multiple messages for the same address range with different source IP addresses will be confusing. If each AAP message included an identification of the sender, a multihomed host would only need to pick one of its IP addresses at startup and always use it as its identifier. /adam -- Adam Dunkels