From pooperbulker@hotmail.com Thu Nov 2 07:59:21 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07193 for ; Thu, 2 Nov 2000 07:59:21 -0500 (EST) From: pooperbulker@hotmail.com Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id DAA22404 for ; Thu, 2 Nov 2000 03:47:49 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eA2Bllv26700 for ; Thu, 2 Nov 2000 03:47:47 -0800 (PST) Received: from piaexch01.PIA_DC1 ([12.4.59.5]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id DAA29525 for ; Thu, 2 Nov 2000 03:47:46 -0800 (PST) Date: Thu, 2 Nov 2000 03:47:46 -0800 (PST) Message-Id: <200011021147.DAA29525@proxy3.cisco.com> Received: from internetpro (cust24.max13.seattle-k56.aa.net [206.125.87.24]) by piaexch01.PIA_DC1 with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VTCVN4SR; Thu, 2 Nov 2000 06:40:05 -0500 To: poopeybulker@hotmail.com Subject: Strong Buy Recommendation (CPHX) MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit OTC Spotlight's previous BUY ALERTS have gained over 367 % !!! Congratulations to those that participated in our previous alerts: CNXX from $ 1.94 to $4.84, ACEN from $ .18 to $ .85, and SRGL from $5.63 to $10.75! STRONG BUY: Clements Golden Phoenix Enterprises, Inc. OTCBB: CPHX BUY AT $1.88 SELL TARGET $6.50 SPECIAL ALERT... CPHX AWARDED EXCLUSIVE DISTRIBUTION RIGHTS TO SUPPLY CITRUS PRODUCTS TO MILLIONS OF CHINESE CONSUMERS ! CPHX DOMINATES THE $10 BILLION CITRUS PRODUCTS MARKET IN CHINA'S NEW GROWING ECONOMY !!! Clements Golden Phoenix Enterprises (CPHX) is capitalizing on China's recent acceptance into the World Trade Organization (WTO) coupled with the lifting of a 20-year ban on importing American citrus, thus creating perhaps the most financially explosive opportunity ever in that nation. These perfectly timed political maneuvers have vaulted CPHX into the position of becoming the "Minute Maid" or "Tropicana" of China to the country's 1.2 BILLION people. A key element in the purchase of CPHX shares is that the stock is extremely undiscovered and undervalued. During the 2 months that shares have been trading, market conditions have limited the exposure of CPHX to new investors. Even a 2 for 1 (forward) split that took place earlier this month went practically unnoticed. This enhances the opportunity for profit with CPHX trading near its low while revenues soar! Armed with major U.S. and Chinese political backing, CPHX has partnered with the largest dairy and consumer foods distributors throughout China. The exclusive licensing and distribution awarded to CPHX follows the Government of China's program to make citrus products and juices more readily available and affordable while promoting the awareness of health and nutrition. As China makes rapid leaps to catch up to worldwide standards, China has addressed the fact that it's citrus production is less than one-fourth of what the U.S. produces while having 5 times the population. Market research performed by Tropicana Juices owned by PepesiCo (NYSE: PEP) and Minute Maid owned by Coca Cola (NYSE: KO) have forecast annual sales of citrus products to be in the $BILLIONS for a nation in a frenzy for the fresh fruits and juices they have gone so long without. The vast, "wide open" citrus market will eventually lead to joint ventures, partnerships, or perhaps much more in the future between the major players in this arena now that ground has been broken. OTCBB: CPHX Recent Price: $1.88 52 Week High/Low: $4.19 - $1.88 Shares Outstanding: 28.5 Million Float: 1.5 Million Target Price: $6.50 The expectation of astronomical sales is bolstered by China's friendly attitude and environment towards CPHX to capture significant market share. As a new WTO member, the eyes of many nations are tracking China's handling and progress of citrus importation. This includes the drastic lowering of tariffs on citrus, juices, and frozen concentrate to keep in line with the standard trade practices of other WTO member nations. Our research on CPHX clearly reveals that its exponential growth has not yet been noticed by investors. Increased attention with expanding volume is expected as strong company news is released. We anticipate many other well known newsletters will also be exposing CPHX to their subscribers in the near term. With its low float and undervalued stock price, CPHX has the potential to outperform even our best recommendations in the past few months! DISCLAIMER: OTC Spotlight Newsletter cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of OTC Spotlight. All information concerning the companies is received directly from the companies profiled and/or outside interviews conducted by OTC Spotlight. OTC Spotlight recommends you use the information found here as an initial starting point for conducting your own research and conduct your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. OTC Spotlight assumes all information to be truthful and reliable; however, we cannot and do not warrant or guarantee the accuracy of this information. All statements contained herein are deemed to be factual as of the date of this report and as such are subject to change without notice. OTC Spotlight is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such OTC Spotlight is not offering investment advice or p! romoting any investment strategies. OTC Spotlight is not offering securities for sale or solicitation of any offer to buy or sell securities. An offer to buy or sell can be made only with accompanying disclosure documents and only in the states and provinces for which they are approved. Any reference in the newsletter to past performance(s) of companies previously profiled in the newsletter are specially selected to be referenced based on the favorable performance of said companies and the companies referenced may not be representative of all past profiles as not all past profiles have performed as well. Please remember that past performance does not predict future results which is why it's called "past performance". On occasion OTC Spotlight receives compensation from a third party in relation to the company being profiled in its newsletter sent to our subscribers. In such a case OTC Spotlight directly mentions this in its newsletter sent to our subscribers along with the exa! ct form and amount of compensation. OTC Spotlight has rec! ei! ved five thousand free trading shares from a third party for the dissemination of this company profile. OTC Spotlight, its affiliates, associates, relatives and anyone associated with OTC Spotlight in any manner reserves the right to either buy or sell shares in the profiled company's stock, either before the date of the profile, during the date of the profile or at any time after the date of the profile. We have an inherent conflict of interest by sending the newsletter at the same time we may own stock in the same company or even have been paid compensation at the time of the profile/promotion. We reserve the right to sell shares at anytime, even during the time period in which we are profiling a company. OTC Spotlight may profile companies trading in fast moving, highly volatile markets, and any reader of this newsletter should observe the trading behavior of any profiled company prior to investing. From investor@hotmail.com Fri Nov 3 04:51:25 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16527 for ; Fri, 3 Nov 2000 04:51:20 -0500 (EST) From: investor@hotmail.com Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA00416 for ; Fri, 3 Nov 2000 00:31:15 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eA38VLa04318 for ; Fri, 3 Nov 2000 00:31:21 -0800 (PST) Received: from mail.class-ic.com (mail3.class-ic.com [38.232.69.160]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id AAA28153 for ; Fri, 3 Nov 2000 00:31:12 -0800 (PST) Date: Fri, 3 Nov 2000 00:31:12 -0800 (PST) Message-Id: <200011030831.AAA28153@proxy1.cisco.com> Received: from internetpro (cust43.max4.seattle-k56.aa.net [206.125.78.43]) by mail.class-ic.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 44K3YWRJ; Fri, 3 Nov 2000 00:34:08 -0800 To: investing@hotmail.com Subject: Register To Win Your Dream Vacation MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit To review the details of the Vacation Package & Pentium PC giveaway please click on the confirmation number below: To Confirm - #5BSI8945M CLICK HERE: ; Fri, 3 Nov 2000 05:36:23 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id BAA14839 for ; Fri, 3 Nov 2000 01:25:16 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eA39PEU16397 for ; Fri, 3 Nov 2000 01:25:14 -0800 (PST) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id BAA12731 for ; Fri, 3 Nov 2000 01:25:04 -0800 (PST) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.16) id 13rcno-0001jp-00; Fri, 03 Nov 2000 10:06:24 +0100 Received: from ee.tu-berlin.de (fitzek@ariel.ee.TU-Berlin.DE [130.149.49.157]) by ftmail.ee.tu-berlin.de (8.9.3/8.9.3) with ESMTP id KAA29582; Fri, 3 Nov 2000 10:06:15 +0100 Sender: fitzek@ftmail.ee.TU-Berlin.DE Message-ID: <3A028007.9B1D7013@ee.tu-berlin.de> Date: Fri, 03 Nov 2000 10:06:15 +0100 From: fitzek Organization: TKN X-Mailer: Mozilla 4.75 [de] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: end2end-interest@isi.edu, cost264@lip6.fr, maddogs@ietf.org, ssm-interest@external.cisco.com, members@tmforum.org, n2k-oc@comsoc.org, af-all@atmforum.com, transinet-all Subject: MPEG-4 and H.263 Video Traces for Network Performance Evaluation Content-Type: multipart/mixed; boundary="------------32F42B7A626E51DC8921CB56" Dies ist eine mehrteilige Nachricht im MIME-Format. --------------32F42B7A626E51DC8921CB56 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Colleagues, we would like to announce a publicly available library of frame size traces of MPEG-4 and H.263 encoded videos: http://www-tkn.ee.tu-berlin.de/research/trace/trace.html or http://www-tkn.ee.tu-berlin.de/~fitzek/TRACE/trace.html We have encoded over ten videos of 60 minutes length each. For each video we have generated MPEG-4 and H.263 encodings at several different quality levels. All in all, we provide over 70 hours worth of video traces. The video traces may be used for network performance studies. For reference purposes and detailed information on the traces we refer to the Technical Report "MPEG-4 and H.263 Video Traces for Network Performance Evaluation", TKN-00-06, TU Berlin, Dept. of Electrical Eng., Oct. 2000, which is available at http://www-tkn.ee.tu-berlin.de/~fitzek/TRACE/pub.html Your feedback is highly welcome and appreciated. Best Regards, Frank Fitzek and Martin Reisslein TU Berlin Arizona State University fitzek@ee.tu-berlin.de reisslein@asu.edu http://www-tkn.ee.tu-berlin.de/~fitzek http://www.public.asu.edu/~mreissl -- * Frank H.P. Fitzek * fitzek@ee.tu-berlin.de * * Telekommunikationsnetze * phone +49-30-314-23830 * * Technische Universitaet Berlin * fax +49-30-314-23818 * * WWW page http://www-tkn.ee.tu-berlin.de * * WWW homepage http://www-tkn.ee.tu-berlin.de/~fitzek * --------------32F42B7A626E51DC8921CB56 Content-Type: text/x-vcard; charset=iso-8859-1; name="fitzek.vcf" Content-Description: Karte für fitzek Content-Disposition: attachment; filename="fitzek.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgCm46Rml0emVrO0ZyYW5rIEguUC4KeC1tb3ppbGxhLWh0bWw6RkFMU0UK b3JnOlRVIEJlcmxpbjtUS04KYWRyOjs7Ozs7Owp2ZXJzaW9uOjIuMQplbWFpbDtpbnRlcm5l dDpmaXR6ZWtAZWUudHUtYmVybGluLmRlCnRpdGxlOkRpcGwuLUluZwp4LW1vemlsbGEtY3B0 OjswCmZuOkZyYW5rIEguUC4gRml0emVrCmVuZDp2Y2FyZAo= --------------32F42B7A626E51DC8921CB56-- From hv@of-hachetal.de Fri Nov 3 21:14:43 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04611 for ; Fri, 3 Nov 2000 21:14:42 -0500 (EST) From: hv@of-hachetal.de Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA09229 for ; Fri, 3 Nov 2000 17:11:49 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eA41BmK03787 for ; Fri, 3 Nov 2000 17:11:48 -0800 (PST) Received: from mindray-inter.mindray.com.cn ([202.103.148.18]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id RAA27824 for ; Fri, 3 Nov 2000 17:11:40 -0800 (PST) Date: Fri, 3 Nov 2000 17:11:40 -0800 (PST) Message-Id: <200011040111.RAA27824@proxy3.cisco.com> Received: from 1cust239.tnt2.mia5.da.uu.net by mindray-inter.mindray.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) id WD22C8RQ; Sat, 4 Nov 2000 09:02:21 +0800 To: hv@of-hachetal.de Subject: At last, Herbal V, the all natural alternative to V----A! Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$44, 2 bottles=$64, 3 bottles=$75 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From Rolland.Vida@lip6.fr Wed Nov 8 14:14:57 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05963 for ; Wed, 8 Nov 2000 14:14:57 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA22172 for ; Wed, 8 Nov 2000 09:57:42 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eA8Hvdq20888 for ; Wed, 8 Nov 2000 09:57:39 -0800 (PST) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id JAA05664 for ; Wed, 8 Nov 2000 09:57:20 -0800 (PST) Received: from rp.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.9.3/jtpda-5.3.2) with ESMTP id SAA09235 ; Wed, 8 Nov 2000 18:30:21 +0100 Received: from rp.lip6.fr (otos.lip6.fr [132.227.61.47]) by rp.lip6.fr (8.8.8/jtpda-5.2) with ESMTP id SAA12289 ; Wed, 8 Nov 2000 18:30:19 +0100 (MET) Message-ID: <3A098DAB.52FD42BD@rp.lip6.fr> Date: Wed, 08 Nov 2000 18:30:19 +0100 From: Vida Rolland Organization: Laboratoire Lip6 X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, ssm-interest@external.cisco.com, Supratik Bhattacharyya Subject: MLDv3 - Internet Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear All, The revised IPng Working Group Charter published on the 5th of October on the mailing list of the IPng WG contained a call for contribution on "Extending MLD to include functionality of IGMPv3". Here is the abstract of an Internet Draft proposal, called "Multicast Listener Discovery Version 3 (MLDv3) for IPv6" () ************* Abstract: This document specifies Version 3 of the Multicast Listener Discovery protocol, MLDv3. MLD is the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. MLDv3 is derived from version 3 of IPv4's Internet Group Management Protocol, IGMPv3. Compared to the previous version, MLDv3 adds support for "source filtering", that is, the ability for a node to report interest in listening to packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to links where there are no interested listeners. When compared to IGMPv3, one important difference to note is that MLDv3 uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. ************ The full text of the draft can be found at: http://www-rp.lip6.fr/~vida/draft-vida-mld-v3-00.txt We welcome any comments or suggestions on the text. Best regards, Rolland Vida, LIP6, Paris, France. ----------------------------------------------------------------------- "Not everything that can be counted counts, and not everything that counts can be counted. " - Albert Einstein Rolland Vida Universite Paris VI "Pierre et Marie Curie" tel: +33 (0)144 277 126 Laboratoire LIP6 - CNRS, C669 fax: +33 (0)144 277 495 8, Rue de Capitaine Scott, 75015, Paris mailto:vida@rp.lip6.fr ----------------------------------------------------------------------- From cdiot@sprintlabs.com Wed Nov 8 20:09:46 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26661 for ; Wed, 8 Nov 2000 20:09:46 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA10114 for ; Wed, 8 Nov 2000 15:40:31 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eA8NeTA19079 for ; Wed, 8 Nov 2000 15:40:29 -0800 (PST) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id PAA04600 for ; Wed, 8 Nov 2000 15:40:26 -0800 (PST) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78) id <47VNGVPH>; Wed, 8 Nov 2000 15:36:40 -0800 Message-ID: <90B65CE19D3DD411895400805F0DAA7A0BDFF7@mailman.sprintlabs.com> From: Christophe Diot To: NGC2000-PC , "'Cost264@lip6.fr'" , "'rm@mash.CS.Berkeley.EDU'" , "'maddogs@ietf.org'" , "'ssm-interest@external.cisco.com'" , "'rmt@lbl.gov'" Subject: NGC 2000 retransmission on SSM Date: Wed, 8 Nov 2000 15:36:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain 8, November, 2000 Thanks to Sprint, Cisco, the University of Oregon, UC-Santa Barbara, and Stanford University, NGC2000, the Second International Workshop on Networked Group Communication is being multicast live from the Stanford University Campus Nov. 8-10. The conference s being transmitted in real-time via Source Specific Multicast. Sessions are only available by SSM. For information on joining, see the University of Oregon Videolab session page at: http://videolab.uoregon.edu/cgi-bin/urd.cgi to join. This is the first event to be retransmitted over SSM. The conference is being held at Stanford University in Palo Alto, California from November 8th to the 10th and the program can be found at: http://www.cs.ucsb.edu/ngc2000/program/ The aim of the Workshop is to allow researchers and practitioners to present the design and implementation techniques for networked group communication. The focus of the Workshop is strictly on multicast and networked group communication. This Workshop is the second and only international event in this area (first workshop was in Pisa, Italy, in November 1999). From hansen.chan@alcatel.com Thu Nov 9 09:57:51 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26774 for ; Thu, 9 Nov 2000 09:57:50 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id FAA26800 for ; Thu, 9 Nov 2000 05:27:38 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eA9DRZ828649 for ; Thu, 9 Nov 2000 05:27:35 -0800 (PST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id FAA29253 for ; Thu, 9 Nov 2000 05:27:32 -0800 (PST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id IAA01113 for ; Thu, 9 Nov 2000 08:02:39 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdJAAntnc1_; Thu Nov 9 08:02:36 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ssm-interest@external.cisco.com; Thu, 9 Nov 2000 08:08:50 -0500 Received: from alcatel.com ([138.120.51.119]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA68FE for ; Thu, 9 Nov 2000 08:08:49 -0500 Message-Id: <3A0AA1DC.ADA864F6@alcatel.com> Date: Thu, 09 Nov 2000 08:08:45 -0500 From: "HANSEN CHAN" X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ssm-interest@external.cisco.com Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit subscribe hansen.chan@alcatel.com From tbat@freeze.com Sun Nov 12 04:00:46 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25006 for ; Sun, 12 Nov 2000 04:00:46 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id XAA23615 for ; Sat, 11 Nov 2000 23:06:33 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAC76TX10595 for ; Sat, 11 Nov 2000 23:06:29 -0800 (PST) Received: from mail.redhot.com.tw ([210.241.250.11]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id XAA17470 for ; Sat, 11 Nov 2000 23:06:25 -0800 (PST) Received: from host (cranston-ip-1-154.dynamic.ziplink.net [209.206.4.154]) by mail.redhot.com.tw (8.8.7/8.8.7) with ESMTP id MAA30581; Sun, 12 Nov 2000 12:32:53 +0800 Message-Id: <200011120432.MAA30581@mail.redhot.com.tw> From: "Karl Turner" Subject: Your Listing #3230 To: ieg39f@mail.redhot.com.tw X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Sat, 11 Nov 2000 22:31:07 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form

Dear Professional,

You have been selected as a potential candidate for a free
listing in the 2000 - 2001 Edition of the International Executive
Guild Registry=2E

Please accept our congratulations for this coveted honor=2E

As this edition is so important in view of the new millennium, the
International Executive Guild Registry will be published in two
different formats; the searchable CD-ROM and the Online Registry=2E

Since inclusion can be considered recognition of your career position
= and professionalism, each candidate is evaluated in keeping with high
= standards of individual achievement=2E In light of this, the Internationa= l
Executive Guild thinks that you may make an interesting biographical
subject=2E

We look forward to your inclusion and appearance in the International
= Executive Guild's Registry=2E Best wishes for your continued success=2E
International Executive Guild
Listing Dept=2E

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E

International Executive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Guild, For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Guild=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of  www=2E  Confirmation of its de= livery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From hansen.chan@alcatel.com Tue Nov 14 19:14:20 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16203 for ; Tue, 14 Nov 2000 19:14:20 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA21958 for ; Tue, 14 Nov 2000 15:00:00 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAEMxpC21541 for ; Tue, 14 Nov 2000 14:59:51 -0800 (PST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id OAA22809 for ; Tue, 14 Nov 2000 14:59:49 -0800 (PST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id RAA27438 for ; Tue, 14 Nov 2000 17:34:51 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdBAAynYOD_; Tue Nov 14 17:34:41 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ssm-interest@external.cisco.com; Tue, 14 Nov 2000 17:40:54 -0500 Received: from alcatel.com ([138.120.51.119]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA2BF0 for ; Tue, 14 Nov 2000 17:40:53 -0500 Message-Id: <3A11BF3B.C25DF39A@alcatel.com> Date: Tue, 14 Nov 2000 17:39:56 -0500 From: "HANSEN CHAN" X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ssm-interest@external.cisco.com Subject: Use of SAP in a PIM SSM Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all, I am trying to understand in a pure SSM network without any shared tree, how would SAP operate? My understanding is that SAP is transmitting on a shared tree. Does it mean that we always stuck with a PIM-SM shared tree, even in a pure SSM network? Cheers, Hansen From eckert@cisco.com Tue Nov 14 19:29:40 2000 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20101 for ; Tue, 14 Nov 2000 19:29:40 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA11488 for ; Tue, 14 Nov 2000 18:18:12 -0500 (EST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA29744; Tue, 14 Nov 2000 15:16:15 -0800 (PST) From: Toerless Eckert Message-Id: <200011142316.PAA29744@cisco.com> Subject: Re: Use of SAP in a PIM SSM Network To: hansen.chan@alcatel.com (HANSEN CHAN) Date: Tue, 14 Nov 2000 15:16:15 -0800 (PST) Cc: ssm-interest@external.cisco.com In-Reply-To: <3A11BF3B.C25DF39A@alcatel.com> from "HANSEN CHAN" at Nov 14, 2000 05:39:56 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I am trying to understand in a pure SSM network without any shared tree, > how would SAP operate? My understanding is that SAP is transmitting on a > shared tree. Does it mean that we always stuck with a PIM-SM shared > tree, even in a pure SSM network? I think you have a network without a shared tree and without SAP. You can of course use SSM to get SAP information, but the receivers need to know the address of the sources in the first place, which is a bit beyond the point of what SAP was meant for in the first place. SAP is nice to have in limited environments, but simply trying to broadcast directory information on a world-wide scale is not a scaling solution. Already today lots of SDP sessions are just made available via the web instead of SAP. -- Toerless From tme@21rst-century.com Tue Nov 14 23:14:32 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12253 for ; Tue, 14 Nov 2000 23:14:31 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id TAA03047 for ; Tue, 14 Nov 2000 19:00:48 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAF30rx14707 for ; Tue, 14 Nov 2000 19:00:57 -0800 (PST) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id TAA17367 for ; Tue, 14 Nov 2000 19:00:40 -0800 (PST) Received: from [216.8.29.208] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 562349; Tue, 14 Nov 2000 21:41:48 -0500 Message-ID: <3A11F843.6B70A1A4@21rst-century.com> Date: Tue, 14 Nov 2000 21:43:15 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Toerless Eckert , Ross Finlayson , Al Adler CC: HANSEN CHAN , ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network References: <200011142316.PAA29744@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Toerless Eckert wrote: > > > I am trying to understand in a pure SSM network without any shared tree, > > how would SAP operate? My understanding is that SAP is transmitting on a > > shared tree. Does it mean that we always stuck with a PIM-SM shared > > tree, even in a pure SSM network? > > I think you have a network without a shared tree and without SAP. You can > of course use SSM to get SAP information, but the receivers need to know > the address of the sources in the first place, which is a bit beyond the > point of what SAP was meant for in the first place. SAP is nice to have > in limited environments, but simply trying to broadcast directory information > on a world-wide scale is not a scaling solution. Already today lots of > SDP sessions are just made available via the web instead of SAP. > > -- Toerless I am not sure that I agree with this. We would certainly be interested in hosting a directory service using SSM, and I suspect others would as well. I would, in fact, claim that in some ways a multicast directory service scales better than web pages FOR AGGREGATED INFORMATION. Suppose that one fine day there are 50,000 SSM groups in permanent operation. Clearly, a web page covering ALL of these groups would basically be a search engine - just a list would not be useful. If each group was announced by a sap type packet with a size (say) of 200 bytes, to go through the entire list would require 10 megabytes. Even if 8 kilobits/sec were allocated to a multicast directory service, it would still take > 3 hours to go through all of these announcements. If, however, the groups were divided into 100 classes, each with ~500 members, and each class getting its own SSM group for directory announcements, all the sessions in a class could be discovered in only 100 seconds, about the time it takes the program announcements on Channel 1 of my cable TV service to cycle through. I think that such a service would be useful; therefore I think that, while SAP may die, multicast session announcements will live on. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From luby@digitalfountain.com Wed Nov 15 00:08:07 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24224 for ; Wed, 15 Nov 2000 00:08:06 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA28196 for ; Tue, 14 Nov 2000 20:02:56 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAF42pv01414 for ; Tue, 14 Nov 2000 20:02:56 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id UAA08578 for ; Tue, 14 Nov 2000 20:02:19 -0800 (PST) Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id TAA14345; Tue, 14 Nov 2000 19:34:19 -0800 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: "Mike Luby" To: , "Toerless Eckert" , "Ross Finlayson" , "Al Adler" Cc: "HANSEN CHAN" , Subject: RE: Use of SAP in a PIM SSM Network Date: Tue, 14 Nov 2000 19:34:12 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A11F843.6B70A1A4@21rst-century.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Transfer-Encoding: 7bit I think there are different kinds of services that can be offered, and that is the difference in the discussion below. I happen to agree with Toerless that webpage access is the more natural way that SSM groups will be accessed. Today, there are many many more than 50,000 pieces of content and streams available on the web from different content providers, and there is absolutely no attempt to make available a centralized listing of all those piece of content in one place on one webpage: each content provider makes their content available on their webpages through hyperlinks, and the organization and presentation of that content is designed by them according to their needs. For example, Yahoo has many many pieces of content and streams available on its extensive website, and each one is accessed by the click of a hyperlink on a given webpage. There is absolutely no attempt to have a global organization of all the content and streams available on the Internet. Thus, I'm wondering what is so special about SSM, and why it won't roll into the same access model as all other content and streams out there? I suspect that if something different is attempted to organize SSM content and streams that was different than the rest of the Internet, then it will have a very limited use on the general Internet. This is the beauty of SSM: it really fits into current practices for making content and streams available on the Internet. Each content provider can independently source their own SSM streams just like they put content up on their webpages today available through http servers, and they don't have to worry about the old style of having a global listing service of all multicast groups in the world (which I suspect was there more because of the problems with having multicast group address clashes, which is not a problem for SSM), they just list their SSM content and streams as they are today on their webpages. The advantage of course is the massive scalability that SSM offers (of course, this is assuming it is deployed across the Internet as we all hope). The advantage of listing SSM content and streams on webpages is that it is what is done today for other content and this way nobody has to change their current practices. Of course, this is not to say that a global listing service would not be useful, but I'm not sure I see why this is anymore useful than a service that is a global listing service for all content and streams on the Internet, i.e., what is special about SSM streams versus other streams other than the massive scalability of SSM? My two cents, Mike -----Original Message----- From: Marshall Eubanks [mailto:tme@21rst-century.com] Sent: Tuesday, November 14, 2000 6:43 PM To: Toerless Eckert; Ross Finlayson; Al Adler Cc: HANSEN CHAN; ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network Toerless Eckert wrote: > > > I am trying to understand in a pure SSM network without any shared tree, > > how would SAP operate? My understanding is that SAP is transmitting on a > > shared tree. Does it mean that we always stuck with a PIM-SM shared > > tree, even in a pure SSM network? > > I think you have a network without a shared tree and without SAP. You can > of course use SSM to get SAP information, but the receivers need to know > the address of the sources in the first place, which is a bit beyond the > point of what SAP was meant for in the first place. SAP is nice to have > in limited environments, but simply trying to broadcast directory information > on a world-wide scale is not a scaling solution. Already today lots of > SDP sessions are just made available via the web instead of SAP. > > -- Toerless I am not sure that I agree with this. We would certainly be interested in hosting a directory service using SSM, and I suspect others would as well. I would, in fact, claim that in some ways a multicast directory service scales better than web pages FOR AGGREGATED INFORMATION. Suppose that one fine day there are 50,000 SSM groups in permanent operation . Clearly, a web page covering ALL of these groups would basically be a search engine - just a list would not be useful. If each group was announced by a sap type packet with a size (say) of 200 bytes, to go through the entire list would require 10 megabytes. Even if 8 kilobits/sec were allocated to a multicast directory service, it would still take > 3 hours to go through all of these announcements. If, however, the groups were divided into 100 classes, each with ~500 members, and each class getting its own SSM group for directory announcements, all the sessions in a class could be discovered in only 100 seconds, about the time it takes the program announcements on Channel 1 of my cable TV service to cycle through. I think that such a service would be useful; therefore I think that, while SAP may die, multicast session announcements will live on. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From zalbanna@MCI.NET Wed Nov 15 02:21:45 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01974 for ; Wed, 15 Nov 2000 02:21:44 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA13219 for ; Tue, 14 Nov 2000 21:59:47 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAF5xkD28242 for ; Tue, 14 Nov 2000 21:59:46 -0800 (PST) Received: from NOD.RESTON.MCI.NET ([166.60.6.38]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id VAA04489 for ; Tue, 14 Nov 2000 21:59:43 -0800 (PST) Received: from zaid ([166.60.14.234]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JWJTTNKE9S9N4C1K@shoe.reston.mci.net> for ssm-interest@external.cisco.com; Wed, 15 Nov 2000 00:56:48 EST Date: Wed, 15 Nov 2000 01:01:01 -0500 From: zaid Subject: Re: Use of SAP in a PIM SSM Network To: Mike Luby , tme@21rst-century.com, Toerless Eckert , Ross Finlayson , Al Adler Cc: HANSEN CHAN , ssm-interest@external.cisco.com Message-id: <002601c04ec9$6f2591a0$4eac1218@zaid.loudoun.mci.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook Express 4.72.3110.1 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT How does this help the end user ? It seems that having a mechanism similar in functionality to SAP would be preferred by users. Using the direct TV model, a user may not want to access the provider's channel to view the list of streams available from that provider. By having a directory service, users will have one place to access to choose any content from any provider. Scalability will be one of the issues to resolve, ultimately the flexibility of this model will likely make it more desirable and usable. Thanks, Zaid -----Original Message----- From: Mike Luby To: tme@21rst-century.com ; Toerless Eckert ; Ross Finlayson ; Al Adler Cc: HANSEN CHAN ; ssm-interest@external.cisco.com Date: Tuesday, November 14, 2000 11:36 PM Subject: RE: Use of SAP in a PIM SSM Network I think there are different kinds of services that can be offered, and that is the difference in the discussion below. I happen to agree with Toerless that webpage access is the more natural way that SSM groups will be accessed. Today, there are many many more than 50,000 pieces of content and streams available on the web from different content providers, and there is absolutely no attempt to make available a centralized listing of all those piece of content in one place on one webpage: each content provider makes their content available on their webpages through hyperlinks, and the organization and presentation of that content is designed by them according to their needs. For example, Yahoo has many many pieces of content and streams available on its extensive website, and each one is accessed by the click of a hyperlink on a given webpage. There is absolutely no attempt to have a global organization of all the content and streams available on the Internet. Thus, I'm wondering what is so special about SSM, and why it won't roll into the same access model as all other content and streams out there? I suspect that if something different is attempted to organize SSM content and streams that was different than the rest of the Internet, then it will have a very limited use on the general Internet. This is the beauty of SSM: it really fits into current practices for making content and streams available on the Internet. Each content provider can independently source their own SSM streams just like they put content up on their webpages today available through http servers, and they don't have to worry about the old style of having a global listing service of all multicast groups in the world (which I suspect was there more because of the problems with having multicast group address clashes, which is not a problem for SSM), they just list their SSM content and streams as they are today on their webpages. The advantage of course is the massive scalability that SSM offers (of course, this is assuming it is deployed across the Internet as we all hope). The advantage of listing SSM content and streams on webpages is that it is what is done today for other content and this way nobody has to change their current practices. Of course, this is not to say that a global listing service would not be useful, but I'm not sure I see why this is anymore useful than a service that is a global listing service for all content and streams on the Internet, i.e., what is special about SSM streams versus other streams other than the massive scalability of SSM? My two cents, Mike -----Original Message----- From: Marshall Eubanks [mailto:tme@21rst-century.com] Sent: Tuesday, November 14, 2000 6:43 PM To: Toerless Eckert; Ross Finlayson; Al Adler Cc: HANSEN CHAN; ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network Toerless Eckert wrote: > > > I am trying to understand in a pure SSM network without any shared tree, > > how would SAP operate? My understanding is that SAP is transmitting on a > > shared tree. Does it mean that we always stuck with a PIM-SM shared > > tree, even in a pure SSM network? > > I think you have a network without a shared tree and without SAP. You can > of course use SSM to get SAP information, but the receivers need to know > the address of the sources in the first place, which is a bit beyond the > point of what SAP was meant for in the first place. SAP is nice to have > in limited environments, but simply trying to broadcast directory information > on a world-wide scale is not a scaling solution. Already today lots of > SDP sessions are just made available via the web instead of SAP. > > -- Toerless I am not sure that I agree with this. We would certainly be interested in hosting a directory service using SSM, and I suspect others would as well. I would, in fact, claim that in some ways a multicast directory service scales better than web pages FOR AGGREGATED INFORMATION. Suppose that one fine day there are 50,000 SSM groups in permanent operation . Clearly, a web page covering ALL of these groups would basically be a search engine - just a list would not be useful. If each group was announced by a sap type packet with a size (say) of 200 bytes, to go through the entire list would require 10 megabytes. Even if 8 kilobits/sec were allocated to a multicast directory service, it would still take > 3 hours to go through all of these announcements. If, however, the groups were divided into 100 classes, each with ~500 members, and each class getting its own SSM group for directory announcements, all the sessions in a class could be discovered in only 100 seconds, about the time it takes the program announcements on Channel 1 of my cable TV service to cycle through. I think that such a service would be useful; therefore I think that, while SAP may die, multicast session announcements will live on. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From sjkoh@pec.etri.re.kr Wed Nov 15 03:23:43 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03964 for ; Wed, 15 Nov 2000 03:23:42 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA09146 for ; Tue, 14 Nov 2000 23:07:50 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAF77nY27634 for ; Tue, 14 Nov 2000 23:07:49 -0800 (PST) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id XAA22671 for ; Tue, 14 Nov 2000 23:07:45 -0800 (PST) Received: from sjkoh (sjkoh.etri.re.kr [129.254.164.46]) by pec.etri.re.kr (8.10.0/8.10.0) with SMTP id eAF6lVd24885; Wed, 15 Nov 2000 15:47:32 +0900 (KST) Message-ID: <001d01c04ed0$54b0a240$2ea4fe81@etri.re.kr> Reply-To: "Seok Joo Koh" From: "Seok Joo Koh" To: "zaid" , "Mike Luby" , , "Toerless Eckert" , "Ross Finlayson" , "Al Adler" Cc: "HANSEN CHAN" , References: <002601c04ec9$6f2591a0$4eac1218@zaid.loudoun.mci.net> Subject: Re: Use of SAP in a PIM SSM Network Date: Wed, 15 Nov 2000 15:50:22 +0900 Organization: ETRI/PEC MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit IMHO, the use of SAP may diminish the merit of SSM anyway. As an alternative for the directory service that users will access to choose any content from any provider, we may think of a common web page service, supported by many content providers. Anyway, SAP has concerns that its traffic has to be generated and delivered to all the users including a large number of uninterest users, and this may give the non-trivial traffic burden to ISPs. Seok J. Koh ETRI/PEC sjkoh@pec.etri.re.kr ----- Original Message ----- From: zaid To: Mike Luby ; ; Toerless Eckert ; Ross Finlayson ; Al Adler Cc: HANSEN CHAN ; Sent: Wednesday, November 15, 2000 3:01 PM Subject: Re: Use of SAP in a PIM SSM Network > How does this help the end user ? It seems that having a mechanism > similar > in functionality to SAP would be preferred by users. Using the direct > TV model, > a user may not want to access the provider's channel to view the list > of streams > available from that provider. By having a directory service, users > will have one > place to access to choose any content from any provider. Scalability > will be one > of the issues to resolve, ultimately the flexibility of this model > will likely make > it more desirable and usable. > > Thanks, > Zaid > > -----Original Message----- > From: Mike Luby > To: tme@21rst-century.com ; Toerless Eckert > ; Ross Finlayson ; Al Adler > > Cc: HANSEN CHAN ; > ssm-interest@external.cisco.com > Date: Tuesday, November 14, 2000 11:36 PM > Subject: RE: Use of SAP in a PIM SSM Network > > > I think there are different kinds of services that can be offered, and > that > is the difference in the discussion below. I happen to agree with > Toerless > that webpage access is the more natural way that SSM groups will be > accessed. Today, there are many many more than 50,000 pieces of > content and > streams available on the web from different content providers, and > there is > absolutely no attempt to make available a centralized listing of all > those > piece of content in one place on one webpage: each content provider > makes > their content available on their webpages through hyperlinks, and the > organization and presentation of that content is designed by them > according > to their needs. For example, Yahoo has many many pieces of content > and > streams available on its extensive website, and each one is accessed > by the > click of a hyperlink on a given webpage. There is absolutely no > attempt to > have a global organization of all the content and streams available on > the > Internet. Thus, I'm wondering what is so special about SSM, and why > it > won't roll into the same access model as all other content and streams > out > there? I suspect that if something different is attempted to organize > SSM > content and streams that was different than the rest of the Internet, > then > it will have a very limited use on the general Internet. This is the > beauty > of SSM: it really fits into current practices for making content and > streams > available on the Internet. Each content provider can independently > source > their own SSM streams just like they put content up on their webpages > today > available through http servers, and they don't have to worry about the > old > style of having a global listing service of all multicast groups in > the > world (which I suspect was there more because of the problems with > having > multicast group address clashes, which is not a problem for SSM), they > just > list their SSM content and streams as they are today on their > webpages. The > advantage of course is the massive scalability that SSM offers (of > course, > this is assuming it is deployed across the Internet as we all hope). > The > advantage of listing SSM content and streams on webpages is that it is > what > is done today for other content and this way nobody has to change > their > current practices. Of course, this is not to say that a global > listing > service would not be useful, but I'm not sure I see why this is > anymore > useful than a service that is a global listing service for all content > and > streams on the Internet, i.e., what is special about SSM streams > versus > other streams other than the massive scalability of SSM? > > My two cents, > Mike > > -----Original Message----- > From: Marshall Eubanks [mailto:tme@21rst-century.com] > Sent: Tuesday, November 14, 2000 6:43 PM > To: Toerless Eckert; Ross Finlayson; Al Adler > Cc: HANSEN CHAN; ssm-interest@external.cisco.com > Subject: Re: Use of SAP in a PIM SSM Network > > > Toerless Eckert wrote: > > > > > I am trying to understand in a pure SSM network without any shared > tree, > > > how would SAP operate? My understanding is that SAP is > transmitting on a > > > shared tree. Does it mean that we always stuck with a PIM-SM > shared > > > tree, even in a pure SSM network? > > > > I think you have a network without a shared tree and without SAP. > You can > > of course use SSM to get SAP information, but the receivers need to > know > > the address of the sources in the first place, which is a bit beyond > the > > point of what SAP was meant for in the first place. SAP is nice to > have > > in limited environments, but simply trying to broadcast directory > information > > on a world-wide scale is not a scaling solution. Already today lots > of > > SDP sessions are just made available via the web instead of SAP. > > > > -- Toerless > > I am not sure that I agree with this. We would certainly be interested > in hosting a directory service using SSM, and I suspect others would > as > well. I would, in fact, claim that in some ways a multicast directory > service scales better than web pages FOR AGGREGATED INFORMATION. > > Suppose that one fine day there are 50,000 SSM groups in permanent > operation > . > Clearly, a web page covering ALL of these groups would basically be a > search > engine - just a list would not be useful. If each group was announced > by a sap type packet with a size (say) of 200 bytes, to go through the > entire > list would require 10 megabytes. Even if 8 kilobits/sec were allocated > to > a multicast directory service, it would still take > 3 hours to go > through > all of these announcements. If, however, the groups were divided into > 100 > classes, each with ~500 members, and each class getting its own SSM > group > for directory announcements, all the sessions in a class could be > discovered in > only 100 seconds, about the time it takes the program announcements on > Channel > 1 of my cable TV service to cycle through. I think that such a service > would be > useful; therefore I think that, while SAP may die, multicast session > announcements > will live on. > > > > Regards > Marshall Eubanks > > > Multicast Technologies, Inc. > 10301 Democracy Lane, Suite 201 > Fairfax, Virginia 22030 > Phone : 703-293-9624 Fax : 703-293-9609 > e-mail : tme@on-the-i.com http://www.on-the-i.com > > > From J.Crowcroft@cs.ucl.ac.uk Wed Nov 15 04:17:12 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29987 for ; Wed, 15 Nov 2000 04:17:12 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA07530 for ; Wed, 15 Nov 2000 00:19:44 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAF8JiQ01695 for ; Wed, 15 Nov 2000 00:19:44 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with SMTP id AAA03370 for ; Wed, 15 Nov 2000 00:19:16 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Nov 2000 08:13:22 +0000 To: Toerless Eckert cc: hansen.chan@alcatel.com (HANSEN CHAN), ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network In-reply-to: Your message of "Tue, 14 Nov 2000 15:16:15 PST." <200011142316.PAA29744@cisco.com> Date: Wed, 15 Nov 2000 08:13:20 +0000 Message-ID: <6708.974276000@cs.ucl.ac.uk> From: Jon Crowcroft In message <200011142316.PAA29744@cisco.com>, Toerless Eckert typed: >>> I am trying to understand in a pure SSM network without any shared tree, >>> how would SAP operate? My understanding is that SAP is transmitting on a >>> shared tree. Does it mean that we always stuck with a PIM-SM shared >>> tree, even in a pure SSM network? >>I think you have a network without a shared tree and without SAP. You can >>of course use SSM to get SAP information, but the receivers need to know >>the address of the sources in the first place, which is a bit beyond the >>point of what SAP was meant for in the first place. SAP is nice to have >>in limited environments, but simply trying to broadcast directory information >>on a world-wide scale is not a scaling solution. Already today lots of >>SDP sessions are just made available via the web instead of SAP. Toerless either you have a well known ssm mcast addr per sap server or you have a well known web page - same difference - the scaling: if yo ucan have 10,000 sessions of video, you can sure happily have 10,000 session announcements..... search engines: are not standard. sure, they are a _piece_ of the picture. cheers jon From luby@digitalfountain.com Wed Nov 15 06:19:48 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21941 for ; Wed, 15 Nov 2000 06:19:47 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id BAA15799 for ; Wed, 15 Nov 2000 01:52:25 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAF9qLG25661 for ; Wed, 15 Nov 2000 01:52:21 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id BAA09491 for ; Wed, 15 Nov 2000 01:52:18 -0800 (PST) Received: from petersburg (adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id BAA21926; Wed, 15 Nov 2000 01:12:39 -0800 X-Authentication-Warning: mail.webfountain.com: Host adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195] claimed to be petersburg Reply-To: From: "Michael Luby" To: "zaid" , , "Toerless Eckert" , "Ross Finlayson" , "Al Adler" Cc: "HANSEN CHAN" , Subject: RE: Use of SAP in a PIM SSM Network Date: Wed, 15 Nov 2000 01:17:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <002601c04ec9$6f2591a0$4eac1218@zaid.loudoun.mci.net> Content-Transfer-Encoding: 7bit How does what help the end user? Having web pages? It is clear that this is the way everybody uses web pages today, so are you asking how does the Internet help end users? I really don't understand this question... I'm wondering about the preferences of end users. What makes anyone believe that they will want yet another service? What rationale is there that end user will want anything else other than what they have today on the Internet, i.e., to to a web page, see a list of content and streams offered by that provider, and click on the link that corresponds to the service that they want. Is anyone seriously suggesting that we need yet another form of a browser (that would be fine, but it will take a long time for any substantial set of users to accept it, and in the meantime it behooves the deployment of SSM to use standard web pages for quick deployment). What is the rationale and business decision behind offering SSM through a different interface other than a standard browser? What is wrong with the way users select different services from any provider from a webpage? As I said before, it may make perfect sense for someone to put up a webpage that offers content for a variety of types of content and streams from a variety of content providers, and this may be even targeted to just SSM streaming content. But, what is special about SSM from the user perspective that makes it compelling enough to offer yet another way to access this content (which will take a long time to accept)?. If you really want SSM to catch on as an Internet (with a capital I) service, it seems the best way to do this is to change as little as possible from the end use experience when this is rolled out, which means you provide access to such content using the standard approach, through web pages. One of the problems with the standard model of multicast is that it was too complex to deploy and operate by most ISPs, and too fragile. Each extra component on top of what is already offered in the Internet makes it more fragile and less acceptable. Whatever can be done to minimize the changes that need to be made to roll out SSM, either in the underlying infrastructure or in the end user experience, will greatly increase the chances that it becomes widely used. Again, my two cents ... flame out ... and let others put there two cents in. Mike Luby -----Original Message----- From: zaid [mailto:zalbanna@mci.net] Sent: Tuesday, November 14, 2000 10:01 PM To: Mike Luby; tme@21rst-century.com; Toerless Eckert; Ross Finlayson; Al Adler Cc: HANSEN CHAN; ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network How does this help the end user ? It seems that having a mechanism similar in functionality to SAP would be preferred by users. Using the direct TV model, a user may not want to access the provider's channel to view the list of streams available from that provider. By having a directory service, users will have one place to access to choose any content from any provider. Scalability will be one of the issues to resolve, ultimately the flexibility of this model will likely make it more desirable and usable. Thanks, Zaid -----Original Message----- From: Mike Luby To: tme@21rst-century.com ; Toerless Eckert ; Ross Finlayson ; Al Adler Cc: HANSEN CHAN ; ssm-interest@external.cisco.com Date: Tuesday, November 14, 2000 11:36 PM Subject: RE: Use of SAP in a PIM SSM Network I think there are different kinds of services that can be offered, and that is the difference in the discussion below. I happen to agree with Toerless that webpage access is the more natural way that SSM groups will be accessed. Today, there are many many more than 50,000 pieces of content and streams available on the web from different content providers, and there is absolutely no attempt to make available a centralized listing of all those piece of content in one place on one webpage: each content provider makes their content available on their webpages through hyperlinks, and the organization and presentation of that content is designed by them according to their needs. For example, Yahoo has many many pieces of content and streams available on its extensive website, and each one is accessed by the click of a hyperlink on a given webpage. There is absolutely no attempt to have a global organization of all the content and streams available on the Internet. Thus, I'm wondering what is so special about SSM, and why it won't roll into the same access model as all other content and streams out there? I suspect that if something different is attempted to organize SSM content and streams that was different than the rest of the Internet, then it will have a very limited use on the general Internet. This is the beauty of SSM: it really fits into current practices for making content and streams available on the Internet. Each content provider can independently source their own SSM streams just like they put content up on their webpages today available through http servers, and they don't have to worry about the old style of having a global listing service of all multicast groups in the world (which I suspect was there more because of the problems with having multicast group address clashes, which is not a problem for SSM), they just list their SSM content and streams as they are today on their webpages. The advantage of course is the massive scalability that SSM offers (of course, this is assuming it is deployed across the Internet as we all hope). The advantage of listing SSM content and streams on webpages is that it is what is done today for other content and this way nobody has to change their current practices. Of course, this is not to say that a global listing service would not be useful, but I'm not sure I see why this is anymore useful than a service that is a global listing service for all content and streams on the Internet, i.e., what is special about SSM streams versus other streams other than the massive scalability of SSM? My two cents, Mike -----Original Message----- From: Marshall Eubanks [mailto:tme@21rst-century.com] Sent: Tuesday, November 14, 2000 6:43 PM To: Toerless Eckert; Ross Finlayson; Al Adler Cc: HANSEN CHAN; ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network Toerless Eckert wrote: > > > I am trying to understand in a pure SSM network without any shared tree, > > how would SAP operate? My understanding is that SAP is transmitting on a > > shared tree. Does it mean that we always stuck with a PIM-SM shared > > tree, even in a pure SSM network? > > I think you have a network without a shared tree and without SAP. You can > of course use SSM to get SAP information, but the receivers need to know > the address of the sources in the first place, which is a bit beyond the > point of what SAP was meant for in the first place. SAP is nice to have > in limited environments, but simply trying to broadcast directory information > on a world-wide scale is not a scaling solution. Already today lots of > SDP sessions are just made available via the web instead of SAP. > > -- Toerless I am not sure that I agree with this. We would certainly be interested in hosting a directory service using SSM, and I suspect others would as well. I would, in fact, claim that in some ways a multicast directory service scales better than web pages FOR AGGREGATED INFORMATION. Suppose that one fine day there are 50,000 SSM groups in permanent operation . Clearly, a web page covering ALL of these groups would basically be a search engine - just a list would not be useful. If each group was announced by a sap type packet with a size (say) of 200 bytes, to go through the entire list would require 10 megabytes. Even if 8 kilobits/sec were allocated to a multicast directory service, it would still take > 3 hours to go through all of these announcements. If, however, the groups were divided into 100 classes, each with ~500 members, and each class getting its own SSM group for directory announcements, all the sessions in a class could be discovered in only 100 seconds, about the time it takes the program announcements on Channel 1 of my cable TV service to cycle through. I think that such a service would be useful; therefore I think that, while SAP may die, multicast session announcements will live on. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From ballardie@ngn-ltd.co.uk Wed Nov 15 07:03:10 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12468 for ; Wed, 15 Nov 2000 07:03:10 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id CAA00807 for ; Wed, 15 Nov 2000 02:30:02 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAFAU6p15410 for ; Wed, 15 Nov 2000 02:30:07 -0800 (PST) Received: from typhoon.mail.pipex.net (typhoon.mail.pipex.net [158.43.128.27]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with SMTP id CAA18803 for ; Wed, 15 Nov 2000 02:29:52 -0800 (PST) Received: (qmail 28045 invoked from network); 15 Nov 2000 10:19:53 -0000 Received: from userej79.uk.uudial.com (HELO vaionote) (62.188.13.90) by smtp-2.dial.pipex.com with SMTP; 15 Nov 2000 10:19:53 -0000 Message-ID: <00c701c04ee9$2c99d740$4f1abc3e@vaionote> Reply-To: "Tony Ballardie" From: "Tony Ballardie" To: "Toerless Eckert" , "Jon Crowcroft" Cc: "HANSEN CHAN" , References: <6708.974276000@cs.ucl.ac.uk> Subject: Re: Use of SAP in a PIM SSM Network Date: Wed, 15 Nov 2000 09:41:44 -0000 Organization: Next Generation Networking Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit > either you have a well known ssm mcast addr per sap server or you have > a well known web page - same difference - how about www.mcast.net ? Tony From J.Crowcroft@cs.ucl.ac.uk Wed Nov 15 07:10:18 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16292 for ; Wed, 15 Nov 2000 07:10:18 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id CAA07200 for ; Wed, 15 Nov 2000 02:57:37 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAFAvMp11105 for ; Wed, 15 Nov 2000 02:57:32 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with SMTP id CAA25470 for ; Wed, 15 Nov 2000 02:57:13 -0800 (PST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Nov 2000 10:50:37 +0000 To: Dirk Ooms cc: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network In-reply-to: Your message of "Wed, 15 Nov 2000 11:31:20 +0100." <3A1265F8.2276000A@alcatel.be> Date: Wed, 15 Nov 2000 10:50:37 +0000 Message-ID: <3451.974285437@cs.ucl.ac.uk> From: Jon Crowcroft ha ha ha finally people realize ssm entails _exactly_ as many problems as simple multicast in terms of 1/ deploying it in routers 2/ changing all the applications to use igmpv3 3/ chaing host OS to use igmpv3 4/ changing session management/annoucement mechanisms :-) (no i dont want to revisit SM - ssm is just fine, and ipv6 with some simple kinks will do many-source multicast just fine too) so no, we dont have resources to do this, but we are happy to roll in SSM/igmpv3 changes to the mbone apps if people contrib. them (spritn have kindly offered to do some apps) - sdr is a non trivial one in that it needs completely re-writing which is outside the scope of a university research department's normal activities.... In message <3A1265F8.2276000A@alcatel.be>, Dirk Ooms typed: >> >> >>Jon Crowcroft wrote: >>> >>> In message <200011142316.PAA29744@cisco.com>, Toerless Eckert typed: >>> >>> >>> I am trying to understand in a pure SSM network without any shared tree, >>> >>> how would SAP operate? My understanding is that SAP is transmitting on a >>> >>> shared tree. Does it mean that we always stuck with a PIM-SM shared >>> >>> tree, even in a pure SSM network? >>> >>> >>I think you have a network without a shared tree and without SAP. You can >>> >>of course use SSM to get SAP information, but the receivers need to know >>> >>the address of the sources in the first place, which is a bit beyond the >>> >>point of what SAP was meant for in the first place. SAP is nice to have >>> >>in limited environments, but simply trying to broadcast directory information >>> >>on a world-wide scale is not a scaling solution. Already today lots of >>> >>SDP sessions are just made available via the web instead of SAP. >>> >>> Toerless >>> >>> either you have a well known ssm mcast addr per sap server >> >>but the 'sap listener' application requires some changes, it has to join >>a specific sap server (which again needs to be listed on a webpage?). >>anyone working on sdr for ssm-only networks? >> >>dirk cheers jon From Dirk.Ooms@alcatel.be Wed Nov 15 07:10:26 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16372 for ; Wed, 15 Nov 2000 07:10:26 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id CAA05965 for ; Wed, 15 Nov 2000 02:53:33 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAFArgU21101 for ; Wed, 15 Nov 2000 02:53:42 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id CAA06457 for ; Wed, 15 Nov 2000 02:53:26 -0800 (PST) Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id eAFAX1i05981; Wed, 15 Nov 2000 11:33:01 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256998.0039EB5F; Wed, 15 Nov 2000 11:32:36 +0100 Message-ID: <3A1265F8.2276000A@alcatel.be> Date: Wed, 15 Nov 2000 11:31:20 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jon Crowcroft CC: Toerless Eckert , HANSEN CHAN , ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network References: <6708.974276000@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon Crowcroft wrote: > > In message <200011142316.PAA29744@cisco.com>, Toerless Eckert typed: > > >>> I am trying to understand in a pure SSM network without any shared tree, > >>> how would SAP operate? My understanding is that SAP is transmitting on a > >>> shared tree. Does it mean that we always stuck with a PIM-SM shared > >>> tree, even in a pure SSM network? > > >>I think you have a network without a shared tree and without SAP. You can > >>of course use SSM to get SAP information, but the receivers need to know > >>the address of the sources in the first place, which is a bit beyond the > >>point of what SAP was meant for in the first place. SAP is nice to have > >>in limited environments, but simply trying to broadcast directory information > >>on a world-wide scale is not a scaling solution. Already today lots of > >>SDP sessions are just made available via the web instead of SAP. > > Toerless > > either you have a well known ssm mcast addr per sap server but the 'sap listener' application requires some changes, it has to join a specific sap server (which again needs to be listed on a webpage?). anyone working on sdr for ssm-only networks? dirk From hansen.chan@alcatel.com Wed Nov 15 09:10:25 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07095 for ; Wed, 15 Nov 2000 09:10:25 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA18222 for ; Wed, 15 Nov 2000 04:52:01 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAFCq1J22646 for ; Wed, 15 Nov 2000 04:52:01 -0800 (PST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id EAA24176 for ; Wed, 15 Nov 2000 04:51:57 -0800 (PST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id HAA18339 for ; Wed, 15 Nov 2000 07:27:01 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA05rpMe; Wed Nov 15 07:26:57 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ssm-interest@external.cisco.com; Wed, 15 Nov 2000 07:33:09 -0500 Received: from alcatel.com ([138.120.49.69]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA2A4E; Wed, 15 Nov 2000 07:33:08 -0500 Message-Id: <3A128249.606E4E44@alcatel.com> Date: Wed, 15 Nov 2000 07:32:10 -0500 From: "HANSEN CHAN" X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Toerless Eckert CC: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network References: <200011142316.PAA29744@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To have SDP sessions available via the web. Is it the same as going to a webcast site (e.g. Yahoo Broadcast and Lycos TV) and click on the program link? How does my PC learn the multicast group address by clicking on the link? Thanks, Hansen Toerless Eckert wrote: > > I am trying to understand in a pure SSM network without any shared tree, > > how would SAP operate? My understanding is that SAP is transmitting on a > > shared tree. Does it mean that we always stuck with a PIM-SM shared > > tree, even in a pure SSM network? > > I think you have a network without a shared tree and without SAP. You can > of course use SSM to get SAP information, but the receivers need to know > the address of the sources in the first place, which is a bit beyond the > point of what SAP was meant for in the first place. SAP is nice to have > in limited environments, but simply trying to broadcast directory information > on a world-wide scale is not a scaling solution. Already today lots of > SDP sessions are just made available via the web instead of SAP. > > -- Toerless From grogier@greatplains.net Wed Nov 15 10:23:42 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08953 for ; Wed, 15 Nov 2000 10:23:41 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA01300 for ; Wed, 15 Nov 2000 06:03:56 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAFE3qD28136 for ; Wed, 15 Nov 2000 06:03:52 -0800 (PST) Received: from nic-ks.greatplains.net (nic-ks.greatplains.net [164.113.239.2]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id GAA17688 for ; Wed, 15 Nov 2000 06:03:48 -0800 (PST) Received: from localhost (grogier@localhost) by nic-ks.greatplains.net (8.9.3/8.9.3) with ESMTP id HAA20967 for ; Wed, 15 Nov 2000 07:57:36 -0600 (CST) Date: Wed, 15 Nov 2000 07:57:35 -0600 (CST) From: Gordon Rogier To: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network In-Reply-To: <3451.974285437@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Nov 2000, Jon Crowcroft wrote: > ha ha ha > > finally people realize > > ssm entails _exactly_ as many problems as simple multicast in terms of > 1/ deploying it in routers > 2/ changing all the applications to use igmpv3 > 3/ chaing host OS to use igmpv3 > 4/ changing session management/annoucement mechanisms granted i have missed the working group discussions, but i think you would need to add to this layer2 switching issues. i have not seen anyone even start to touch this issue. will igmp snoopers be upgradable, will propietary methods (eg. cisco's igmp/cgmp) be upgradable to support the SSM methods. the content we are discussing here will be high enough bit rate that campus level traffic management will be a critical factor. --*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-- Gordon Rogier grogier@greatplains.net Network Engineer 785-864-0381wk 785-550-4468 cell Great Plains Network 785-864-9330 FAX From tme@21rst-century.com Wed Nov 15 11:30:04 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04359 for ; Wed, 15 Nov 2000 11:30:03 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA08473 for ; Wed, 15 Nov 2000 07:13:18 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAFFDQc18976 for ; Wed, 15 Nov 2000 07:13:26 -0800 (PST) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id HAA23692 for ; Wed, 15 Nov 2000 07:13:15 -0800 (PST) Received: from 21rst-century.com by dfw7sosrv11.alter.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjpku19909; Wed, 15 Nov 2000 15:11:53 GMT Message-ID: <3A12A722.842F859E@21rst-century.com> Date: Wed, 15 Nov 2000 10:09:22 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: luby@digitalfountain.com CC: zaid , Toerless Eckert , Ross Finlayson , Al Adler , HANSEN CHAN , ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Mike; Toerless presented an argument that session announcements wouldn't scale. I presented a counter argument, a scheme which does scale, which no-one has refuted. Michael Luby wrote: > How does what help the end user? Having web pages? It is clear that this > is the way everybody uses web pages today, so are you asking how does the > Internet help end users? I really don't understand this question... > > I'm wondering about the preferences of end users. What makes anyone believe > that they will want yet another service? What rationale is there that end > user will want anything else other than what they have today on the > Internet, i.e., to to a web page, see a list of content and streams offered > by that provider, and click on the link that corresponds to the service that > they want. Is anyone seriously suggesting that we need yet another form of > a browser (that would be fine, but it will take a long time for any > substantial set of users to accept it, and in the meantime it behooves the > deployment of SSM to use standard web pages for quick deployment). What is > the rationale and business decision behind offering SSM through a different > interface other than a standard browser? I think what you are forgetting is that in the near future people will not necessarily access the internet (and particularly internet broadcasts) through a box with a web server. I doubt that people with a handheld 3G wireless IP "SSM-Man" audio player on the beach are going to want to to look at web sites to select content. A scrollable list of content by genre (such as what the Kerbango box has, but via multicast) would make more sense. As for Internet TV : I have cable television at home. It broadcasts a rotating schedule of what's on the air on channels 1 and 2 - a session announcement, of a sort. I use it all the time. So do lots of other people, including many who have never used any sort of browser. SSM session announcements will have similar utility, and I have no doubt that they will be used. Marshall > What is wrong with the way users > select different services from any provider from a webpage? As I said > before, it may make perfect sense for someone to put up a webpage that > offers content for a variety of types of content and streams from a variety > of content providers, and this may be even targeted to just SSM streaming > content. But, what is special about SSM from the user perspective that > makes it compelling enough to offer yet another way to access this content > (which will take a long time to accept)?. If you really want SSM to catch > on as an Internet (with a capital I) service, it seems the best way to do > this is to change as little as possible from the end use experience when > this is rolled out, which means you provide access to such content using the > standard approach, through web pages. > > One of the problems with the standard model of multicast is that it was too > complex to deploy and operate by most ISPs, and too fragile. Each extra > component on top of what is already offered in the Internet makes it more > fragile and less acceptable. Whatever can be done to minimize the changes > that need to be made to roll out SSM, either in the underlying > infrastructure or in the end user experience, will greatly increase the > chances that it becomes widely used. > > Again, my two cents ... flame out ... and let others put there two cents in. > > Mike Luby > > -----Original Message----- > From: zaid [mailto:zalbanna@mci.net] > Sent: Tuesday, November 14, 2000 10:01 PM > To: Mike Luby; tme@21rst-century.com; Toerless Eckert; Ross Finlayson; > Al Adler > Cc: HANSEN CHAN; ssm-interest@external.cisco.com > Subject: Re: Use of SAP in a PIM SSM Network > > How does this help the end user ? It seems that having a mechanism > similar > in functionality to SAP would be preferred by users. Using the direct > TV model, > a user may not want to access the provider's channel to view the list > of streams > available from that provider. By having a directory service, users > will have one > place to access to choose any content from any provider. Scalability > will be one > of the issues to resolve, ultimately the flexibility of this model > will likely make > it more desirable and usable. > > Thanks, > Zaid > > -----Original Message----- > From: Mike Luby > To: tme@21rst-century.com ; Toerless Eckert > ; Ross Finlayson ; Al Adler > > Cc: HANSEN CHAN ; > ssm-interest@external.cisco.com > Date: Tuesday, November 14, 2000 11:36 PM > Subject: RE: Use of SAP in a PIM SSM Network > > I think there are different kinds of services that can be offered, and > that > is the difference in the discussion below. I happen to agree with > Toerless > that webpage access is the more natural way that SSM groups will be > accessed. Today, there are many many more than 50,000 pieces of > content and > streams available on the web from different content providers, and > there is > absolutely no attempt to make available a centralized listing of all > those > piece of content in one place on one webpage: each content provider > makes > their content available on their webpages through hyperlinks, and the > organization and presentation of that content is designed by them > according > to their needs. For example, Yahoo has many many pieces of content > and > streams available on its extensive website, and each one is accessed > by the > click of a hyperlink on a given webpage. There is absolutely no > attempt to > have a global organization of all the content and streams available on > the > Internet. Thus, I'm wondering what is so special about SSM, and why > it > won't roll into the same access model as all other content and streams > out > there? I suspect that if something different is attempted to organize > SSM > content and streams that was different than the rest of the Internet, > then > it will have a very limited use on the general Internet. This is the > beauty > of SSM: it really fits into current practices for making content and > streams > available on the Internet. Each content provider can independently > source > their own SSM streams just like they put content up on their webpages > today > available through http servers, and they don't have to worry about the > old > style of having a global listing service of all multicast groups in > the > world (which I suspect was there more because of the problems with > having > multicast group address clashes, which is not a problem for SSM), they > just > list their SSM content and streams as they are today on their > webpages. The > advantage of course is the massive scalability that SSM offers (of > course, > this is assuming it is deployed across the Internet as we all hope). > The > advantage of listing SSM content and streams on webpages is that it is > what > is done today for other content and this way nobody has to change > their > current practices. Of course, this is not to say that a global > listing > service would not be useful, but I'm not sure I see why this is > anymore > useful than a service that is a global listing service for all content > and > streams on the Internet, i.e., what is special about SSM streams > versus > other streams other than the massive scalability of SSM? > > My two cents, > Mike > T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From Supratik@sprintlabs.com Wed Nov 15 13:57:34 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28871 for ; Wed, 15 Nov 2000 13:57:33 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA20271 for ; Wed, 15 Nov 2000 09:48:15 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAFHmEk06522 for ; Wed, 15 Nov 2000 09:48:14 -0800 (PST) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id JAA08873 for ; Wed, 15 Nov 2000 09:47:47 -0800 (PST) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78) id ; Wed, 15 Nov 2000 09:44:27 -0800 Received: from sprintlabs.com (ip199-2-53-56.sprintlabs.com [199.2.53.56]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id W408XX71; Wed, 15 Nov 2000 09:44:20 -0800 From: Supratik Bhattacharyya To: HANSEN CHAN Cc: ssm-interest@external.cisco.com Message-ID: <3A12CB06.37123863@sprintlabs.com> Date: Wed, 15 Nov 2000 09:42:30 -0800 X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Use of SAP in a PIM SSM Network References: <200011142316.PAA29744@cisco.com> <3A128249.606E4E44@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As an example of a web-based interface for SSM-cast, you can look at the UofO SSM Trial page : http://videolab.uoregon.edu/projects.html Note that this is currently set up to use URD on the receiving host's DR, but this is not a fundamental restriction, and can be easily changed to support a v3 host running v3-enabled apps (with a v3 DR of course)... Cheers, --Supratik HANSEN CHAN wrote: > To have SDP sessions available via the web. Is it the same as going to a webcast > site (e.g. Yahoo Broadcast and Lycos TV) and click on the program link? How does > my PC learn the multicast group address by clicking on the link? > > Thanks, > Hansen > > Toerless Eckert wrote: > > > > I am trying to understand in a pure SSM network without any shared tree, > > > how would SAP operate? My understanding is that SAP is transmitting on a > > > shared tree. Does it mean that we always stuck with a PIM-SM shared > > > tree, even in a pure SSM network? > > > > I think you have a network without a shared tree and without SAP. You can > > of course use SSM to get SAP information, but the receivers need to know > > the address of the sources in the first place, which is a bit beyond the > > point of what SAP was meant for in the first place. SAP is nice to have > > in limited environments, but simply trying to broadcast directory information > > on a world-wide scale is not a scaling solution. Already today lots of > > SDP sessions are just made available via the web instead of SAP. > > > > -- Toerless From lamaster@nren.nasa.gov Wed Nov 15 14:54:32 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25473 for ; Wed, 15 Nov 2000 14:54:29 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA29910 for ; Wed, 15 Nov 2000 10:32:22 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAFIW1d28303 for ; Wed, 15 Nov 2000 10:32:07 -0800 (PST) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.132.150]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id KAA29340 for ; Wed, 15 Nov 2000 10:31:33 -0800 (PST) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id KAA16605 for ; Wed, 15 Nov 2000 10:13:01 -0800 (PST) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Wed, 15 Nov 2000 10:13:01 -0800 (PST) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network In-Reply-To: <3451.974285437@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Nov 2000, Jon Crowcroft wrote: > ha ha ha > > finally people realize > > ssm entails _exactly_ as many problems as simple multicast in terms of > 1/ deploying it in routers > 2/ changing all the applications to use igmpv3 > 3/ chaing host OS to use igmpv3 > 4/ changing session management/annoucement mechanisms > > :-) I don't know how many people agree with me, but, although SSM obviously has huge benefits for broadcast-type applications, the benefits are not so obvious to me for all multicast applications. So, personally, although I fully support the SSM deployment, I don't want to abandon completely the capability for global shared trees, which I think will continue to be most appropriate for large numbers of low datarate sources, such as distributed simulations, as well as multicast-enabled games that were "threatened" a few years ago. At the moment, the assignment of the SSM address space and a wave of deployments over the next year will give us a usable SSM infrastructure - that is, addressing item 1/ above - although, of course, /2, 3/, and 4/ will still be there. /4 is solvable, though not solved yet. 2/ and 3/ are what I see as the main problem, and even after solutions are available, still won't be *automatic* in the case where that matters most -- "personal systems" (e.g. the gaggle of PC-based systems running legacy Windows 95/98/me). SSM does seem to have finally given multicast the appeal to commercial content providers that was not there before, though, so that demand-pull from users may finally start to have an effect. > so no, we dont have resources to do this, but we are happy to roll in > SSM/igmpv3 changes to the mbone apps if people contrib. them (spritn > have kindly offered to do some apps) - sdr is a non trivial one in > that it needs completely re-writing which is outside the scope of a > university research department's normal activities.... If somebody is going to rewrite sdr to integrate SSM, I hope it is done so that it still handles traditional SAP announcements transparently in parallel, both on the receiving and announcement side. SAP will continue to be used for some time at least. Questions/comments/refutations welcome. -- Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From eckert@cisco.com Wed Nov 15 16:30:08 2000 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04377 for ; Wed, 15 Nov 2000 16:30:08 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by ams-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id VAA04602 for ; Wed, 15 Nov 2000 21:17:11 +0100 (MET) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA01389; Wed, 15 Nov 2000 12:11:04 -0800 (PST) From: Toerless Eckert Message-Id: <200011152011.MAA01389@cisco.com> Subject: Re: Use of SAP in a PIM SSM Network To: lamaster@nren.nasa.gov (Hugh LaMaster) Date: Wed, 15 Nov 2000 12:11:04 -0800 (PST) Cc: ssm-interest@external.cisco.com In-Reply-To: from "Hugh LaMaster" at Nov 15, 2000 10:13:01 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I don't want to abandon completely the capability for global > shared trees, which I think will continue to be most appropriate > for large numbers of low datarate sources, such as distributed > simulations, as well as multicast-enabled games that were > "threatened" a few years ago. I don't know. I think that access-control, management and scalability requirements will make it more and more obvious, that handling source-discovery at the network layer will not fly in the Internet. Especially not with the unsolved address allocation problem for application sessions. I wonder why nobody thinks of session management with a standardizable solution for a session/ application layer RP function to handle session. An application programmer really does not care if "joining to a session as a source and/or receiver" is done with IP Multicast alone, or if there's a session library that will do this: Contacting some RP-server, signal to the RP if you are a source, maybe also if you are active or also a receiver, and then have the library also join towards the active currently active sources for this session - as indicated by the RP. Conferencing solutions using unicast are doing things along this line since the beginning of time, only that each application has it's own solution for it, which takes away the ability to really set up session management facilities in an application independent way. Maybe i just don't know the solutions space well enough there, but with something like this i really don't see a need for "global source-discovery in an ad-hoc managed address space", which is what we have today. Cheers From lenny@juniper.net Wed Nov 15 21:08:31 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28179 for ; Wed, 15 Nov 2000 21:08:30 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id QAA10985 for ; Wed, 15 Nov 2000 16:59:30 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAG0xS207948 for ; Wed, 15 Nov 2000 16:59:29 -0800 (PST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id QAA08399 for ; Wed, 15 Nov 2000 16:59:19 -0800 (PST) Received: from maroon.jnpr.net (maroon.jnpr.net [172.24.244.36]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07688; Wed, 15 Nov 2000 16:53:07 -0800 (PST) Received: from localhost (lenny@localhost) by maroon.jnpr.net (8.9.3/8.9.3) with ESMTP id QAA76043; Wed, 15 Nov 2000 16:53:07 -0800 (PST) (envelope-from lenny@juniper.net) X-Authentication-Warning: maroon.jnpr.net: lenny owned process doing -bs Date: Wed, 15 Nov 2000 16:53:07 -0800 (PST) From: Leonard Giuliano X-Sender: lenny@maroon.jnpr.net To: Toerless Eckert cc: Hugh LaMaster , ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network In-Reply-To: <200011152011.MAA01389@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I suppose one way to make SAP work in SSM is to modify the protocol to have the directly connected routers to active sources use unicast to register with core "rendezvous points". Then each of these rendezvous points will talk to each other with another protocol to tell each other about the active sources that they are each aware of. Wait, this sounds familiar... SSM presents an interesing tradeoff where some functionality is reduced to meet a much more common model as well as radically simplifying network deployment. Being only able to join a single source is inherantly incompatible with something like SAP, but few commercial content providers would disagree that sdr doesn't represent the commercially viable future of multicast. SSM hinges upon the mass appeal of one-to-many apps like WMP, Real player and IP/TV, while eliminating the biggest hinderance to deployment: a PIM-SM/MSDP RP-based infrastructure is too complex. Maybe SSM is just a stepping stone to the full functionality that shared-tree infrastructures provide. But it will be a whole lot better than what we have now, where multicast is virtually nowhere to be found. From eckert@cisco.com Wed Nov 15 22:17:28 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16245 for ; Wed, 15 Nov 2000 22:17:28 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA20880 for ; Wed, 15 Nov 2000 18:17:20 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA11212; Wed, 15 Nov 2000 18:17:09 -0800 (PST) From: Toerless Eckert Message-Id: <200011160217.SAA11212@cisco.com> Subject: Re: Use of SAP in a PIM SSM Network To: lenny@juniper.net (Leonard Giuliano) Date: Wed, 15 Nov 2000 18:17:09 -0800 (PST) Cc: eckert@cisco.com (Toerless Eckert), lamaster@nren.nasa.gov (Hugh LaMaster), ssm-interest@external.cisco.com In-Reply-To: from "Leonard Giuliano" at Nov 15, 2000 04:53:07 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I suppose one way to make SAP work in SSM is to modify the protocol to > have the directly connected routers to active sources use unicast to > register with core "rendezvous points". Then each of these rendezvous > points will talk to each other with another protocol to tell each other > about the active sources that they are each aware of. Wait, this sounds > familiar... Selling the spanish inquisition to protestants! > SSM presents an interesing tradeoff where some functionality is reduced to > meet a much more common model as well as radically simplifying network > deployment. Being only able to join a single source is inherantly > incompatible with something like SAP, but few commercial content providers > would disagree that sdr doesn't represent the commercially viable future > of multicast. SSM hinges upon the mass appeal of one-to-many apps like > WMP, Real player and IP/TV, while eliminating the biggest hinderance to > deployment: a PIM-SM/MSDP RP-based infrastructure is too complex. > > Maybe SSM is just a stepping stone to the full functionality that > shared-tree infrastructures provide. But it will be a whole lot better > than what we have now, where multicast is virtually nowhere to be found. The whole point is that global source discovery in the network layer with a non-hierarchically managed address space has shown to be a non-scaling approach. There are things that sound cool in the first place and work to a point but have some limits. Just because we learnt this about the IP Multicast model after 10 years doesn't mean that the model is bad or that we should force to make it work somehow, if there are much more easy alternatives to get to the same results by just putting tasks into different layers. From finlayson@live.com Wed Nov 15 23:13:43 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00587 for ; Wed, 15 Nov 2000 23:13:42 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id TAA16794 for ; Wed, 15 Nov 2000 19:07:13 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAG33Tp22613 for ; Wed, 15 Nov 2000 19:03:29 -0800 (PST) Received: from ns.live.com (ns.live.com [208.184.148.162]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id TAA24456 for ; Wed, 15 Nov 2000 19:03:00 -0800 (PST) Received: from rsf-laptop.live.com (dhcp0.live.com [208.184.148.170]) by ns.live.com (8.9.3/8.9.3) with ESMTP id SAA16445; Wed, 15 Nov 2000 18:56:45 -0800 (PST) (envelope-from finlayson@live.com) Message-Id: <4.3.1.1.20001115180955.00b94e90@ns.live.com> X-Sender: rsf@ns.live.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 15 Nov 2000 18:53:40 -0800 To: tme@21rst-century.com From: Ross Finlayson Subject: Re: Use of SAP in a PIM SSM Network Cc: Toerless Eckert , Al Adler , HANSEN CHAN , ssm-interest@external.cisco.com In-Reply-To: <3A11F843.6B70A1A4@21rst-century.com> References: <200011142316.PAA29744@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I'm sure that most SSM sessions will end up getting advertised on web pages, and launched from web browsers. This is the technology that most people are familiar with, and it scales reasonably well for sessions that are long-lasting, and whose information doesn't change frequently (so that web caching can take effect, and so that users don't have to keep 'refreshing' the web page). (I just hope, though, that people standardize on using SDP to describe these sessions - either using data:// URLs embedded in web pages, or via links back to a web server. I'd hate to see a proliferation of viewer-specific hacks like we see now with Real or Windows Media sessions.) The main disadvantage of advertising SSM sessions on the web is that the announcements will be visible even to those who don't have SSM-connectivity. So be prepared for lots of people asking "Why can't I receive this stream after I've launched it from your web site?!" At the same time, though, I see no reason why *some* SSM sessions - especially those that are more ephemeral in nature - can't also be advertised within SDP directories, using single-source-SAP as the announcement protocol. This probably makes the most sense for advertising multiple sessions that come from the same source (or at least, from the same provider); the SDP directory that advertises these sessions can then come from the same source (or provider). However, I don't think there'll be much value in trying to have a single large global multicast session directory for announcing SSM sessions from independent providers - as we do now in the ISM world - because you either have to do this using ISM (which not all SSM receivers will have), or else use a SSM source (a single point of failure) with some separate unicast protocol needed for announcing session description data to that source. John Crowcroft wrote: >so no, we dont have resources to do this, but we are happy to roll in >SSM/igmpv3 changes to the mbone apps if people contrib. them (spritn >have kindly offered to do some apps) - sdr is a non trivial one in >that it needs completely re-writing which is outside the scope of a >university research department's normal activities.... Actually, modifying "sdr" to handle launching SSM sessions - including the ability to use arbitrary SSM SDP/SAP directories - should not be all that difficult, I think. The most recent "sdr" version already contains my patches to support launching of SDP "directory" sessions[*], so it already knows how to handle multiple, arbitrary SDP/SAP directories. All that's needed now is the ability to recognize the special SDP syntax for SSM sessions, and the ability to subscribe to a SSM SDP/SAP directories using an apropriate IGMPv3 API call. Needless to say, I'll be making such a change to "multikit" at some point :-) Ross. [*] "sdr" currently supports only an old format for SDP "directory" sessions, not the newer format described in From eckert@cisco.com Thu Nov 16 02:31:15 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00495 for ; Thu, 16 Nov 2000 02:31:15 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA08858 for ; Wed, 15 Nov 2000 12:49:20 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA02479; Wed, 15 Nov 2000 12:23:55 -0800 (PST) From: Toerless Eckert Message-Id: <200011152023.MAA02479@cisco.com> Subject: Re: Use of SAP in a PIM SSM Network To: tme@21rst-century.com Date: Wed, 15 Nov 2000 12:23:55 -0800 (PST) Cc: luby@digitalfountain.com, zalbanna@mci.net (zaid), eckert@cisco.com (Toerless Eckert), finlayson@live.com (Ross Finlayson), al@on-the-i.com (Al Adler), hansen.chan@alcatel.com (HANSEN CHAN), ssm-interest@external.cisco.com In-Reply-To: <3A12A722.842F859E@21rst-century.com> from "Marshall Eubanks" at Nov 15, 2000 10:09:22 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Toerless presented an argument that session announcements wouldn't > scale. I presented a counter argument, a scheme which does scale, which > no-one has refuted. Just because my email server was upgraded ;-) I hope that i just said that session announcements in the way it is currently handled in the Internet does not scale. Session announcements by themselves will scale, but by doing so, we implicitly need to introduce directory like selection mechanism that simultaneously can give us all the information to use SSM too. All the examples cited (cable-tv, wireless devices) show that the session information you may want to receive in a broadcast style are limited in quantity (certainly not "everything from the internet"). Also they typically will be managed by someone providing the access, like AT&T for the cable-tv or whoever gives you the wireless connectivity. You may not call it web anymore, but the more you get into ubiquitous devices, the more will you see that they all have some initial portal to services. In this space, yes, you may want to "broadcast" session information, and yes, you can easily use SSM, because you can source that broadcast from a well-known source address. Heck, why not use our beloved anycast mechanism ? The problem with broadcasting session information is that nobody in his sane mind (hopefully) should think that you would want to get a flat, undifferentiated broadcast of all the sessions in all the world, which is what you would get today with SAP. And once you are putting structure into this, then you say that you want to select which part you want to receive, and that already means that you have keys for selection, and those keys just need to map to the source addresses originating the broadcast selection, so that SSM can be used. Cheers Toerless From luby@digitalfountain.com Thu Nov 16 03:42:04 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03218 for ; Thu, 16 Nov 2000 03:42:03 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id XAA05978 for ; Wed, 15 Nov 2000 23:39:21 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAG7dGE05098 for ; Wed, 15 Nov 2000 23:39:16 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id XAA16752 for ; Wed, 15 Nov 2000 23:39:13 -0800 (PST) Received: from petersburg (adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id XAA17171; Wed, 15 Nov 2000 23:12:25 -0800 X-Authentication-Warning: mail.webfountain.com: Host adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195] claimed to be petersburg Reply-To: From: "Michael Luby" To: Cc: "zaid" , "Toerless Eckert" , "Ross Finlayson" , "Al Adler" , "HANSEN CHAN" , , "Michael Luby" Subject: RE: Use of SAP in a PIM SSM Network Date: Wed, 15 Nov 2000 23:17:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A12A722.842F859E@21rst-century.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Transfer-Encoding: 7bit Marshall, You make some good points about future devices coming into the picture that will not necessarily access the current webpages on the Internet, most likely because they are too rich to be displayed on initial versions of wireless devices. However, for the Internet, where I believe SSM has a future, I still believe that it makes most sense to access SSM content the same as any other content, via clicking on a link on a web page. This requires no changes to current practices of content providers, other than deploying SSM (which is a large hurdle, and that is the point, this is large enough of a hurdle that changing anything else and putting even more hurdles in the way of acceptance will make deployment of SSM all that much slower than it already is likely to be.) I do think that there will be as you say a whole new generation of devices as you point out that will need another way to access content other than going to a standard Internet webpage which is too rich, and one possible way to do this is some kind of push of a session directory to the device and then the end user clicks on the links that they want to access. Hmmm, this is beginning to sound just like the AOL service where all users have a common AOL homepage to start there searches from, but in this case the homepage would be specially desgined for display on the devices and would show what categories of content is available, and then the user clicks on the link to get to a particular category, and the a scollable list of available content within the category is shown which can be clicked on. The difference is that the webpages may be specially designed to be small so that it can be viewed reasonable in a wireless device, for example. I guess I'm not really seeing the difference between a scrollable list of content by genre (= lists of links on different webpages, one for each genre), whether it be for cable T.V. or for the 3G wireless device. Aren't all of these just different forms of webpages that show what content is available, and it is just that some are more primitive, more succinct, or more compact than others? Isn't the directory service available on cable T.V. over time slowly evolving into something more like a webpage? Of course, it is fine if the webpage itself is sent out over an SSM group, nothing stops that from happening, just like any other piece of content may be delivered more efficiently using SSM if there is a lot of concurrent access to the content, like the homepage for the device and perhaps in your example all of the webpages for each genre that lists all of the content available within each genre (which may all be available using SSM). Mike -----Original Message----- From: Marshall Eubanks [mailto:tme@21rst-century.com] Sent: Wednesday, November 15, 2000 7:09 AM To: luby@digitalfountain.com Cc: zaid; Toerless Eckert; Ross Finlayson; Al Adler; HANSEN CHAN; ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network Dear Mike; Toerless presented an argument that session announcements wouldn't scale. I presented a counter argument, a scheme which does scale, which no-one has refuted. Michael Luby wrote: > How does what help the end user? Having web pages? It is clear that this > is the way everybody uses web pages today, so are you asking how does the > Internet help end users? I really don't understand this question... > > I'm wondering about the preferences of end users. What makes anyone believe > that they will want yet another service? What rationale is there that end > user will want anything else other than what they have today on the > Internet, i.e., to to a web page, see a list of content and streams offered > by that provider, and click on the link that corresponds to the service that > they want. Is anyone seriously suggesting that we need yet another form of > a browser (that would be fine, but it will take a long time for any > substantial set of users to accept it, and in the meantime it behooves the > deployment of SSM to use standard web pages for quick deployment). What is > the rationale and business decision behind offering SSM through a different > interface other than a standard browser? I think what you are forgetting is that in the near future people will not necessarily access the internet (and particularly internet broadcasts) through a box with a web server. I doubt that people with a handheld 3G wireless IP "SSM-Man" audio player on the beach are going to want to to look at web sites to select content. A scrollable list of content by genre (such as what the Kerbango box has, but via multicast) would make more sense. As for Internet TV : I have cable television at home. It broadcasts a rotating schedule of what's on the air on channels 1 and 2 - a session announcement, of a sort. I use it all the time. So do lots of other people, including many who have never used any sort of browser. SSM session announcements will have similar utility, and I have no doubt that they will be used. Marshall > What is wrong with the way users > select different services from any provider from a webpage? As I said > before, it may make perfect sense for someone to put up a webpage that > offers content for a variety of types of content and streams from a variety > of content providers, and this may be even targeted to just SSM streaming > content. But, what is special about SSM from the user perspective that > makes it compelling enough to offer yet another way to access this content > (which will take a long time to accept)?. If you really want SSM to catch > on as an Internet (with a capital I) service, it seems the best way to do > this is to change as little as possible from the end use experience when > this is rolled out, which means you provide access to such content using the > standard approach, through web pages. > > One of the problems with the standard model of multicast is that it was too > complex to deploy and operate by most ISPs, and too fragile. Each extra > component on top of what is already offered in the Internet makes it more > fragile and less acceptable. Whatever can be done to minimize the changes > that need to be made to roll out SSM, either in the underlying > infrastructure or in the end user experience, will greatly increase the > chances that it becomes widely used. > > Again, my two cents ... flame out ... and let others put there two cents in. > > Mike Luby > > -----Original Message----- > From: zaid [mailto:zalbanna@mci.net] > Sent: Tuesday, November 14, 2000 10:01 PM > To: Mike Luby; tme@21rst-century.com; Toerless Eckert; Ross Finlayson; > Al Adler > Cc: HANSEN CHAN; ssm-interest@external.cisco.com > Subject: Re: Use of SAP in a PIM SSM Network > > How does this help the end user ? It seems that having a mechanism > similar > in functionality to SAP would be preferred by users. Using the direct > TV model, > a user may not want to access the provider's channel to view the list > of streams > available from that provider. By having a directory service, users > will have one > place to access to choose any content from any provider. Scalability > will be one > of the issues to resolve, ultimately the flexibility of this model > will likely make > it more desirable and usable. > > Thanks, > Zaid > > -----Original Message----- > From: Mike Luby > To: tme@21rst-century.com ; Toerless Eckert > ; Ross Finlayson ; Al Adler > > Cc: HANSEN CHAN ; > ssm-interest@external.cisco.com > Date: Tuesday, November 14, 2000 11:36 PM > Subject: RE: Use of SAP in a PIM SSM Network > > I think there are different kinds of services that can be offered, and > that > is the difference in the discussion below. I happen to agree with > Toerless > that webpage access is the more natural way that SSM groups will be > accessed. Today, there are many many more than 50,000 pieces of > content and > streams available on the web from different content providers, and > there is > absolutely no attempt to make available a centralized listing of all > those > piece of content in one place on one webpage: each content provider > makes > their content available on their webpages through hyperlinks, and the > organization and presentation of that content is designed by them > according > to their needs. For example, Yahoo has many many pieces of content > and > streams available on its extensive website, and each one is accessed > by the > click of a hyperlink on a given webpage. There is absolutely no > attempt to > have a global organization of all the content and streams available on > the > Internet. Thus, I'm wondering what is so special about SSM, and why > it > won't roll into the same access model as all other content and streams > out > there? I suspect that if something different is attempted to organize > SSM > content and streams that was different than the rest of the Internet, > then > it will have a very limited use on the general Internet. This is the > beauty > of SSM: it really fits into current practices for making content and > streams > available on the Internet. Each content provider can independently > source > their own SSM streams just like they put content up on their webpages > today > available through http servers, and they don't have to worry about the > old > style of having a global listing service of all multicast groups in > the > world (which I suspect was there more because of the problems with > having > multicast group address clashes, which is not a problem for SSM), they > just > list their SSM content and streams as they are today on their > webpages. The > advantage of course is the massive scalability that SSM offers (of > course, > this is assuming it is deployed across the Internet as we all hope). > The > advantage of listing SSM content and streams on webpages is that it is > what > is done today for other content and this way nobody has to change > their > current practices. Of course, this is not to say that a global > listing > service would not be useful, but I'm not sure I see why this is > anymore > useful than a service that is a global listing service for all content > and > streams on the Internet, i.e., what is special about SSM streams > versus > other streams other than the massive scalability of SSM? > > My two cents, > Mike > T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From J.Crowcroft@cs.ucl.ac.uk Thu Nov 16 04:49:48 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02582 for ; Thu, 16 Nov 2000 04:49:47 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA11697 for ; Thu, 16 Nov 2000 00:34:27 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAG8YRb20814 for ; Thu, 16 Nov 2000 00:34:27 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with SMTP id AAA03380 for ; Thu, 16 Nov 2000 00:34:24 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Nov 2000 08:26:04 +0000 To: Toerless Eckert cc: lenny@juniper.net (Leonard Giuliano), lamaster@nren.nasa.gov (Hugh LaMaster), ssm-interest@external.cisco.com, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Use of SAP in a PIM SSM Network In-reply-to: Your message of "Wed, 15 Nov 2000 18:17:09 PST." <200011160217.SAA11212@cisco.com> Date: Thu, 16 Nov 2000 08:26:03 +0000 Message-ID: <16813.974363163@cs.ucl.ac.uk> From: Jon Crowcroft In message <200011160217.SAA11212@cisco.com>, Toerless Eckert typed: >>> Maybe SSM is just a stepping stone to the full functionality that >>> shared-tree infrastructures provide. But it will be a whole lot better >>> than what we have now, where multicast is virtually nowhere to be found. >>The whole point is that global source discovery in the network layer with >>a non-hierarchically managed address space has shown to be a non-scaling >>approach. There are things that sound cool in the first place and work not clear - the GLOP and ipv6 ways of allocating multicast introduce _some_ hierarchiy - in fact its relatively easy to impose all sorts if you have _enough_ address space..... >>to a point but have some limits. Just because we learnt this about the >>IP Multicast model after 10 years doesn't mean that the model is bad or >>that we should force to make it work somehow, if there are much more >>easy alternatives to get to the same results by just putting tasks into >>different layers. if yo uhave applications which genuijley have significant number of sources with dynamics, then the server solution does not scale - you have just pushed the management problem to that of 1/ locating one of a set of servers (how) 2/ making servers fault tolerant (anyone for anycast? :-) 3/ managing the application state in an unnatural way 4/ putting performance (delay and procerssign) limits on the scale of the application ok so you could have a hierarchy of redundant servers....,and what standard internet protocoos are you going to use to manage those? no, i think we need to retain the deering multicast model and just keep up the pressure on Large Router Vendors (this means you:-) to be smart about scaling the routers up to meet the users requirements rather than scaling the users expectations down to what you want to do:-) cheers jon From lamaster@nren.nasa.gov Thu Nov 16 13:43:41 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24175 for ; Thu, 16 Nov 2000 13:43:41 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA19054 for ; Thu, 16 Nov 2000 09:29:36 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAGHTZL05794 for ; Thu, 16 Nov 2000 09:29:35 -0800 (PST) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.132.150]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id JAA26630 for ; Thu, 16 Nov 2000 09:29:06 -0800 (PST) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id JAA25523 for ; Thu, 16 Nov 2000 09:10:38 -0800 (PST) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Thu, 16 Nov 2000 09:10:38 -0800 (PST) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Nov 2000, Leonard Giuliano wrote: > SSM presents an interesing tradeoff where some functionality is reduced to > meet a much more common model as well as radically simplifying network > deployment. Being only able to join a single source is inherantly > incompatible with something like SAP, but few commercial content providers > would disagree that sdr doesn't represent the commercially viable future > of multicast. SSM hinges upon the mass appeal of one-to-many apps like > WMP, Real player and IP/TV, while eliminating the biggest hinderance to > deployment: a PIM-SM/MSDP RP-based infrastructure is too complex. ^^^^^^^^^^^ I agree that SSM is much more appealing to commercial providers at this time, and covers 80% of the users and applications out there, so, that's great. If it motivates content providers, enterprises, and consumer ISP's, wonderful. But, it doesn't necessarily cover 100% of the users and applications. Also, a couple of message have mentioned the difficulties os PIM-SM, RP's, etc., but, I honestly think it is *easy* compared to many things out there- it just doesn't have many people's bottom lines associated with it today. (Compare PIM to, for example, what ISPs do regarding traffic engineering (in general), or what enterprises do with frame-relay, and ISDN, and tons of other messy stuff. PIM is easy by contrast.) The biggest problem we have today with MSDP is the same thing that we have always had with multicast -- people generally don't monitor things until the minute they need them, so, something may be broken for a while before someone notices it. When lots of people are accessing lots of multicast content, network operators will start hearing complaints when things break, just like they do now with web access. > Maybe SSM is just a stepping stone to the full functionality that > shared-tree infrastructures provide. But it will be a whole lot better > than what we have now, where multicast is virtually nowhere to be found. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Multicast is widely available on WANs. By far the largest problem is getting it into the enterprise LAN and out to the consumer. If SSM is the catalyst that gets content providers and consumers demanding multicast, that's great, but, you're still going to have to deal with all the legacy enterprise, dialup, tier-2/3 deployment issues that you had before. [Hmm. I'm plagiarizing...;-) ] The hope is, that, with new content providers embracing SSM, the demand will be there, and hence, the motivation to work on the deployment issues. ======= The other issue is the future: SSM will work fine for accessing broadcast-type content-- there aren't going to be *that* many content providers out there, and, consumers will expect to find that content at the providers web site. Additional router state will be small. SSM doesn't address the problem of a scalable multicast source directory (neither does the SAP-via-MSDP method either, really - MSDP won't scale to really large numbers of sources either). SSM also doesn't address the problem of large numbers of "small" groups. I think we still need a pure shared-tree implementation to handle the (1000's of low-bandwidth sources)X(1000's of groups) problem. -- Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From eckert@cisco.com Thu Nov 16 14:16:52 2000 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06301 for ; Thu, 16 Nov 2000 14:16:52 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA05107 for ; Thu, 16 Nov 2000 12:57:35 -0500 (EST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA05422; Thu, 16 Nov 2000 09:59:09 -0800 (PST) From: Toerless Eckert Message-Id: <200011161759.JAA05422@cisco.com> Subject: Re: Use of SAP in a PIM SSM Network To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Thu, 16 Nov 2000 09:59:09 -0800 (PST) Cc: eckert@cisco.com (Toerless Eckert), lenny@juniper.net (Leonard Giuliano), lamaster@nren.nasa.gov (Hugh LaMaster), ssm-interest@external.cisco.com, J.Crowcroft@cs.ucl.ac.uk In-Reply-To: <16813.974363163@cs.ucl.ac.uk> from "Jon Crowcroft" at Nov 16, 2000 08:26:03 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > not clear - the GLOP and ipv6 ways of allocating multicast introduce > _some_ hierarchiy - in fact its relatively easy to impose all sorts if > you have _enough_ address space..... Isn't the right phrase for IPv4 "If you had _enough_ address space..." ? > if yo uhave applications which genuijley have significant number of > sources with dynamics, then the server solution does not scale - you > have just pushed the management problem to that of > 1/ locating one of a set of servers (how) > 2/ making servers fault tolerant (anyone for anycast? :-) > 3/ managing the application state in an unnatural way > 4/ putting performance (delay and procerssign) limits on the scale of > the application Well, /1 i think is not siginificantly more expensive if done outside the network layer than inside. The way we have it now is to have one common "server" (RP) infrastructure for all applications together, and isn't it exactly this one size fits all" that limits flexibility introduces unnecessary complexity and can not be individually be optimized for particular suites of applications ? /2 Sure, i love anycast ;-) /3 I do not get it. "Biking is an unnatural way of transportation (TM) automotive society" ? /4 Only if we can assume that we can not build scaling server infrastructures for large scale applications. I think we can. There must be something all those content server boxes will be good for. How about this ? Wasn't there sufficient research in distributed systems in the last 20 years to come up with appropriate solutions for larger scale applications, as long as you stick to some scenarios in the first place (instead of trying to solve it generically for all of them together in the network layer) ? > ok so you could have a hierarchy of redundant servers....,and what > standard internet protocoos are you going to use to manage those? Why does it have to be standardised in the IETF ? Why not some other place ? Why are things like CORBA not standardised in the IETF ? Don't those distributed applications relying on it run over the Internet also ? > no, i think we need to retain the deering multicast model and just > keep up the pressure on Large Router Vendors (this means you:-) > to be smart about scaling the routers up to meet the users > requirements rather than scaling the users expectations down to what > you want to do:-) We won't take the holy grail away, Lancelot ;-) I guess this router vendor would just love to see some return of investment on multicast, and as far as i am concerned this in the first place means to get ip packet replication in routers used and payed for. The control plane operations will just follow the users application demands, and SSM is just another alternative. If there were more interesting Internet-wide applications that can not work well with SSM, then certainly the focus would be different. Cheers Toerless From zalbanna@MCI.NET Thu Nov 16 19:21:02 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26959 for ; Thu, 16 Nov 2000 19:21:01 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA18695 for ; Thu, 16 Nov 2000 14:43:17 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAGMhMM07665 for ; Thu, 16 Nov 2000 14:43:22 -0800 (PST) Received: from NOD.RESTON.MCI.NET ([166.60.6.38]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id OAA11743 for ; Thu, 16 Nov 2000 14:43:11 -0800 (PST) Received: from zaid ([166.60.2.9]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JWM74X8WB29LVL15@shoe.reston.mci.net> for ssm-interest@external.cisco.com; Thu, 16 Nov 2000 17:39:18 EST Date: Thu, 16 Nov 2000 17:43:30 -0500 From: zaid Subject: Re: Use of SAP in a PIM SSM Network To: ssm-interest@external.cisco.com Message-id: <010c01c0501e$a4df1c20$09023ca6@zaid.loudoun.mci.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook Express 4.72.3110.1 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Just wondering ........ Instead of having a SAP like mechanism , does it make sense to have a [Si,Gw] for every [Si,Gx] (x=1....n). Where Gw is a well known group with a well known port number ?? -----Original Message----- From: Toerless Eckert To: Jon Crowcroft Cc: Toerless Eckert ; Leonard Giuliano ; Hugh LaMaster ; ssm-interest@external.cisco.com ; J.Crowcroft@cs.ucl.ac.uk Date: Thursday, November 16, 2000 1:43 PM Subject: Re: Use of SAP in a PIM SSM Network > not clear - the GLOP and ipv6 ways of allocating multicast introduce > _some_ hierarchiy - in fact its relatively easy to impose all sorts if > you have _enough_ address space..... Isn't the right phrase for IPv4 "If you had _enough_ address space..." ? > if yo uhave applications which genuijley have significant number of > sources with dynamics, then the server solution does not scale - you > have just pushed the management problem to that of > 1/ locating one of a set of servers (how) > 2/ making servers fault tolerant (anyone for anycast? :-) > 3/ managing the application state in an unnatural way > 4/ putting performance (delay and procerssign) limits on the scale of > the application Well, /1 i think is not siginificantly more expensive if done outside the network layer than inside. The way we have it now is to have one common "server" (RP) infrastructure for all applications together, and isn't it exactly this one size fits all" that limits flexibility introduces unnecessary complexity and can not be individually be optimized for particular suites of applications ? /2 Sure, i love anycast ;-) /3 I do not get it. "Biking is an unnatural way of transportation (TM) automotive society" ? /4 Only if we can assume that we can not build scaling server infrastructures for large scale applications. I think we can. There must be something all those content server boxes will be good for. How about this ? Wasn't there sufficient research in distributed systems in the last 20 years to come up with appropriate solutions for larger scale applications, as long as you stick to some scenarios in the first place (instead of trying to solve it generically for all of them together in the network layer) ? > ok so you could have a hierarchy of redundant servers....,and what > standard internet protocoos are you going to use to manage those? Why does it have to be standardised in the IETF ? Why not some other place ? Why are things like CORBA not standardised in the IETF ? Don't those distributed applications relying on it run over the Internet also ? > no, i think we need to retain the deering multicast model and just > keep up the pressure on Large Router Vendors (this means you:-) > to be smart about scaling the routers up to meet the users > requirements rather than scaling the users expectations down to what > you want to do:-) We won't take the holy grail away, Lancelot ;-) I guess this router vendor would just love to see some return of investment on multicast, and as far as i am concerned this in the first place means to get ip packet replication in routers used and payed for. The control plane operations will just follow the users application demands, and SSM is just another alternative. If there were more interesting Internet-wide applications that can not work well with SSM, then certainly the focus would be different. Cheers Toerless From J.Crowcroft@cs.ucl.ac.uk Fri Nov 17 04:17:10 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18994 for ; Fri, 17 Nov 2000 04:17:10 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id AAA16290 for ; Fri, 17 Nov 2000 00:03:33 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAH83WC14487 for ; Fri, 17 Nov 2000 00:03:32 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with SMTP id AAA26550 for ; Fri, 17 Nov 2000 00:03:30 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 17 Nov 2000 07:57:09 +0000 To: Toerless Eckert cc: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network In-reply-to: Your message of "Thu, 16 Nov 2000 09:59:09 PST." <200011161759.JAA05422@cisco.com> Date: Fri, 17 Nov 2000 07:57:06 +0000 Message-ID: <24631.974447826@cs.ucl.ac.uk> From: Jon Crowcroft In message <200011161759.JAA05422@cisco.com>, Toerless Eckert typed: >>/4 Only if we can assume that we can not build scaling server infrastructures >>for large scale applications. I think we can. There must be something all >>those content server boxes will be good for. How about this ? Wasn't there >>sufficient research in distributed systems in the last 20 years to come up >>with appropriate solutions for larger scale applications, as long as you >>stick to some scenarios in the first place (instead of trying to solve >>it generically for all of them together in the network layer) ? what i am tellng you is that there WASNT sufficient research in distributed systems (i know - i was part of it:-) IP level solutions are better at scaling for fault tolerance - most the distributed server solutions are good up to Big Numbers like 3. >>> ok so you could have a hierarchy of redundant servers....,and what >>> standard internet protocoos are you going to use to manage those? >>Why does it have to be standardised in the IETF ? Why not some other place ? >>Why are things like CORBA not standardised in the IETF ? Don't those >>distributed applications relying on it run over the Internet also ? oh boy, so we dont need to be able to buy multi-vendor solutions? dont be silly. >>> no, i think we need to retain the deering multicast model and just >>> keep up the pressure on Large Router Vendors (this means you:-) >>> to be smart about scaling the routers up to meet the users >>> requirements rather than scaling the users expectations down to what >>> you want to do:-) >>We won't take the holy grail away, Lancelot ;-) thanks....but it aint that hard if we buy juniper:-) >>I guess this router vendor would just love to see some return of investment >>on multicast, and as far as i am concerned this in the first place means >>to get ip packet replication in routers used and payed for. The control plane >>operations will just follow the users application demands, and SSM is just >>another alternative. If there were more interesting Internet-wide applications >>that can not work well with SSM, then certainly the focus would be different. hey, dont get me wrongh - i LOVE ssm - its cool, its good, it scales, it makes really good coffee etc - dont let me put you off - just trying to say: don't throw out the work on PIM bidir just yet:-) cheers jon From eckert@cisco.com Fri Nov 17 04:43:00 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29588 for ; Fri, 17 Nov 2000 04:43:00 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA13204 for ; Fri, 17 Nov 2000 00:28:54 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA25518; Fri, 17 Nov 2000 00:28:52 -0800 (PST) From: Toerless Eckert Message-Id: <200011170828.AAA25518@cisco.com> Subject: Re: Use of SAP in a PIM SSM Network To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Fri, 17 Nov 2000 00:28:52 -0800 (PST) Cc: eckert@cisco.com (Toerless Eckert), ssm-interest@external.cisco.com In-Reply-To: <24631.974447826@cs.ucl.ac.uk> from "Jon Crowcroft" at Nov 17, 2000 07:57:06 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >>Why does it have to be standardised in the IETF ? Why not some other place ? > >>Why are things like CORBA not standardised in the IETF ? Don't those > >>distributed applications relying on it run over the Internet also ? > > oh boy, so we dont need to be able to buy multi-vendor solutions? dont > be silly. No, multi-vendor solutions are nice (well, if they work, as a customer i've mostly encountered cases where they don't, but let's not use practical experience as a distraction for ideals one would like to follow). I was only suggesting that the IETF is not the only place to standardise multi-vendor solutions. > >>We won't take the holy grail away, Lancelot ;-) > > thanks....but it aint that hard if we buy juniper:-) Well, if ip multicast were ever to vanish completely due to ssm (which i neither expect nor hope), then i'd rather guess that Cisco will still have the last bastions of customers ("he who starts earlier needs to be backward compatible much longer" - see also reference [Microsoft]). > hey, dont get me wrongh - i LOVE ssm - its cool, its good, it scales, > it makes really good coffee etc - dont let me put you off - just > trying to say: don't throw out the work on PIM bidir just yet:-) Oh, on the contrary. As far as architecture is concerned, SSM is so simple, so well working, so uncontroversial, so... boring ? Evolving on Bidir-PIM is much more challenging. Especially if you think about all the politics on BGMP. Now just give us lots of customer incentive to evolve there... Cheers Toerless P.S.: There are no Corba applications with more than 3 hosts involved ? ;-)) From Scott.Millington@edt.ericsson.se Sun Nov 19 15:51:39 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12520 for ; Sun, 19 Nov 2000 15:51:39 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA27818 for ; Sun, 19 Nov 2000 11:32:50 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAJJWnN20614 for ; Sun, 19 Nov 2000 11:32:49 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id LAA29814 for ; Sun, 19 Nov 2000 11:32:48 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id eAJJW7t04021 for ; Sun, 19 Nov 2000 20:32:07 +0100 (MET) Received: FROM esealnt444.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sun Nov 19 20:32:07 2000 +0100 Received: by esealnt444 with Internet Mail Service (5.5.2651.58) id ; Sun, 19 Nov 2000 20:32:06 +0100 Message-ID: <33C9100DDE98D211A16D0008C7A4E3FE0818F2D3@esealnt103> From: "Scott Millington (BCT)" To: "'ssm-interest@external.cisco.com'" Subject: RE: Use of SAP in a PIM SSM Network Date: Sun, 19 Nov 2000 20:31:57 +0100 Return-Receipt-To: "Scott Millington (BCT)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA12520 Hi Hugh & all, I don't know in which world you are living, but I would love to be there. Ericsson has very little problem with multicast in Campus environmnets & LAN's...It is the WAN that "generates" all the problems (link speed, load on existing links, business critical traffic "at risk", and redundancy). Add to this that My division is responsible, but doesn't have control over different "islands" it also becomes a political mess. I have been kicking away for 2 years to try and motivate folks / organisations to open their eyes to the necessity of multicast. Until September there was very little interest. NOW everyone & their brother wants everything to work 6 months ago. Perhaps it is the globality of organisations that the Ericsson Global IT Services Provides for...Am I the only one with this dilemma?? SSM would be wonderful if we can get it up & running with support for different applications. I have an organisational question but it can easily be SSM / PIM-SM related. Is there anyone out there that has an application (Platform & Application independant) for the dynamic assignment of multicast addresses GGG.GGG.GGG.GGG:port where folks can book a randomized multicast group in the same way as one would book a conference room?? A bonus feature would be that this application could handle & mediate conflicts (someone "keeping" an assignment, or making their own assignments). My problem is that conflicts are a recognised "threat", but my department is only responsible for providing "Multicast" in the net...without any concern for the applications / uses. Sincerely, Scott Millington Data Communications Architect +++++++++++++++++++++++++ Ericsson Global IT Services AB Corporate Network - Basic EriNet KI/BCT/I/ONF Kistagången 4-4tr. 125 82 Stockholm Telephone: +46-8-75 71667 Cellphone: +46-70-643 7897 Facsimile: +46-8-40 45550 EMAIL: scott.millington@edt.ericsson.se URL: work - http://www.ericsson.se home - http://haapis.zap.to +++++++++++++++++++++++++ Disclaimer: When I say something it is just me saying something and it is probably wrong anyway. Certainly nothing I post should be construed as a statement of Ericsson company policy. -----Original Message----- From: Hugh LaMaster [mailto:lamaster@nren.nasa.gov] Sent: 2000-11-16 18:11 To: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network Multicast is widely available on WANs. By far the largest problem is getting it into the enterprise LAN and out to the consumer. If SSM is the catalyst that gets content providers and consumers demanding multicast, that's great, but, you're still going to have to deal with all the legacy enterprise, dialup, tier-2/3 deployment issues that you had before. [Hmm. I'm plagiarizing...;-) ] The hope is, that, with new content providers embracing SSM, the demand will be there, and hence, the motivation to work on the deployment issues. From finlayson@live.com Tue Nov 21 03:09:50 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11427 for ; Tue, 21 Nov 2000 03:09:49 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id XAA17295 for ; Mon, 20 Nov 2000 23:00:08 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAL707R24644 for ; Mon, 20 Nov 2000 23:00:07 -0800 (PST) Received: from ns.live.com (ns.live.com [208.184.148.162]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id WAA02694 for ; Mon, 20 Nov 2000 22:59:28 -0800 (PST) Received: from rsf-laptop.live.com (dhcp0.live.com [208.184.148.170]) by ns.live.com (8.9.3/8.9.3) with ESMTP id WAA97374 for ; Mon, 20 Nov 2000 22:54:17 -0800 (PST) (envelope-from finlayson@live.com) Message-Id: <4.3.1.1.20001120224608.00b7c9f0@ns.live.com> X-Sender: rsf@ns.live.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 20 Nov 2000 22:52:52 -0800 To: ssm-interest@external.cisco.com From: Ross Finlayson Subject: How to describe SSM sessions in SDP? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I've forgotten - does "draft-ietf-mmusic-sdp-srcfilter-00.txt" describe our current consensus for how SSM sessions are described in SDP - e.g., c=IN IP4 232.3.4.5/127 a=incl:IN IP4 232.3.4.5 192.168.9.10 ? I remember that this was discussed in one of the meetings in Pittsburgh (and that I was the only person in the room who would have preferred to have everything specified in the "c=" line :-), but I forget what approach we ended up with (if it's different from that described in "draft-ietf-mmusic-sdp-srcfilter-00.txt")? Ross. From eckert@cisco.com Tue Nov 21 03:36:06 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14321 for ; Tue, 21 Nov 2000 03:36:05 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA17051 for ; Mon, 20 Nov 2000 23:17:21 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA15952; Mon, 20 Nov 2000 23:16:51 -0800 (PST) From: Toerless Eckert Message-Id: <200011210716.XAA15952@cisco.com> Subject: Re: How to describe SSM sessions in SDP? To: finlayson@live.com (Ross Finlayson) Date: Mon, 20 Nov 2000 23:16:51 -0800 (PST) Cc: ssm-interest@external.cisco.com In-Reply-To: <4.3.1.1.20001120224608.00b7c9f0@ns.live.com> from "Ross Finlayson" at Nov 20, 2000 10:52:52 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I've forgotten - does "draft-ietf-mmusic-sdp-srcfilter-00.txt" describe our > current consensus for how SSM sessions are described in SDP - e.g., > c=IN IP4 232.3.4.5/127 > a=incl:IN IP4 232.3.4.5 192.168.9.10 > ? It seems to describe that, yes. It is a bit sad though, that it, like IGMPv3 tries to provide just an adequate solution for ISM (normal multicast) in the first place, even though most likely most users of both IGMPv3 and such an SDDP extension will want to use it for SSM. Problem is: There is nothing in this extened session description telling you if the filtering is just voluntarily - which is what filtering is for ISM, or if this is rather a necessary provisioning of the source address for the benefit of SSM. So an upgraded application that can recognize this extension can not differentiate if this is a SSM session, so it can not warn the user that he won't see traffic in case that there's just insufficient stack below - like only IGMPv2 or the like. Sure, the IGMPv3 API doesn't provide sufficient information either, but that just makes it worse. So an application that would like to learn if that's an SSM session, or if it can optionally express the filtering needs more attributes than just the list of sources. It would need at least another binary bit "Must include" or the like. Could rather call it "SSM" anyhow. My 2cents. Cheers Toerless From rcq@sockets.com Tue Nov 21 07:53:34 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19656 for ; Tue, 21 Nov 2000 07:53:33 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id DAA25843 for ; Tue, 21 Nov 2000 03:18:19 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eALBIJ305760 for ; Tue, 21 Nov 2000 03:18:19 -0800 (PST) Received: from celox-hud-ems1.celoxnetworks.com ([12.45.226.221]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id DAA03726 for ; Tue, 21 Nov 2000 03:17:43 -0800 (PST) Received: from laptop33 (laptop33.celoxnetworks.com [192.168.31.55]) by celox-hud-ems1.celoxnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id W0A89JHW; Tue, 21 Nov 2000 06:14:56 -0500 Message-Id: <4.1.20001121053853.021d4f00@celox-hud-imap1.celoxnetworks.com> X-Sender: rcq@sockets.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 21 Nov 2000 06:16:47 -0500 To: Toerless Eckert From: bob quinn Subject: Re: How to describe SSM sessions in SDP? Cc: finlayson@live.com (Ross Finlayson), ssm-interest@external.cisco.com In-Reply-To: <200011210716.XAA15952@cisco.com> References: <4.3.1.1.20001120224608.00b7c9f0@ns.live.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 02:16 AM 11/21/00 , Toerless Eckert wrote: >> I've forgotten - does "draft-ietf-mmusic-sdp-srcfilter-00.txt" describe our >> current consensus for how SSM sessions are described in SDP - e.g., >> c=IN IP4 232.3.4.5/127 >> a=incl:IN IP4 232.3.4.5 192.168.9.10 >> ? > >It seems to describe that, yes. It is a bit sad though, that it, like IGMPv3 >tries to provide just an adequate solution for ISM (normal multicast) in >the first place, even though most likely most users of both IGMPv3 and >such an SDDP extension will want to use it for SSM. > >Problem is: There is nothing in this extened session description telling you >if the filtering is just voluntarily - which is what filtering is for ISM, >or if this is rather a necessary provisioning of the source address for >the benefit of SSM. Isn't the need for a source address (aka, a "filter") implicit to the *Source Specific* Multicast address range? >So an upgraded application that can recognize this extension can not >differentiate if this is a SSM session, so it can not warn the user that >he won't see traffic in case that there's just insufficient stack below - >like only IGMPv2 or the like. Sure, the IGMPv3 API doesn't provide >sufficient information either, but that just makes it worse. Current Multicast protocols and APIs are no better. When you join any ISM group, there's no feedback from local routers or APIs to notify an application when they won't receive anything (e.g., when the local router isn't forwarding multicast traffic). So, if we're going to improve the API and IGMP for SSM, why not improve it for ISM too, while we're at it? A new API and IGMP message for both would be very nice. Something that would actually query the local router(s) for IGMP version and an indication of whether they have a multicast routing protocol enabled would be much appreciated by multicast application developers (and their users). >So an application that would like to learn if that's an SSM session, or >if it can optionally express the filtering needs more attributes than >just the list of sources. It would need at least another binary bit >"Must include" or the like. Could rather call it "SSM" anyhow. That still seems hit-or-miss without a feedback mechanism from the local infrastructure and API. regards, bob quinn From eckert@cisco.com Tue Nov 21 17:33:52 2000 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17547 for ; Tue, 21 Nov 2000 17:33:51 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA15327 for ; Tue, 21 Nov 2000 16:23:03 -0500 (EST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA17560; Tue, 21 Nov 2000 13:23:44 -0800 (PST) From: Toerless Eckert Message-Id: <200011212123.NAA17560@cisco.com> Subject: Re: How to describe SSM sessions in SDP? To: rcq@sockets.com (bob quinn) Date: Tue, 21 Nov 2000 13:23:44 -0800 (PST) Cc: eckert@cisco.com (Toerless Eckert), finlayson@live.com (Ross Finlayson), ssm-interest@external.cisco.com In-Reply-To: <4.1.20001121053853.021d4f00@celox-hud-imap1.celoxnetworks.com> from "bob quinn" at Nov 21, 2000 06:16:47 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Isn't the need for a source address (aka, a "filter") implicit > to the *Source Specific* Multicast address range? Right, but so far i am not persuaded that everyone agress that all future applications, stacks and protocols should just hardcode 232/8 to be SSM and only that range to SSM. And of couorse we already have customers who ask for multicast outside this range to (ab)use scoping for access control. So i guess as of today we don't know if a group is SSM or not by just looking on the group address, and as long as we have this, it owuld really be help full if we could try to convey this information a bit better than we try to do it now (like we convey it not). > Current Multicast protocols and APIs are no better. When you > join any ISM group, there's no feedback from local routers or > APIs to notify an application when they won't receive anything > (e.g., when the local router isn't forwarding multicast traffic). True, but with SSM we're adding another layer of uncertainty, which is about the source address being option or not. > So, if we're going to improve the API and IGMP for SSM, why not > improve it for ISM too, while we're at it? A new API and IGMP > message for both would be very nice. Something that would actually > query the local router(s) for IGMP version and an indication of > whether they have a multicast routing protocol enabled would be > much appreciated by multicast application developers (and their > users). Well as far as ISM is concerned, the host stack does already know if there's a router and which version the router has. It's just the API that never wanted to deliver this information to the host. As long as there was only ISM, i think the mayority of reasons was in favor of not doing this signalling, but today i'm concerned about applications that may for example get two session announcements, one which is low-bandwidth ISM, and the other is high-bandwidth SSM and then i'd like the application to be able to differentiate a bit better if a session is one or the other. Cheers Toerless From almeroth@cs.ucsb.edu Wed Nov 22 12:51:11 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08432 for ; Wed, 22 Nov 2000 12:51:10 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA12639 for ; Wed, 22 Nov 2000 08:00:02 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAMFxur22101 for ; Wed, 22 Nov 2000 07:59:56 -0800 (PST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id HAA19555 for ; Wed, 22 Nov 2000 07:59:19 -0800 (PST) Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by letters.cs.ucsb.edu (8.9.3+Sun/8.9.3) with ESMTP id HAA02873; Wed, 22 Nov 2000 07:41:11 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id HAA05210 for ; Wed, 22 Nov 2000 07:41:10 -0800 (PST) Date: Wed, 22 Nov 2000 07:41:10 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200011221541.HAA05210@jackson.cs.ucsb.edu> To: Scott.Millington@edt.ericsson.se, ssm-interest@external.cisco.com Subject: RE: Use of SAP in a PIM SSM Network >>Ericsson has very little problem with multicast in Campus environmnets & LAN's...It is the WAN that "generates" all the problems (link speed, load on existing links, business critical traffic "at risk", and redundancy). Add to this that My division is responsible, but doesn't have control over different "islands" it also becomes a political mess. I hate to bring up an oft repeated argument: "How do you deal with this for unicast?" When peering between domains, every single issue you mention is both an issue for unicast and multicast. >>I have been kicking away for 2 years to try and motivate folks / organisations to open their eyes to the necessity of multicast. Until September there was very little interest. NOW everyone & their brother wants everything to work 6 months ago. Perhaps it is the globality of organisations that the Ericsson Global IT Services Provides for...Am I the only one with this dilemma?? Nope... and everyone is struggling. The solution seems to be to get these folks thinking the right way about multicast. >>SSM would be wonderful if we can get it up & running with support for different applications. Do you have content and applications lined up? >>I have an organisational question but it can easily be SSM / PIM-SM related. Is there anyone out there that has an application (Platform & Application independant) for the dynamic assignment of multicast addresses GGG.GGG.GGG.GGG:port where folks can book a randomized multicast group in the same way as one would book a conference room?? A bonus feature would be that this application could handle & mediate conflicts (someone "keeping" an assignment, or making their own assignments). Again, this is perception. Tell your folks if they feel like they are likely to see a conflict, they should go buy a lottery ticket. Same odds. -Kevin From luby@digitalfountain.com Wed Nov 22 14:35:52 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10282 for ; Wed, 22 Nov 2000 14:35:51 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA25655 for ; Wed, 22 Nov 2000 10:03:18 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAMI3ML01208 for ; Wed, 22 Nov 2000 10:03:22 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id KAA17529 for ; Wed, 22 Nov 2000 10:02:34 -0800 (PST) Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id JAA19739; Wed, 22 Nov 2000 09:56:20 -0800 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: "Mike Luby" To: "Kevin C. Almeroth" , , Cc: "Michael Luby" Subject: RE: Use of SAP in a PIM SSM Network Date: Wed, 22 Nov 2000 09:56:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <200011221541.HAA05210@jackson.cs.ucsb.edu> Content-Transfer-Encoding: 7bit Actually, I don't fully understand the last question about choosing SSM multicast addresses uniquely. Since with SSM the address (channel) that the client sends an IGMPv3 join to is a (S,G) pair, where S is the origin server IP address and G is easily chosen to be unique among all G's that S is sourcing, it would seem that the problem of finding a globally unique address is not a problem. However, there is still the issue of how the (S,G) address is mapped to a shorter address by some hardware environments like Ethernet, and maybe the question is how to make sure that this is unique with high probability? It would be good to clarify this question so that there aren't misunderstandings and so that the weakness of the current solutions can be potentially fixed in the future. -Mike -----Original Message----- From: Kevin C. Almeroth [mailto:almeroth@cs.ucsb.edu] Sent: Wednesday, November 22, 2000 7:41 AM To: Scott.Millington@edt.ericsson.se; ssm-interest@external.cisco.com Subject: RE: Use of SAP in a PIM SSM Network >>Ericsson has very little problem with multicast in Campus environmnets & LAN's...It is the WAN that "generates" all the problems (link speed, load on existing links, business critical traffic "at risk", and redundancy). Add to this that My division is responsible, but doesn't have control over different "islands" it also becomes a political mess. I hate to bring up an oft repeated argument: "How do you deal with this for unicast?" When peering between domains, every single issue you mention is both an issue for unicast and multicast. >>I have been kicking away for 2 years to try and motivate folks / organisations to open their eyes to the necessity of multicast. Until September there was very little interest. NOW everyone & their brother wants everything to work 6 months ago. Perhaps it is the globality of organisations that the Ericsson Global IT Services Provides for...Am I the only one with this dilemma?? Nope... and everyone is struggling. The solution seems to be to get these folks thinking the right way about multicast. >>SSM would be wonderful if we can get it up & running with support for different applications. Do you have content and applications lined up? >>I have an organisational question but it can easily be SSM / PIM-SM related. Is there anyone out there that has an application (Platform & Application independant) for the dynamic assignment of multicast addresses GGG.GGG.GGG.GGG:port where folks can book a randomized multicast group in the same way as one would book a conference room?? A bonus feature would be that this application could handle & mediate conflicts (someone "keeping" an assignment, or making their own assignments). Again, this is perception. Tell your folks if they feel like they are likely to see a conflict, they should go buy a lottery ticket. Same odds. -Kevin From wilbertdg@hetnet.nl Wed Nov 22 16:43:40 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17485 for ; Wed, 22 Nov 2000 16:43:39 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA14297 for ; Wed, 22 Nov 2000 12:36:39 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAMKaXC18590 for ; Wed, 22 Nov 2000 12:36:33 -0800 (PST) Received: from hetnet.nl (net090s.hetnet.nl [194.151.104.183]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id MAA26939 for ; Wed, 22 Nov 2000 12:35:55 -0800 (PST) Received: from pecan ([192.150.187.119]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.537.53); Wed, 22 Nov 2000 21:31:31 +0100 Message-ID: <008a01c054c2$f1fbe620$77bb96c0@pecan> From: "Wilbert de Graaf" To: References: <200011221541.HAA05210@jackson.cs.ucsb.edu> Subject: Multicast seminar at LINX: Can I safely tell my manager ? Date: Wed, 22 Nov 2000 12:29:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Next week there is a multicast seminar at the London Internet Exchange (LINX): http://www.linx.net/multicast/programme.html I was wondering if anybody knows it's safe to send my manager, before he comes back with a new set of cons. - Wilbert From tme@21rst-century.com Wed Nov 22 21:11:23 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25098 for ; Wed, 22 Nov 2000 21:11:12 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA07483 for ; Wed, 22 Nov 2000 16:56:43 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAN0ucO01227 for ; Wed, 22 Nov 2000 16:56:38 -0800 (PST) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id QAA29201 for ; Wed, 22 Nov 2000 16:56:28 -0800 (PST) Received: from [216.8.7.56] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 570796; Wed, 22 Nov 2000 19:39:06 -0500 Message-ID: <3A1C67D1.B4814CBF@21rst-century.com> Date: Wed, 22 Nov 2000 19:41:54 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Mike Luby CC: "Kevin C. Almeroth" , Scott.Millington@edt.ericsson.se, ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mike Luby wrote: > > Actually, I don't fully understand the last question about choosing SSM > multicast addresses uniquely. Since with SSM the address (channel) that the > client sends an IGMPv3 join to is a (S,G) pair, where S is the origin server > IP address and G is easily chosen to be unique among all G's that S is > sourcing, it would seem that the problem of finding a globally unique > address is not a problem. However, there is still the issue of how the > (S,G) address is mapped to a shorter address by some hardware environments > like Ethernet, and maybe the question is how to make sure that this is > unique with high probability? It would be good to clarify this question so > that there aren't misunderstandings and so that the weakness of the current > solutions can be potentially fixed in the future. > -Mike > Dear Mike; I think that the biggest issue here is MAC address collision at layer 2. I think that it is a good idea to avoid this if possible. What we plan to do with our SSM broadcasts (starting next month) is to map our GLOP space from 233/8 into the 232/8 SSM address range, and use that. If everyone does this, then it is pretty straight-forward to avoid MAC collisions. Of course, then, if you have more than 256 multicast groups, you have to worry about collisions, but at least you can manage that yourself (or acquire access to another ASN). The basic thing here is that broadcasters are going to want static Class D addresses. (We, for example, have been up (doing ISM) since early October with about 30 seconds of down time, and certainly want constant addresses.) SSM will not change that. Whether these addresses are assigned by GLOP type mechanisms or by other means such as MALLOC/ MADCAP doesn't really matter that much, as long as collisions can be avoided. It would be nice, however, if a Global SSM allocation mechanism could be set up in the near future, before too many people's choices get set in stone. Marshall > -----Original Message----- > From: Kevin C. Almeroth [mailto:almeroth@cs.ucsb.edu] > Sent: Wednesday, November 22, 2000 7:41 AM > To: Scott.Millington@edt.ericsson.se; ssm-interest@external.cisco.com > Subject: RE: Use of SAP in a PIM SSM Network > > >>Ericsson has very little problem with multicast in Campus environmnets & > LAN's...It is the WAN that "generates" all the problems (link speed, load on > existing links, business critical traffic "at risk", and redundancy). Add > to this that My division is responsible, but doesn't have control over > different "islands" it also becomes a political mess. > > I hate to bring up an oft repeated argument: "How do you deal with > this for unicast?" > > When peering between domains, every single issue you mention is > both an issue for unicast and multicast. > > >>I have been kicking away for 2 years to try and motivate folks / > organisations to open their eyes to the necessity of multicast. Until > September there was very little interest. NOW everyone & their brother > wants everything to work 6 months ago. Perhaps it is the globality of > organisations that the Ericsson Global IT Services Provides for...Am I the > only one with this dilemma?? > > Nope... and everyone is struggling. The solution seems to be to > get these folks thinking the right way about multicast. > > >>SSM would be wonderful if we can get it up & running with support for > different applications. > > Do you have content and applications lined up? > > >>I have an organisational question but it can easily be SSM / PIM-SM > related. Is there anyone out there that has an application (Platform & > Application independant) for the dynamic assignment of multicast addresses > GGG.GGG.GGG.GGG:port where folks can book a randomized multicast group in > the same way as one would book a conference room?? A bonus feature would be > that this application could handle & mediate conflicts (someone "keeping" an > assignment, or making their own assignments). > > Again, this is perception. Tell your folks if they feel like they > are likely to see a conflict, they should go buy a lottery ticket. > Same odds. > > -Kevin -- Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From pusateri@juniper.net Wed Nov 22 23:26:59 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16674 for ; Wed, 22 Nov 2000 23:26:58 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id TAA29040 for ; Wed, 22 Nov 2000 19:13:19 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAN3DI204965 for ; Wed, 22 Nov 2000 19:13:18 -0800 (PST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id TAA20612 for ; Wed, 22 Nov 2000 19:12:40 -0800 (PST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA07451; Wed, 22 Nov 2000 19:07:27 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id TAA99587; Wed, 22 Nov 2000 19:07:27 -0800 (PST) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200011230307.TAA99587@garnet.juniper.net> To: tme@21rst-century.com cc: Mike Luby , "Kevin C. Almeroth" , Scott.Millington@edt.ericsson.se, ssm-interest@external.cisco.com, pusateri@juniper.net Subject: Re: Use of SAP in a PIM SSM Network In-Reply-To: Message from Marshall Eubanks of "Wed, 22 Nov 2000 19:41:54 EST." <3A1C67D1.B4814CBF@21rst-century.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99584.974948847.1@garnet.juniper.net> Date: Wed, 22 Nov 2000 19:07:27 -0800 From: Tom Pusateri In message <3A1C67D1.B4814CBF@21rst-century.com> you write: > > The basic thing here is that broadcasters are going to want static >Class D addresses. (We, for example, have been up (doing ISM) since >early >October with about 30 seconds of down time, and certainly want constant >addresses.) >SSM will not change that. Whether these addresses are assigned by GLOP >type mechanisms or by other means such as MALLOC/ MADCAP doesn't really >matter that much, as long >as collisions can be avoided. It would be nice, however, if a Global SSM >allocation mechanism could be set up in the near future, before too many >people's choices get set in stone. Encouraging the use of static Class D addresses sets a bad precedent and I don't think we should be encouraging this. The broadcasters and content providers have static host names which can be used for rendezvousing and the source address and group address should be able to float as needed to meet demand. End users will not be aware of the group address being used under most circumstances anyway. Thanks, Tom From Scott.Millington@edt.ericsson.se Thu Nov 23 04:37:07 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04091 for ; Thu, 23 Nov 2000 04:37:06 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id AAA00918 for ; Thu, 23 Nov 2000 00:42:21 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAN8gK710060 for ; Thu, 23 Nov 2000 00:42:20 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id AAA14124 for ; Thu, 23 Nov 2000 00:42:18 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id eAN8fct11436 for ; Thu, 23 Nov 2000 09:41:38 +0100 (MET) Received: FROM esealnt444.al.sw.ericsson.se BY esealnt461 ; Thu Nov 23 09:41:37 2000 +0100 Received: by esealnt444 with Internet Mail Service (5.5.2651.58) id ; Thu, 23 Nov 2000 09:41:37 +0100 Message-ID: <33C9100DDE98D211A16D0008C7A4E3FE0818F309@esealnt103> From: "Scott Millington (BCT)" To: "'tme@21rst-century.com'" , Mike Luby Cc: "Kevin C. Almeroth" , ssm-interest@external.cisco.com Subject: RE: Use of SAP in a PIM SSM Network Date: Thu, 23 Nov 2000 09:41:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" The problem is that someone could "hard code" a group address, and then begin sending at a different time. If they do this and interrupt / disturb something important (i.e. a global press conference) then Someone (namely me) will be getting a mess of angry phone calls. Not enough that it is a "hacker" problem, but even Some applications (Marratech off the top o me head) allow many to many where the group:port address combination is the only deciding factor...while this isn't the SSM model there are the same inherent risks, or am I paranoid? Scott Just because you are paranoid doesn't mean they aren't out to get you. -----Original Message----- From: Marshall Eubanks [mailto:tme@21rst-century.com] Sent: 2000-11-23 01:42 To: Mike Luby Cc: Kevin C. Almeroth; Scott.Millington@edt.ericsson.se; ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network Mike Luby wrote: > > Actually, I don't fully understand the last question about choosing SSM > multicast addresses uniquely. Since with SSM the address (channel) that the > client sends an IGMPv3 join to is a (S,G) pair, where S is the origin server > IP address and G is easily chosen to be unique among all G's that S is > sourcing, it would seem that the problem of finding a globally unique > address is not a problem. However, there is still the issue of how the > (S,G) address is mapped to a shorter address by some hardware environments > like Ethernet, and maybe the question is how to make sure that this is > unique with high probability? It would be good to clarify this question so > that there aren't misunderstandings and so that the weakness of the current > solutions can be potentially fixed in the future. > -Mike > Dear Mike; I think that the biggest issue here is MAC address collision at layer 2. I think that it is a good idea to avoid this if possible. What we plan to do with our SSM broadcasts (starting next month) is to map our GLOP space from 233/8 into the 232/8 SSM address range, and use that. If everyone does this, then it is pretty straight-forward to avoid MAC collisions. Of course, then, if you have more than 256 multicast groups, you have to worry about collisions, but at least you can manage that yourself (or acquire access to another ASN). The basic thing here is that broadcasters are going to want static Class D addresses. (We, for example, have been up (doing ISM) since early October with about 30 seconds of down time, and certainly want constant addresses.) SSM will not change that. Whether these addresses are assigned by GLOP type mechanisms or by other means such as MALLOC/ MADCAP doesn't really matter that much, as long as collisions can be avoided. It would be nice, however, if a Global SSM allocation mechanism could be set up in the near future, before too many people's choices get set in stone. Marshall > -----Original Message----- > From: Kevin C. Almeroth [mailto:almeroth@cs.ucsb.edu] > Sent: Wednesday, November 22, 2000 7:41 AM > To: Scott.Millington@edt.ericsson.se; ssm-interest@external.cisco.com > Subject: RE: Use of SAP in a PIM SSM Network > > >>Ericsson has very little problem with multicast in Campus environmnets & > LAN's...It is the WAN that "generates" all the problems (link speed, load on > existing links, business critical traffic "at risk", and redundancy). Add > to this that My division is responsible, but doesn't have control over > different "islands" it also becomes a political mess. > > I hate to bring up an oft repeated argument: "How do you deal with > this for unicast?" > > When peering between domains, every single issue you mention is > both an issue for unicast and multicast. > > >>I have been kicking away for 2 years to try and motivate folks / > organisations to open their eyes to the necessity of multicast. Until > September there was very little interest. NOW everyone & their brother > wants everything to work 6 months ago. Perhaps it is the globality of > organisations that the Ericsson Global IT Services Provides for...Am I the > only one with this dilemma?? > > Nope... and everyone is struggling. The solution seems to be to > get these folks thinking the right way about multicast. > > >>SSM would be wonderful if we can get it up & running with support for > different applications. > > Do you have content and applications lined up? > > >>I have an organisational question but it can easily be SSM / PIM-SM > related. Is there anyone out there that has an application (Platform & > Application independant) for the dynamic assignment of multicast addresses > GGG.GGG.GGG.GGG:port where folks can book a randomized multicast group in > the same way as one would book a conference room?? A bonus feature would be > that this application could handle & mediate conflicts (someone "keeping" an > assignment, or making their own assignments). > > Again, this is perception. Tell your folks if they feel like they > are likely to see a conflict, they should go buy a lottery ticket. > Same odds. > > -Kevin -- Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From Scott.Millington@edt.ericsson.se Thu Nov 23 05:01:50 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11893 for ; Thu, 23 Nov 2000 05:01:49 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id BAA09167 for ; Thu, 23 Nov 2000 01:07:04 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAN973w16894 for ; Thu, 23 Nov 2000 01:07:03 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id BAA18238 for ; Thu, 23 Nov 2000 01:06:24 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id eAN96Kt01556 for ; Thu, 23 Nov 2000 10:06:21 +0100 (MET) Received: FROM esealnt444.al.sw.ericsson.se BY esealnt461 ; Thu Nov 23 10:06:20 2000 +0100 Received: by esealnt444 with Internet Mail Service (5.5.2651.58) id ; Thu, 23 Nov 2000 10:06:20 +0100 Message-ID: <33C9100DDE98D211A16D0008C7A4E3FE0818F30A@esealnt103> From: "Scott Millington (BCT)" To: "'ssm-interest@external.cisco.com'" Subject: RE: Use of SAP in a PIM SSM Network Date: Thu, 23 Nov 2000 10:06:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA11893 Doc, you is preachin to the choir ;) True...Unicast is the same (if not worse) but Multicast is new, "non-traditional", and presently not viewed as production traffic. I mentioned before that I was getting folks motivated...well, when you show a graph of travel costs (air stools, not counting time / hotel etc) contra multicast costs - ripped off quite literally from an old Motorola presentation - the effect on admin folks can be, um, pretty impressive. "Do you have content and applications lined up?" LOL . . . Which came first ;) I actually do have content...a whole organisation where the President is interested in video conferencing "All Staff Meetings" globally. Applications is actually the great motivator, since they appear to be leaning towards Microsoft Media Server...MMS has the wonderful ability to attempt different connectvity methods multicast-udp-tcp-http until it gets contact. This means that simply not enabling multicast is no longer an option. *insert gleeful "I bloody told you so" facial expression here*. As for the lottery comparison...Who says logic has anthing to do with corporate decisionmaking?? Cheers, Scott Millington Data Communications Architect +++++++++++++++++++++++++ Ericsson Global IT Services AB Corporate Network - Basic EriNet KI/BCT/I/ONF Kistagången 4-4tr. 125 82 Stockholm Telephone: +46-8-75 71667 Cellphone: +46-70-643 7897 Facsimile: +46-8-40 45550 EMAIL: scott.millington@edt.ericsson.se URL: work - http://www.ericsson.se home - http://haapis.zap.to +++++++++++++++++++++++++ "Friendship is the hardest thing in the world to explain. It's not something you learn in school. But if you haven't learned the meaning of friendship, you reallyhaven't learned anything." - Muhammad Ali -----Original Message----- From: almeroth@cs.ucsb.edu [mailto:almeroth@cs.ucsb.edu] Sent: 2000-11-22 16:41 To: Scott.Millington@edt.ericsson.se; ssm-interest@external.cisco.com Subject: RE: Use of SAP in a PIM SSM Network >>Ericsson has very little problem with multicast in Campus environmnets & LAN's...It is the WAN that "generates" all the problems (link speed, load on existing links, business critical traffic "at risk", and redundancy). Add to this that My division is responsible, but doesn't have control over different "islands" it also becomes a political mess. I hate to bring up an oft repeated argument: "How do you deal with this for unicast?" When peering between domains, every single issue you mention is both an issue for unicast and multicast. >>I have been kicking away for 2 years to try and motivate folks / organisations to open their eyes to the necessity of multicast. Until September there was very little interest. NOW everyone & their brother wants everything to work 6 months ago. Perhaps it is the globality of organisations that the Ericsson Global IT Services Provides for...Am I the only one with this dilemma?? Nope... and everyone is struggling. The solution seems to be to get these folks thinking the right way about multicast. >>SSM would be wonderful if we can get it up & running with support for different applications. Do you have content and applications lined up? >>I have an organisational question but it can easily be SSM / PIM-SM related. Is there anyone out there that has an application (Platform & Application independant) for the dynamic assignment of multicast addresses GGG.GGG.GGG.GGG:port where folks can book a randomized multicast group in the same way as one would book a conference room?? A bonus feature would be that this application could handle & mediate conflicts (someone "keeping" an assignment, or making their own assignments). Again, this is perception. Tell your folks if they feel like they are likely to see a conflict, they should go buy a lottery ticket. Same odds. -Kevin From J.Crowcroft@cs.ucl.ac.uk Thu Nov 23 06:13:05 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10096 for ; Thu, 23 Nov 2000 06:13:04 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id CAA10760 for ; Thu, 23 Nov 2000 02:07:03 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eANA6wl02280 for ; Thu, 23 Nov 2000 02:06:58 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with SMTP id CAA02484 for ; Thu, 23 Nov 2000 02:06:56 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Nov 2000 10:00:32 +0000 To: "Scott Millington (BCT)" cc: "'ssm-interest@external.cisco.com'" Subject: Re: Use of SAP in a PIM SSM Network In-reply-to: Your message of "Thu, 23 Nov 2000 10:06:19 +0100." <33C9100DDE98D211A16D0008C7A4E3FE0818F30A@esealnt103> Date: Thu, 23 Nov 2000 10:00:32 +0000 Message-ID: <8514.974973632@cs.ucl.ac.uk> From: Jon Crowcroft speakin of ericsson: i note that the 3G mobile access net stuff is not "multicast ready" given 3Gpp is basically packet and shared media, this seems sort of marginally criminal :-) given that there's LOADS of peope thinking that push technologies channel tech, event/alerting/notifying, based on context and proximity etc etc etc, it in fact seems bordering on the insane ommission in fact, its stretches my patience and credulity to breaking point, to quote the real inspector hound... In message <33C9100DDE98D211A16D0008C7A4E3FE0818F30A@esealnt103>, "Scott Millin gton (BCT)" typed: >>Doc, you is preachin to the choir ;) >> >>True...Unicast is the same (if not worse) but Multicast is new, = >>"non-traditional", and presently not viewed as production traffic. >> >>I mentioned before that I was getting folks motivated...well, when you = >>show a graph of travel costs (air stools, not counting time / hotel = >>etc) contra multicast costs - ripped off quite literally from an old = >>Motorola presentation - the effect on admin folks can be, um, pretty = >>impressive.=20 >> >>"Do you have content and applications lined up?" >>LOL . . . Which came first ;) >>I actually do have content...a whole organisation where the President = >>is interested in video conferencing "All Staff Meetings" globally. = >>Applications is actually the great motivator, since they appear to be = >>leaning towards Microsoft Media Server...MMS has the wonderful ability = >>to attempt different connectvity methods multicast-udp-tcp-http until = >>it gets contact. This means that simply not enabling multicast is no = >>longer an option. *insert gleeful "I bloody told you so" facial = >>expression here*. >> >>As for the lottery comparison...Who says logic has anthing to do with = >>corporate decisionmaking?? >> >>Cheers, >>Scott Millington >>Data Communications Architect >>+++++++++++++++++++++++++ >>Ericsson Global IT Services AB >>Corporate Network - Basic EriNet >>KI/BCT/I/ONF >>Kistag=E5ngen 4-4tr. >>125 82 Stockholm >>Telephone: +46-8-75 71667 >>Cellphone: +46-70-643 7897 >>Facsimile: +46-8-40 45550 >>EMAIL: scott.millington@edt.ericsson.se >>URL: work - http://www.ericsson.se >> home - http://haapis.zap.to >>+++++++++++++++++++++++++ >>"Friendship is the hardest thing in the world to=20 >>explain. It's not something you learn in school.=20 >>But if you haven't learned the meaning of=20 >>friendship, you reallyhaven't learned=20 >>anything." - Muhammad Ali =20 >> >> >> >>-----Original Message----- >>From: almeroth@cs.ucsb.edu [mailto:almeroth@cs.ucsb.edu] >>Sent: 2000-11-22 16:41 >>To: Scott.Millington@edt.ericsson.se; ssm-interest@external.cisco.com >>Subject: RE: Use of SAP in a PIM SSM Network >> >> >>>>Ericsson has very little problem with multicast in Campus = >>environmnets & LAN's...It is the WAN that "generates" all the problems = >>(link speed, load on existing links, business critical traffic "at = >>risk", and redundancy). Add to this that My division is responsible, = >>but doesn't have control over different "islands" it also becomes a = >>political mess. >> >>I hate to bring up an oft repeated argument: "How do you deal with >>this for unicast?" >> >>When peering between domains, every single issue you mention is >>both an issue for unicast and multicast. >> >>>>I have been kicking away for 2 years to try and motivate folks / = >>organisations to open their eyes to the necessity of multicast. Until = >>September there was very little interest. NOW everyone & their brother = >>wants everything to work 6 months ago. Perhaps it is the globality of = >>organisations that the Ericsson Global IT Services Provides for...Am I = >>the only one with this dilemma?? >> >>Nope... and everyone is struggling. The solution seems to be to >>get these folks thinking the right way about multicast. =20 >> >>>>SSM would be wonderful if we can get it up & running with support for = >>different applications. =20 >> >>Do you have content and applications lined up? >> >>>>I have an organisational question but it can easily be SSM / PIM-SM = >>related. Is there anyone out there that has an application (Platform & = >>Application independant) for the dynamic assignment of multicast = >>addresses GGG.GGG.GGG.GGG:port where folks can book a randomized = >>multicast group in the same way as one would book a conference room?? = >>A bonus feature would be that this application could handle & mediate = >>conflicts (someone "keeping" an assignment, or making their own = >>assignments). >> >>Again, this is perception. Tell your folks if they feel like they >>are likely to see a conflict, they should go buy a lottery ticket. >>Same odds. >> >>-Kevin cheers jon From Scott.Millington@edt.ericsson.se Thu Nov 23 06:17:33 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11887 for ; Thu, 23 Nov 2000 06:17:33 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id CAA12588 for ; Thu, 23 Nov 2000 02:13:37 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eANADfv03993 for ; Thu, 23 Nov 2000 02:13:41 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id CAA01619 for ; Thu, 23 Nov 2000 02:12:52 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id eANACmt23634 for ; Thu, 23 Nov 2000 11:12:48 +0100 (MET) Received: FROM esealnt444.al.sw.ericsson.se BY esealnt461 ; Thu Nov 23 11:12:18 2000 +0100 Received: by esealnt444 with Internet Mail Service (5.5.2651.58) id ; Thu, 23 Nov 2000 11:12:18 +0100 Message-ID: <33C9100DDE98D211A16D0008C7A4E3FE0818F30B@esealnt103> From: "Scott Millington (BCT)" To: "'ssm-interest@external.cisco.com'" Subject: RE: Use of SAP in a PIM SSM Network Date: Thu, 23 Nov 2000 11:12:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" *theme music*ERICSSON DEFENDER!!!*/theme music* I won't make any "warranty statements" but the IP base station address planning I did for Ericsson had a focus on just Multicast and reinforced the ipmortance of this service in the new world (IPv4 & IPv6). OTOH I was involved in the very preliminary work, so how it has developed since my involvement ceased is quite simply beyond me. There is (was) a 3G developers link on ericsson.com...and a search for 3g on the usenet should prove fruitful, but if you want me to do a little legwork (I'm on paternity leave) send me a private message. Scott -----Original Message----- From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk] Sent: 2000-11-23 11:01 To: Scott Millington (BCT) Cc: 'ssm-interest@external.cisco.com' Subject: Re: Use of SAP in a PIM SSM Network speakin of ericsson: i note that the 3G mobile access net stuff is not "multicast ready" given 3Gpp is basically packet and shared media, this seems sort of marginally criminal :-) given that there's LOADS of peope thinking that push technologies channel tech, event/alerting/notifying, based on context and proximity etc etc etc, it in fact seems bordering on the insane ommission in fact, its stretches my patience and credulity to breaking point, to quote the real inspector hound... In message <33C9100DDE98D211A16D0008C7A4E3FE0818F30A@esealnt103>, "Scott Millin gton (BCT)" typed: >>Doc, you is preachin to the choir ;) >> >>True...Unicast is the same (if not worse) but Multicast is new, = >>"non-traditional", and presently not viewed as production traffic. >> >>I mentioned before that I was getting folks motivated...well, when you = >>show a graph of travel costs (air stools, not counting time / hotel = >>etc) contra multicast costs - ripped off quite literally from an old = >>Motorola presentation - the effect on admin folks can be, um, pretty = >>impressive.=20 >> >>"Do you have content and applications lined up?" >>LOL . . . Which came first ;) >>I actually do have content...a whole organisation where the President = >>is interested in video conferencing "All Staff Meetings" globally. = >>Applications is actually the great motivator, since they appear to be = >>leaning towards Microsoft Media Server...MMS has the wonderful ability = >>to attempt different connectvity methods multicast-udp-tcp-http until = >>it gets contact. This means that simply not enabling multicast is no = >>longer an option. *insert gleeful "I bloody told you so" facial = >>expression here*. >> >>As for the lottery comparison...Who says logic has anthing to do with = >>corporate decisionmaking?? >> >>Cheers, >>Scott Millington >>Data Communications Architect >>+++++++++++++++++++++++++ >>Ericsson Global IT Services AB >>Corporate Network - Basic EriNet >>KI/BCT/I/ONF >>Kistag=E5ngen 4-4tr. >>125 82 Stockholm >>Telephone: +46-8-75 71667 >>Cellphone: +46-70-643 7897 >>Facsimile: +46-8-40 45550 >>EMAIL: scott.millington@edt.ericsson.se >>URL: work - http://www.ericsson.se >> home - http://haapis.zap.to >>+++++++++++++++++++++++++ >>"Friendship is the hardest thing in the world to=20 >>explain. It's not something you learn in school.=20 >>But if you haven't learned the meaning of=20 >>friendship, you reallyhaven't learned=20 >>anything." - Muhammad Ali =20 >> >> >> >>-----Original Message----- >>From: almeroth@cs.ucsb.edu [mailto:almeroth@cs.ucsb.edu] >>Sent: 2000-11-22 16:41 >>To: Scott.Millington@edt.ericsson.se; ssm-interest@external.cisco.com >>Subject: RE: Use of SAP in a PIM SSM Network >> >> >>>>Ericsson has very little problem with multicast in Campus = >>environmnets & LAN's...It is the WAN that "generates" all the problems = >>(link speed, load on existing links, business critical traffic "at = >>risk", and redundancy). Add to this that My division is responsible, = >>but doesn't have control over different "islands" it also becomes a = >>political mess. >> >>I hate to bring up an oft repeated argument: "How do you deal with >>this for unicast?" >> >>When peering between domains, every single issue you mention is >>both an issue for unicast and multicast. >> >>>>I have been kicking away for 2 years to try and motivate folks / = >>organisations to open their eyes to the necessity of multicast. Until = >>September there was very little interest. NOW everyone & their brother = >>wants everything to work 6 months ago. Perhaps it is the globality of = >>organisations that the Ericsson Global IT Services Provides for...Am I = >>the only one with this dilemma?? >> >>Nope... and everyone is struggling. The solution seems to be to >>get these folks thinking the right way about multicast. =20 >> >>>>SSM would be wonderful if we can get it up & running with support for = >>different applications. =20 >> >>Do you have content and applications lined up? >> >>>>I have an organisational question but it can easily be SSM / PIM-SM = >>related. Is there anyone out there that has an application (Platform & = >>Application independant) for the dynamic assignment of multicast = >>addresses GGG.GGG.GGG.GGG:port where folks can book a randomized = >>multicast group in the same way as one would book a conference room?? = >>A bonus feature would be that this application could handle & mediate = >>conflicts (someone "keeping" an assignment, or making their own = >>assignments). >> >>Again, this is perception. Tell your folks if they feel like they >>are likely to see a conflict, they should go buy a lottery ticket. >>Same odds. >> >>-Kevin cheers jon From danshterman@hotmail.com Thu Nov 23 12:53:56 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12748 for ; Thu, 23 Nov 2000 12:53:56 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA10084 for ; Thu, 23 Nov 2000 08:41:40 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eANGfd500916 for ; Thu, 23 Nov 2000 08:41:39 -0800 (PST) Received: from hotmail.com (f17.law11.hotmail.com [64.4.17.17]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id IAA22706 for ; Thu, 23 Nov 2000 08:41:37 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 23 Nov 2000 08:39:43 -0800 Received: from 192.114.177.229 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 23 Nov 2000 16:39:42 GMT X-Originating-IP: [192.114.177.229] From: "Dany Shterman" To: ssm-interest@external.cisco.com Subject: can ssm and non-ssm colide ? Date: Thu, 23 Nov 2000 16:39:42 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Nov 2000 16:39:43.0077 (UTC) FILETIME=[FB34B150:01C0556B] Hi. I understand that a router can have 2 types of multicast forwarding rules: 1. (S,D) : i.e do multicast to a packet that arrives with IP destination "d" and IP source "s" iff S=="s" and D=="d". 2. (*,D) : i.e do multicast to a packet that arrives with IP destination "d" iff D=="d". Questions: a. is it true ? b. is it possible that a router will have 2 contradicting forwarding rules : (S,D) and (*,D) that direct traffic to 2 different ports, for the same IP destination address D ? c. If the answer to the previous question is true, then to what port should the router forward ? ThankX. Dan _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From tme@21rst-century.com Thu Nov 23 14:46:53 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22601 for ; Thu, 23 Nov 2000 14:46:52 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA01227 for ; Thu, 23 Nov 2000 10:47:15 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eANIlJU19291 for ; Thu, 23 Nov 2000 10:47:19 -0800 (PST) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id KAA12599 for ; Thu, 23 Nov 2000 10:47:08 -0800 (PST) Received: from [216.8.13.252] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 570922; Thu, 23 Nov 2000 13:30:50 -0500 Message-ID: <3A1D6313.12CEAE8A@21rst-century.com> Date: Thu, 23 Nov 2000 13:33:55 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Dany Shterman CC: ssm-interest@external.cisco.com Subject: Re: can ssm and non-ssm colide ? (re-sent) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dany Shterman wrote: > > Hi. > I understand that a router can have 2 types of multicast forwarding rules: > > 1. (S,D) : i.e do multicast to a packet that arrives with IP destination > "d" and IP source "s" iff S=="s" and D=="d". 2. (*,D) : i.e do multicast to > a packet that arrives with IP destination "d" iff D=="d". > > Questions: > a. is it true ? > b. is it possible that a router will have 2 contradicting forwarding rules > : (S,D) and (*,D) that direct traffic to 2 different ports, for the same > IP destination address D ? > c. If the answer to the previous question is true, then to what port > should the router forward ? > > ThankX. > Dan > > _____________________________________________________________________________________ Sorry - this was sent too soon - here is the final Dear Dan; What exactly do you mean ? Is D the multicast class D address ? This is generally called "G", for the group. It is NOT a destination. Remember, SSM and ISM address ranges are supposed to be disjoint - (S,G) is allowed in a SSM range, but (*,G) is supposed to be filtered out. So this cannot occur in a proper SSM implementation. If you tried to do ISM in the SSM address space, it wouldn't work. In PIM-SM ISM, a (*,G) JOIN and an (S,G) join certainly could have different directions - generally, they would. It also is always possible to have the same data arriving at a router from two directions - this is also supposed to be detected and pruned.(SSM could have this too.) In general, these situations are supposed to be detected and pruned off as soon as possible. From http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-00.txt At the end of phase 2, traffic will be flowing natively from S along a source-specific tree to the RP, and from there along the shared tree to the receivers. Where the two trees intersect, traffic may transfer from the source-specific tree to the RP tree, and so avoid taking a long detour via the RP. and All of these problems are caused by there being more than one upstream router with join state for the group or source-group pair. PIM does not prevent such duplicate joins from occurring - instead when duplicate data packets appear on the LAN from different routers, these routers notice this, and then elect a single forwarder. This election is performed using PIM Assert messages, which resolve the problem in favor of the upstream router which has (S,G) state, or if neither or both router has (S,G) state, then in favor of the router with the best metric to the RP for RP trees, or the best metric to the source to source- specific trees. I BELIEVE that if there is both (S,G) and (*,G) forwarding state, that the (S,G) list is searched first and then the (*,G) is used only if there is no (S,G) match, but I cannot (as I wait for the turkey to cook) find any documentation that confirms this. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From tme@21rst-century.com Thu Nov 23 15:08:01 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22600 for ; Thu, 23 Nov 2000 14:46:52 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA18013 for ; Thu, 23 Nov 2000 10:30:19 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eANIUSm15829 for ; Thu, 23 Nov 2000 10:30:28 -0800 (PST) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id KAA00419 for ; Thu, 23 Nov 2000 10:30:14 -0800 (PST) Received: from [216.8.13.252] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 570919; Thu, 23 Nov 2000 13:10:17 -0500 Message-ID: <3A1D5E3F.4B2F10BE@21rst-century.com> Date: Thu, 23 Nov 2000 13:13:19 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Dany Shterman CC: ssm-interest@external.cisco.com Subject: Re: can ssm and non-ssm colide ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dany Shterman wrote: > > Hi. > I understand that a router can have 2 types of multicast forwarding rules: > > 1. (S,D) : i.e do multicast to a packet that arrives with IP destination > "d" and IP source "s" iff S=="s" and D=="d". 2. (*,D) : i.e do multicast to > a packet that arrives with IP destination "d" iff D=="d". > > Questions: > a. is it true ? > b. is it possible that a router will have 2 contradicting forwarding rules > : (S,D) and (*,D) that direct traffic to 2 different ports, for the same > IP destination address D ? > c. If the answer to the previous question is true, then to what port > should the router forward ? > > ThankX. > Dan > > _____________________________________________________________________________________ What exactly do you mean ? Is D the multicast class D address ? This is generally called "G", for the group. It is NOT a destination. Remember, SSM and ISM address ranges are supposed to be disjoint - (S,G) is allowed in a SSM range, but (*,G) is supposed to be filtered out. So this cannot occur in a proper SSM implementation. If you tried to do ISM in the SSM address space, it wouldn't work. In PIM-SM ISM, a (*,G) JOIN and an (S,G) join certainly could have different directions - generally, they would. You could, for instance, be sending encapsulated multicasts to the RP, and then having them multicasted back to a receiver on the same LAN as you, so that the same data flow along the pipe in both directions. From Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From mjh@hazard.aciri.org Thu Nov 23 16:24:36 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02730 for ; Thu, 23 Nov 2000 16:24:36 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA13128 for ; Thu, 23 Nov 2000 11:52:41 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eANJqaO04590 for ; Thu, 23 Nov 2000 11:52:36 -0800 (PST) Received: from hazard.aciri.org (adsl-63-196-11-252.dsl.snfc21.pacbell.net [63.196.11.252]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id LAA20939 for ; Thu, 23 Nov 2000 11:52:34 -0800 (PST) Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1]) by hazard.aciri.org (8.11.1/8.11.1) with ESMTP id eANJeUm15905; Thu, 23 Nov 2000 11:40:30 -0800 (PST) (envelope-from mjh@hazard.aciri.org) From: Mark Handley X-Organisation: ACIRI To: tme@21rst-century.com cc: Dany Shterman , ssm-interest@external.cisco.com Subject: Re: can ssm and non-ssm colide ? (re-sent) In-reply-to: Your message of "Thu, 23 Nov 2000 13:33:55 EST." <3A1D6313.12CEAE8A@21rst-century.com> Date: Thu, 23 Nov 2000 11:40:30 -0800 Message-ID: <15903.975008430@hazard.aciri.org> Sender: mjh@aciri.org >http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-00.txt > > At the end of phase 2, traffic will be flowing natively from S along a > source-specific tree to the RP, and from there along the shared tree to > the receivers. Where the two trees intersect, traffic may transfer from > the source-specific tree to the RP tree, and so avoid taking a long > detour via the RP. > >and > > All of these problems are caused by there being more than one upstream > router with join state for the group or source-group pair. PIM does not > prevent such duplicate joins from occurring - instead when duplicate > data packets appear on the LAN from different routers, these routers > notice this, and then elect a single forwarder. This election is > performed using PIM Assert messages, which resolve the problem in favor > of the upstream router which has (S,G) state, or if neither or both > router has (S,G) state, then in favor of the router with the best metric > to the RP for RP trees, or the best metric to the source to source- > specific trees. > > >I BELIEVE that if there is both (S,G) and (*,G) forwarding state, >that the (S,G) list is searched first and then the (*,G) is used only if >there is no (S,G) match, but I cannot (as I wait for the turkey to cook) >find any documentation that confirms this. It's in the "Data Packet Forwarding Rules" in Section 4.2. A couple of provisos modify what you said above: - if there's (S,G) state, then the packet will be forwarding using a combination of both (S,G) and (*,G) state if it arrived on the correct interface to have come from S. - if the packet arrived on the correct interface to have come from the RP (and not from S), then it will only be forwarded using purely (*,G) state if the SPTbit for (S,G) is false (indicating the the (S,G) forwarding state is not yet active). Cheers, Mark From jmulik@unix.temple.edu Thu Nov 23 16:48:02 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12409 for ; Thu, 23 Nov 2000 16:48:02 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA09536 for ; Thu, 23 Nov 2000 12:25:08 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eANKP7509036 for ; Thu, 23 Nov 2000 12:25:07 -0800 (PST) Received: from typhoon.ocis.temple.edu (typhoon.ocis.temple.edu [155.247.166.103]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id MAA22834 for ; Thu, 23 Nov 2000 12:24:27 -0800 (PST) Received: from localhost (jmulik@localhost) by typhoon.ocis.temple.edu (8.11.0/8.11.0) with ESMTP id eANKIfO08000 for ; Thu, 23 Nov 2000 15:18:41 -0500 (EST) Date: Thu, 23 Nov 2000 15:18:41 -0500 (EST) From: Jaiwant Mulik X-Sender: jmulik@typhoon.ocis.temple.edu To: ssm-interest@external.cisco.com Subject: Re: can ssm and non-ssm colide ? In-Reply-To: <3A1D5E3F.4B2F10BE@21rst-century.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, What again is ISM (I know SSM) ? bye, On Thu, 23 Nov 2000, Marshall Eubanks wrote: > Dany Shterman wrote: > > > > Hi. > > I understand that a router can have 2 types of multicast forwarding rules: > > > > 1. (S,D) : i.e do multicast to a packet that arrives with IP destination > > "d" and IP source "s" iff S=="s" and D=="d". 2. (*,D) : i.e do multicast to > > a packet that arrives with IP destination "d" iff D=="d". > > > > Questions: > > a. is it true ? > > b. is it possible that a router will have 2 contradicting forwarding rules > > : (S,D) and (*,D) that direct traffic to 2 different ports, for the same > > IP destination address D ? > > c. If the answer to the previous question is true, then to what port > > should the router forward ? > > > > ThankX. > > Dan > > > > _____________________________________________________________________________________ > > What exactly do you mean ? Is D the multicast class D address ? This > is generally called "G", for the group. It is NOT a destination. > > Remember, SSM and ISM address ranges are supposed to be disjoint - > (S,G) is allowed in a SSM range, but (*,G) is supposed to be > filtered out. So this cannot occur in a proper SSM implementation. If you > tried to do ISM in the SSM address space, it wouldn't work. > > In PIM-SM ISM, > a (*,G) JOIN and an (S,G) join certainly could have different directions - > generally, they would. You could, for instance, be sending > encapsulated multicasts to the RP, and then having them multicasted > back to a receiver on the same LAN as you, so that the same data flow > along the pipe in both directions. > > >From > > > Regards > Marshall Eubanks > > > Multicast Technologies, Inc. > 10301 Democracy Lane, Suite 201 > Fairfax, Virginia 22030 > Phone : 703-293-9624 Fax : 703-293-9609 > e-mail : tme@on-the-i.com http://www.on-the-i.com > Jaiwant Mulik ----------------------------------------------------------------------- Email : jmulik@unix.temple.edu (preferred), jmulik@acm.org Home page : http://unix.temple.edu/~jmulik Office hours : Mon: 10:30-12:30, Tue: 2:00-4:00, Wed: 2:40-4:40 Location : Room 1043/1044, Wachman Hall. Phones : (215) 204-3197 (o), (215) 777-4828 (r) ----------------------------------------------------------------------- Lekin woh zindagi he kya, jisme koi namumkin sapna na ho ? "Lets look at this from a logical point of view" - Prof. in class. From finlayson@live.com Thu Nov 23 20:58:31 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13833 for ; Thu, 23 Nov 2000 20:58:30 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id QAA11411 for ; Thu, 23 Nov 2000 16:33:15 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAO0XK819201 for ; Thu, 23 Nov 2000 16:33:20 -0800 (PST) Received: from ns.live.com (ns.live.com [208.184.148.162]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id QAA23335 for ; Thu, 23 Nov 2000 16:33:09 -0800 (PST) Received: from rsf-laptop.live.com (adsl-63-202-175-180.dsl.snfc21.pacbell.net [63.202.175.180]) by ns.live.com (8.9.3/8.9.3) with ESMTP id QAA03236; Thu, 23 Nov 2000 16:27:17 -0800 (PST) (envelope-from finlayson@live.com) Message-Id: <4.3.1.1.20001123161830.00b28f00@ns.live.com> X-Sender: rsf@ns.live.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 23 Nov 2000 16:26:44 -0800 To: Jaiwant Mulik From: Ross Finlayson Subject: Re: can ssm and non-ssm colide ? Cc: ssm-interest@external.cisco.com In-Reply-To: References: <3A1D5E3F.4B2F10BE@21rst-century.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:18 PM 11/23/00, Jaiwant Mulik wrote: >What again is ISM (I know SSM) ? The term "ISM" ("Internet Standard Multicast") describes the current IP multicast model, in which joins are done to multicast group addresses only, and packets are received regardless of the sender. By the way, I have to say that I dislike the term "ISM". It's misleading, because SSM is likely to also be a standard someday. Instead, I'd like to suggest the term "Source-Independent Multicast" ("SIM"). This is not only more descriptive, but also more contrasts better with "Source-Specific Multicast". Ross. From holbrook@cisco.com Fri Nov 24 07:41:18 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22875 for ; Fri, 24 Nov 2000 07:41:17 -0500 (EST) Received: from holbrook-dsl1.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id DAA12229; Fri, 24 Nov 2000 03:00:43 -0800 (PST) Received: by holbrook-dsl1.cisco.com (Postfix, from userid 500) id CA33BDB00F; Fri, 24 Nov 2000 03:03:35 -0800 (PST) From: Hugh Holbrook To: Ross Finlayson Cc: Jaiwant Mulik , ssm-interest@cisco.com In-reply-to: <4.3.1.1.20001123161830.00b28f00@ns.live.com> Subject: Re: Re: can ssm and non-ssm colide ? Reply-To: holbrook@cisco.com Message-Id: <20001124110335.CA33BDB00F@holbrook-dsl1.cisco.com> Date: Fri, 24 Nov 2000 03:03:35 -0800 (PST) > From: Ross Finlayson > > Instead, I'd like to suggest the term "Source-Independent Multicast" > ("SIM"). This is not only more descriptive, but also more contrasts better > with "Source-Specific Multicast". We used the term ISM in the first version of the SSM architecture document. Susequently, Brad and I both agreed that we didn't like it very much for the reasons you mention. We got a handful of consultations and then we switched to Any-Source Multicast (ASM) to describe the RFC1112 multicast model. I like SIM well enough, but ASM is pretty similar to SIM, to my thinking, and it appears now i draft-holbrook-ssm-arch-00.txt. I'm not inclined to change the name again unless there is strong sentiment to do so. Is there? -Hugh From eckert@cisco.com Fri Nov 24 13:34:34 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21636 for ; Fri, 24 Nov 2000 13:34:33 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA08606 for ; Fri, 24 Nov 2000 09:38:50 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA23384; Fri, 24 Nov 2000 09:37:43 -0800 (PST) From: Toerless Eckert Message-Id: <200011241737.JAA23384@cisco.com> Subject: Re: Use of SAP in a PIM SSM Network To: pusateri@juniper.net (Tom Pusateri) Date: Fri, 24 Nov 2000 09:37:42 -0800 (PST) Cc: tme@21rst-century.com, luby@digitalfountain.com (Mike Luby), almeroth@cs.ucsb.edu (Kevin C. Almeroth), Scott.Millington@edt.ericsson.se, ssm-interest@external.cisco.com, pusateri@juniper.net In-Reply-To: <200011230307.TAA99587@garnet.juniper.net> from "Tom Pusateri" at Nov 22, 2000 07:07:27 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Encouraging the use of static Class D addresses sets a bad precedent > and I don't think we should be encouraging this. The broadcasters > and content providers have static host names which can be > used for rendezvousing and the source address and group address should > be able to float as needed to meet demand. End users will not be > aware of the group address being used under most circumstances > anyway. Agreed. What i was thinking of as a possible operational improvement would be to have some operational SSM document in which to recommend a specific randomn number generator for selecting the SSM address to use, and have this generator be seeded by some combination of AS number and source ip address to be used for the channel, so that we gett less MAC-level ambiguities of the SSM groups being used. Would just need someone with more insight and time to come up with good recommendaations for this. I think if you could show just by some good simulation, that you could get collision rate at MAC layer down by a few factors over completely random assignment, then it would be good enough to have this for all practical purposes. Dunno how much one could practically achieve with this though... Cheers Toerless From luby@digitalfountain.com Fri Nov 24 14:35:59 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAB05484 for ; Fri, 24 Nov 2000 14:35:58 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA25072 for ; Fri, 24 Nov 2000 10:38:26 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAOIcPx24062 for ; Fri, 24 Nov 2000 10:38:25 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id KAA10614 for ; Fri, 24 Nov 2000 10:38:21 -0800 (PST) Received: from petersburg (adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id KAA13529; Fri, 24 Nov 2000 10:11:41 -0800 X-Authentication-Warning: mail.webfountain.com: Host adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195] claimed to be petersburg Reply-To: From: "Michael Luby" To: "Ross Finlayson" , "Jaiwant Mulik" Cc: Subject: RE: can ssm and non-ssm colide ? Date: Fri, 24 Nov 2000 10:16:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <4.3.1.1.20001123161830.00b28f00@ns.live.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Ross, I feel and have felt for some time the same way about the naming of ISM. It isn't symmetric with the naming of SSM, and does give the impression that one is a standard and the other is something else. I like your suggestion of calling the original model of multicast SIM instead of ISM, it seems to be the perfect name! Mike -----Original Message----- From: Ross Finlayson [mailto:finlayson@live.com] Sent: Thursday, November 23, 2000 4:27 PM To: Jaiwant Mulik Cc: ssm-interest@external.cisco.com Subject: Re: can ssm and non-ssm colide ? At 12:18 PM 11/23/00, Jaiwant Mulik wrote: >What again is ISM (I know SSM) ? The term "ISM" ("Internet Standard Multicast") describes the current IP multicast model, in which joins are done to multicast group addresses only, and packets are received regardless of the sender. By the way, I have to say that I dislike the term "ISM". It's misleading, because SSM is likely to also be a standard someday. Instead, I'd like to suggest the term "Source-Independent Multicast" ("SIM"). This is not only more descriptive, but also more contrasts better with "Source-Specific Multicast". Ross. From finlayson@live.com Fri Nov 24 19:23:55 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04864 for ; Fri, 24 Nov 2000 19:23:55 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id PAA07834 for ; Fri, 24 Nov 2000 15:25:33 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAONPWo06895 for ; Fri, 24 Nov 2000 15:25:32 -0800 (PST) Received: from ns.live.com (ns.live.com [208.184.148.162]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id PAA14628 for ; Fri, 24 Nov 2000 15:24:52 -0800 (PST) Received: from rsf-laptop.live.com (dhcp2.danastreet.live.com [208.185.235.156]) by ns.live.com (8.9.3/8.9.3) with ESMTP id PAA48691 for ; Fri, 24 Nov 2000 15:19:16 -0800 (PST) (envelope-from finlayson@live.com) Message-Id: <4.3.1.1.20001124151445.00b41e60@ns.live.com> X-Sender: rsf@ns.live.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 24 Nov 2000 15:14:49 -0800 To: ssm-interest@external.cisco.com From: Ross Finlayson Subject: A better name than ISM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:32 PM 11/24/00, Hugh Holbrook wrote: >I agree. I think we should raise this issue at maddogs. It feels >kind of like a nit, but I think naming is really important -- bad >names can cause SO much confusion... OK, there seems to be consensus that "Internet Standard Multicast"/ISM is not the best name/acronym for the current multicast model. As for an alternative - IMHO, either "Any-Source Multicast"/ASM or "Source-Independent Multicast"/SIM would be better. Personally, I prefer "SIM" for (as Mike noted) its symmetry with SSM (given that SSM stands for "Source-Specific Multicast", *not* "Single-Source Multicast".) If this stuff takes off, these acronyms could end up being widely learned and used by students, engineers, trade rags, so I agree with Hugh that having a clear, non-confusing name/acronym is important. (For example, think about how many people have already confused the acronyms RTCP and RTSP.) Ross. From porce@kaist.ac.kr Fri Nov 24 20:42:45 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15526 for ; Fri, 24 Nov 2000 20:42:44 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA18166 for ; Fri, 24 Nov 2000 16:29:02 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAP0T1v14136 for ; Fri, 24 Nov 2000 16:29:02 -0800 (PST) Received: from m018.com ([210.112.10.141]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id QAA20709 for ; Fri, 24 Nov 2000 16:28:17 -0800 (PST) Received: from ns ([210.112.7.7]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 25 Nov 2000 09:21:03 +0900 Message-ID: <001501c05676$2a40e6c0$d012060a@hansol.co.kr> From: "Lee, Jiwoong" To: , "Ross Finlayson" , "Jaiwant Mulik" Cc: References: Subject: Re: can ssm and non-ssm colide ? Date: Sat, 25 Nov 2000 09:25:07 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Good points. Well-categorized names will be good. BTW ISM(or whatever) and SSM belong to explicit multicast and explicit multicast is just one (efficient) way to realize multicast. Therefore, number of soure might not be a good discriminant in a wide view. The name ISM surely is misleadeing. "Generic multicast" was a my alternative to call *ISM*, though I don't recommend to use it. Jiwoong ----- Original Message ----- From: "Michael Luby" To: "Ross Finlayson" ; "Jaiwant Mulik" Cc: Sent: Saturday, November 25, 2000 3:16 AM Subject: RE: can ssm and non-ssm colide ? > Ross, > I feel and have felt for some time the same way about the naming of ISM. It > isn't symmetric with the naming of SSM, and does give the impression that > one is a standard and the other is something else. I like your suggestion > of calling the original model of multicast SIM instead of ISM, it seems to > be the perfect name! > Mike > > -----Original Message----- > From: Ross Finlayson [mailto:finlayson@live.com] > Sent: Thursday, November 23, 2000 4:27 PM > To: Jaiwant Mulik > Cc: ssm-interest@external.cisco.com > Subject: Re: can ssm and non-ssm colide ? > > > At 12:18 PM 11/23/00, Jaiwant Mulik wrote: > >What again is ISM (I know SSM) ? > > The term "ISM" ("Internet Standard Multicast") describes the current IP > multicast model, in which joins are done to multicast group addresses only, > and packets are received regardless of the sender. > > By the way, I have to say that I dislike the term "ISM". It's misleading, > because SSM is likely to also be a standard someday. > > Instead, I'd like to suggest the term "Source-Independent Multicast" > ("SIM"). This is not only more descriptive, but also more contrasts better > with "Source-Specific Multicast". > > Ross. > > > From mjh@hazard.aciri.org Fri Nov 24 21:23:17 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23619 for ; Fri, 24 Nov 2000 21:23:16 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA25075 for ; Fri, 24 Nov 2000 17:23:12 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAP1NBF19709 for ; Fri, 24 Nov 2000 17:23:11 -0800 (PST) Received: from hazard.aciri.org (adsl-63-196-11-252.dsl.snfc21.pacbell.net [63.196.11.252]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id RAA00286 for ; Fri, 24 Nov 2000 17:23:10 -0800 (PST) Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1]) by hazard.aciri.org (8.11.1/8.11.1) with ESMTP id eAP1D6m26249; Fri, 24 Nov 2000 17:13:06 -0800 (PST) (envelope-from mjh@hazard.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Ross Finlayson cc: ssm-interest@external.cisco.com Subject: Re: A better name than ISM In-reply-to: Your message of "Fri, 24 Nov 2000 15:14:49 PST." <4.3.1.1.20001124151445.00b41e60@ns.live.com> Date: Fri, 24 Nov 2000 17:13:06 -0800 Message-ID: <26247.975114786@hazard.aciri.org> Sender: mjh@aciri.org >At 12:32 PM 11/24/00, Hugh Holbrook wrote: >>I agree. I think we should raise this issue at maddogs. It feels >>kind of like a nit, but I think naming is really important -- bad >>names can cause SO much confusion... > >OK, there seems to be consensus that "Internet Standard Multicast"/ISM is >not the best name/acronym for the current multicast model. As for an >alternative - IMHO, either "Any-Source Multicast"/ASM or >"Source-Independent Multicast"/SIM would be better. Personally, I prefer >"SIM" for (as Mike noted) its symmetry with SSM (given that SSM stands for >"Source-Specific Multicast", *not* "Single-Source Multicast".) SIM is a rather overloaded abbreviation, and ASM implies the receivers have no control over which sources they listen to, which is no longer true with IGMPv3. The key difference is that in SSM receivers join a source/channel, whereas in ISM they join a group (or group of sources). The ideal name would probably be Group-Specific Multicast, but that acronym is taken. Source-Group Multicast would work too, but (informally at least) that acronym is also taken. How about Group-Addressed Multicast (GAM), Internet Group Multicast (IGM) or just Group Multicast (GM)? Cheers, Mark From eckert@cisco.com Sat Nov 25 01:52:05 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14815 for ; Sat, 25 Nov 2000 01:52:04 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id VAA09371 for ; Fri, 24 Nov 2000 21:23:01 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA14880; Fri, 24 Nov 2000 21:22:24 -0800 (PST) From: Toerless Eckert Message-Id: <200011250522.VAA14880@cisco.com> Subject: Re: A better name than ISM To: mjh@aciri.org (Mark Handley) Date: Fri, 24 Nov 2000 21:22:24 -0800 (PST) Cc: finlayson@live.com (Ross Finlayson), ssm-interest@external.cisco.com In-Reply-To: <26247.975114786@hazard.aciri.org> from "Mark Handley" at Nov 24, 2000 05:13:06 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The key difference is that in SSM receivers join a source/channel, > whereas in ISM they join a group (or group of sources). The ideal > name would probably be Group-Specific Multicast, but that acronym is > taken. Source-Group Multicast would work too, but (informally at > least) that acronym is also taken. How about Group-Addressed > Multicast (GAM), Internet Group Multicast (IGM) or just Group > Multicast (GM)? I think the original term used in rfc1112 is "Host Group Multicast", which would abbrviate to HGM. Cheers Toerless From adsearch2@unbounded.com Sat Nov 25 09:09:18 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20203 for ; Sat, 25 Nov 2000 09:09:17 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id EAA25035 for ; Sat, 25 Nov 2000 04:59:24 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAPCxIn13860 for ; Sat, 25 Nov 2000 04:59:18 -0800 (PST) Received: from enduser (ts001d04.sun-fl.concentric.net [206.173.69.16]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with SMTP id EAA03844 for ; Sat, 25 Nov 2000 04:59:12 -0800 (PST) Message-Id: <200011251259.EAA03844@proxy1.cisco.com> From: "Purchasing" To: "http://www.ietf.org/html.charters/ssm-charter.html" Subject: Your advertising rates Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 25 Nov 2000 07:57:05 Hello ssm-interest@external.cisco.com, We saw you listed at http://www.ietf.org/html.charters/ssm-charter.html. We would appreciate you letting us know if you accept advertising on your website and your rates. Any information you could supply about your traffic and demographics would be helpful as well. You can email us your proposal at: inquire6@freeautobot.com You are also invited to place your link on our site for free at: http://63.82.144.35/inquire6/index.html If you are not accepting advertising at this time we would appreciate you forwarding this email to anyone you know who has a high traffic website which accepts paid advertising Thank you for your consideration. If you have no interest in ever accepting advertising please just click this link then click send. mailto:removeadinquire@mail.ru?Subject=remove ########################################################### Please report any internet abuse to: abusealert@hongkong.com From tme@21rst-century.com Sat Nov 25 11:32:29 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27618 for ; Sat, 25 Nov 2000 11:32:29 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA16800 for ; Sat, 25 Nov 2000 07:22:48 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAPFMlK23773 for ; Sat, 25 Nov 2000 07:22:47 -0800 (PST) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id HAA13518 for ; Sat, 25 Nov 2000 07:22:43 -0800 (PST) Received: from [216.8.13.239] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 571179; Sat, 25 Nov 2000 10:15:57 -0500 Message-ID: <3A1FD87B.6F8266D6@21rst-century.com> Date: Sat, 25 Nov 2000 10:19:22 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Toerless Eckert CC: Mark Handley , Ross Finlayson , ssm-interest@external.cisco.com Subject: Re: A better name than ISM References: <200011250522.VAA14880@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Toerless Eckert wrote: > > > The key difference is that in SSM receivers join a source/channel, > > whereas in ISM they join a group (or group of sources). The ideal > > name would probably be Group-Specific Multicast, but that acronym is > > taken. Source-Group Multicast would work too, but (informally at > > least) that acronym is also taken. How about Group-Addressed > > Multicast (GAM), Internet Group Multicast (IGM) or just Group > > Multicast (GM)? > > I think the original term used in rfc1112 is "Host Group Multicast", > which would abbrviate to HGM. > > Cheers > Toerless For what it's worth, none of the new choices mentioned on the list seem significantly better than ISM to me. If there was going to be a change (again), I would suggest GSM (any possible three letter choice is undoubtedly "taken" by some project somewhere...). There is something to be said for "net-masking" for humans - having two related acronyms be similar, but disjoint at the beginning or the end (SSM vs ISM or SSM vs GSM, say), helps the reader to remember both better. If, like GSM, the phrases behind the acronyms are also parallel, so much the better. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From tme@21rst-century.com Sat Nov 25 12:13:07 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06651 for ; Sat, 25 Nov 2000 12:13:07 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA08095 for ; Sat, 25 Nov 2000 08:17:46 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAPGHj828092 for ; Sat, 25 Nov 2000 08:17:45 -0800 (PST) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id IAA18168 for ; Sat, 25 Nov 2000 08:17:40 -0800 (PST) Received: from [216.8.13.239] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 571180; Sat, 25 Nov 2000 10:54:39 -0500 Message-ID: <3A1FE188.7BB9B54D@21rst-century.com> Date: Sat, 25 Nov 2000 10:57:59 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Toerless Eckert CC: Tom Pusateri , Mike Luby , "Kevin C. Almeroth" , Scott.Millington@edt.ericsson.se, ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network References: <200011241737.JAA23384@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Toerless Eckert wrote: > > > Encouraging the use of static Class D addresses sets a bad precedent > > and I don't think we should be encouraging this. The broadcasters > > and content providers have static host names which can be > > used for rendezvousing and the source address and group address should > > be able to float as needed to meet demand. End users will not be > > aware of the group address being used under most circumstances > > anyway. > > Agreed. What i was thinking of as a possible operational improvement would > be to have some operational SSM document in which to recommend a specific > randomn number generator for selecting the SSM address to use, and have this > generator be seeded by some combination of AS number and source ip address > to be used for the channel, so that we gett less MAC-level ambiguities of > the SSM groups being used. > > Would just need someone with more insight and time to come up with good > recommendaations for this. I think if you could show just by some good > simulation, that you could get collision rate at MAC layer down by a few > factors over completely random assignment, then it would be good enough > to have this for all practical purposes. > > Dunno how much one could practically achieve with this though... > > Cheers > Toerless SSM in intended for (or, is at least, ideal for) BROADCASTING. In the real world, broadcasters stay up for years at a time. They don't like down time, even for seconds. They will NEVER want to renumber their class D addresses - these will get embedded in too many places (including .pls type files at the receivers) to make any such transition smooth. If there is a MAC layer collision, for any reason, they will want a fast means of resolving it. Now, I am sorry, but this sounds awful much like a static address to me. SSM is very attractive for broadcasters. Please do not hinder it by insisting on some theoretical purity that does not fit their business model. Marshall Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From pusateri@juniper.net Sat Nov 25 12:44:54 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13672 for ; Sat, 25 Nov 2000 12:44:53 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA17408 for ; Sat, 25 Nov 2000 08:36:43 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAPGalC22039 for ; Sat, 25 Nov 2000 08:36:47 -0800 (PST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id IAA19790 for ; Sat, 25 Nov 2000 08:36:33 -0800 (PST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA09783; Sat, 25 Nov 2000 08:30:45 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id IAA43233; Sat, 25 Nov 2000 08:30:44 -0800 (PST) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200011251630.IAA43233@garnet.juniper.net> To: tme@21rst-century.com cc: Toerless Eckert , Tom Pusateri , Mike Luby , "Kevin C. Almeroth" , Scott.Millington@edt.ericsson.se, ssm-interest@external.cisco.com, pusateri@juniper.net Subject: Re: Use of SAP in a PIM SSM Network In-Reply-To: Message from Marshall Eubanks of "Sat, 25 Nov 2000 10:57:59 EST." <3A1FE188.7BB9B54D@21rst-century.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43230.975169844.1@garnet.juniper.net> Date: Sat, 25 Nov 2000 08:30:44 -0800 From: Tom Pusateri In message <3A1FE188.7BB9B54D@21rst-century.com> you write: > >SSM in intended for (or, is at least, ideal for) BROADCASTING. >In the real world, broadcasters >stay up for years at a time. They don't like down time, even for seconds. >They will NEVER want to renumber their class D addresses - these will >get embedded in too many places (including .pls type files at the receivers) >to make any such transition smooth. >If there is a MAC layer collision, for any reason, they will want a fast >means of resolving it. Now, I am sorry, >but this sounds awful much like a static address to me. The whole point is this should be left up to the source to determine how to allocate group addresses. If your SSM source wants to assign static addresses, that is a local decision. But I would make a few points known upfront to your clients: 1. Others SSM sources will likely use the same group addresses and they must be prepared to deal with this. 2. Unused group addresses will be reclaimed. In fact, I would encourage a group address lease which they can renew at regular intervals. Thanks, Tom From sob@newdev.harvard.edu Sat Nov 25 12:54:29 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15720 for ; Sat, 25 Nov 2000 12:54:23 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA26819 for ; Sat, 25 Nov 2000 08:57:05 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eAPGv5p01594 for ; Sat, 25 Nov 2000 08:57:05 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id IAA02336 for ; Sat, 25 Nov 2000 08:57:01 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id LAA00421 for ssm-interest@external.cisco.com; Sat, 25 Nov 2000 11:33:59 -0500 (EST) Date: Sat, 25 Nov 2000 11:33:59 -0500 (EST) From: Scott Bradner Message-Id: <200011251633.LAA00421@newdev.harvard.edu> To: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network Marshall sez: > If there is a MAC layer collision, for any reason, they will want a fast > means of resolving it. I guess I'm confused - the Ethernet (for example) drivers I've seen do not assume that the multicast packet they just got is actually for them - they check and discard the ones that are not so I do not see what the problem is Scott (in fact many Ethernet adapters do not know how to check for a specifc multicast address - they hash teh address into some number of bins (e.g. 64) and if a flag for that bin is on they accept the packet ) From luby@digitalfountain.com Sat Nov 25 15:08:31 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25901 for ; Sat, 25 Nov 2000 15:08:30 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA10911 for ; Sat, 25 Nov 2000 11:15:29 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAPJFSn25171 for ; Sat, 25 Nov 2000 11:15:28 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id LAA04669 for ; Sat, 25 Nov 2000 11:14:47 -0800 (PST) Received: from petersburg (adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id KAA01582; Sat, 25 Nov 2000 10:45:04 -0800 X-Authentication-Warning: mail.webfountain.com: Host adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195] claimed to be petersburg Reply-To: From: "Michael Luby" To: , "Toerless Eckert" Cc: "Tom Pusateri" , "Kevin C. Almeroth" , , , "Michael Luby" Subject: RE: Use of SAP in a PIM SSM Network Date: Sat, 25 Nov 2000 10:49:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A1FE188.7BB9B54D@21rst-century.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit > SSM in intended for (or, is at least, ideal for) BROADCASTING. > In the real world, broadcasters > stay up for years at a time. They don't like down time, even for seconds. > They will NEVER want to renumber their class D addresses - these will > get embedded in too many places (including .pls type files at the receivers) > to make any such transition smooth. > If there is a MAC layer collision, for any reason, they will want a fast > means of resolving it. Now, I am sorry, > but this sounds awful much like a static address to me. > SSM is very attractive for broadcasters. Please do not hinder it by insisting > on some theoretical purity that does not fit their business model. > > > Marshall I'm still a little confused about why it is such a big deal for collisions to be happening. First off, aren't the collisions only going to occur at the edge of the network on some local shared LAN? Aren't all the router and switches in the middle smart enough to understand the channel address (S,G) and not the hashed MAC address of this and thus will only care if the pair (S,G) is unique? Aren't clients only going to receive the packets they have asked for unless they are on a shared LAN (in which case they should filter them out)? Maybe some networking expert could explain exactly where the problem could occur of colliding at the MAC level, and how many end users in the Internet today and in the future are likely to be susceptible to such a problem? This would be very enlightening to me, as then I would understand the full scope of the issue and the pros and cons on both sides. I'd also like to point out that anybody who is deploying commercial grade applications will obviously have an application level filter to make sure that they are receiving the correct packets and make sure to throw out packets that weren't requested, and not just rely on the networking infrastructure to deliver requested packets. This is certainly something we do. This at least solves the problem of accepting bad packets, but still there is the wasted bandwidth issue that this doesn't deal with (wasted by pulling in unintended packets). On the last point you made Marshall, one of the main attractions of SSM to really large commercial broadcasters is that it frees them up from using the same multicast address allocation that they have today in the 233 space. If multicast is really successful, large broadcasters won't be using just a couple of hundred multicast groups, but thousands and tens of thousands. Thus, the old scheme of using AS numbers etc. is exactly one of the things broadcasters (at least the ones we've talked with) have to get away from, because they are already out of multicast addresses to use. This style of static allocation restricts them to do no more than what they are doing today, and this does not bode well for the commercial deployment of SSM if this becomes the model. Thus, whatever we can do to make it the case that SSM means (S,G) packets get delivered to a client based on the full channel name is really going to help commercial deployment. One last point Marshall, with SSM wouldn't it be the pair (S,G) that the broadcasters should be embedding in all those places, not just the group address G? Maybe you can explain this more (about where these multicast addresses would be embedded by the commercial broadcasters and why) to have a more cogent understanding. Mike From fenner@research.att.com Sat Nov 25 15:13:05 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27331 for ; Sat, 25 Nov 2000 15:13:04 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA04098 for ; Sat, 25 Nov 2000 11:11:18 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAPJBNm09306 for ; Sat, 25 Nov 2000 11:11:23 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id LAA04383 for ; Sat, 25 Nov 2000 11:10:31 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id B10914CE0B; Sat, 25 Nov 2000 14:05:56 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA04330; Sat, 25 Nov 2000 14:05:56 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA19284; Sat, 25 Nov 2000 11:05:55 -0800 (PST) Message-Id: <200011251905.LAA19284@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: sob@harvard.edu Subject: Re: Use of SAP in a PIM SSM Network Cc: ssm-interest@external.cisco.com Date: Sat, 25 Nov 2000 11:05:55 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a From my hallway discussions about MAC-layer collisions, I think the fear is that the light switch will join the ALL-LIGHT-SWITCHES group, and if that happens to collide at the MAC layer with a 25Mbps video stream the light switch's CPU will be too busy dropping traffic to turn the light on. Only a layer 3 device could save the light switch, since a layer 2 device (even an IGMP-snooping one) can still only filter on the MAC address. Bill From mjh@hazard.aciri.org Sat Nov 25 16:16:05 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12219 for ; Sat, 25 Nov 2000 16:16:04 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA09855 for ; Sat, 25 Nov 2000 12:09:56 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAPKA0315235 for ; Sat, 25 Nov 2000 12:10:00 -0800 (PST) Received: from hazard.aciri.org (adsl-63-196-11-252.dsl.snfc21.pacbell.net [63.196.11.252]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id MAA06489 for ; Sat, 25 Nov 2000 12:09:46 -0800 (PST) Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1]) by hazard.aciri.org (8.11.1/8.11.1) with ESMTP id eAPJwYm36855; Sat, 25 Nov 2000 11:58:34 -0800 (PST) (envelope-from mjh@hazard.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Bill Fenner cc: sob@harvard.edu, ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network In-reply-to: Your message of "Sat, 25 Nov 2000 11:05:55 PST." <200011251905.LAA19284@windsor.research.att.com> Date: Sat, 25 Nov 2000 11:58:34 -0800 Message-ID: <36853.975182314@hazard.aciri.org> Sender: mjh@aciri.org >>From my hallway discussions about MAC-layer collisions, I think the fear >is that the light switch will join the ALL-LIGHT-SWITCHES group, and if >that happens to collide at the MAC layer with a 25Mbps video stream the >light switch's CPU will be too busy dropping traffic to turn the light on. >Only a layer 3 device could save the light switch, since a layer 2 device >(even an IGMP-snooping one) can still only filter on the MAC address. In almost all cases, having IP-aware NICs seems to be a bad thing in the long run. This might just be one of those rare cases when it isn't. If multicast ever becomes common enough for this to be a real problem, I'd think this would be a point on which products can differentiate themselves. Cheers, Mark From smirnow@fokus.gmd.de Sat Nov 25 19:07:27 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10171 for ; Sat, 25 Nov 2000 19:07:27 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA03775 for ; Sat, 25 Nov 2000 15:01:27 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAPN1Rv11274 for ; Sat, 25 Nov 2000 15:01:27 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id PAA26900 for ; Sat, 25 Nov 2000 15:01:25 -0800 (PST) Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id XAA14475 for ; Sat, 25 Nov 2000 23:44:35 +0100 (MET) Received: (from mis@localhost) by dumbo.fokus.gmd.de (8.8.8/8.8.8) id XAA28863 for ssm-interest@external.cisco.com; Sat, 25 Nov 2000 23:44:26 +0100 (MET) Date: Sat, 25 Nov 2000 23:44:26 +0100 (MET) From: Michael Smirnov Message-Id: <200011252244.XAA28863@dumbo.fokus.gmd.de> To: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network X-Sun-Charset: US-ASCII Hi, SIM, ASM, GSM, HGM,... sound to me like an attempt to hoard what has been open before, however I understand that with SSM there is such a need. It's also fine with me when people refer to rfc1112 as "native multicast" cheers Michael From J.Crowcroft@cs.ucl.ac.uk Sun Nov 26 11:42:18 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20660 for ; Sun, 26 Nov 2000 11:42:17 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA29844 for ; Sun, 26 Nov 2000 07:27:43 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAQFRhB15444 for ; Sun, 26 Nov 2000 07:27:43 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with SMTP id HAA14833 for ; Sun, 26 Nov 2000 07:26:59 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 26 Nov 2000 15:21:22 +0000 To: Mark Handley cc: ssm-interest@external.cisco.com, J.Crowcroft@cs.ucl.ac.uk Subject: Re: A better name than ISM In-reply-to: Your message of "Fri, 24 Nov 2000 17:13:06 PST." <26247.975114786@hazard.aciri.org> Date: Sun, 26 Nov 2000 15:21:22 +0000 Message-ID: <3606.975252082@cs.ucl.ac.uk> From: Jon Crowcroft right - ssm is not multicast. its really a very big departure from the entire IP world - the difference between unicast and deering's multicast at the fundamental service level was very thin - anyone can send to either, and anyone can receive what is sent to them, or choose not -the rest was address allocation and routing the channel model in SSM explicitly creates an association from address allocation, source, and receiver set that is much less flexible (although as everyone keeps saying, appears to cover the majroity of the _current_ "compelling", or as i prefer, fashionable applications:-) i'd prefer we change the name of SSM back to channel In message <26247.975114786@hazard.aciri.org>, Mark Handley typed: >> >>>At 12:32 PM 11/24/00, Hugh Holbrook wrote: >>>>I agree. I think we should raise this issue at maddogs. It feels >>>>kind of like a nit, but I think naming is really important -- bad >>>>names can cause SO much confusion... >>> >>>OK, there seems to be consensus that "Internet Standard Multicast"/ISM is >>>not the best name/acronym for the current multicast model. As for an >>>alternative - IMHO, either "Any-Source Multicast"/ASM or >>>"Source-Independent Multicast"/SIM would be better. Personally, I prefer >>>"SIM" for (as Mike noted) its symmetry with SSM (given that SSM stands for >>>"Source-Specific Multicast", *not* "Single-Source Multicast".) >> >>SIM is a rather overloaded abbreviation, and ASM implies the receivers >>have no control over which sources they listen to, which is no longer >>true with IGMPv3. >> >>The key difference is that in SSM receivers join a source/channel, >>whereas in ISM they join a group (or group of sources). The ideal >>name would probably be Group-Specific Multicast, but that acronym is >>taken. Source-Group Multicast would work too, but (informally at >>least) that acronym is also taken. How about Group-Addressed >>Multicast (GAM), Internet Group Multicast (IGM) or just Group >>Multicast (GM)? >> >>Cheers, >> Mark >> >> cheers jon From tme@21rst-century.com Sun Nov 26 13:45:48 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03866 for ; Sun, 26 Nov 2000 13:45:42 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA10860 for ; Sun, 26 Nov 2000 09:36:20 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAQHaE325923 for ; Sun, 26 Nov 2000 09:36:14 -0800 (PST) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id JAA24686 for ; Sun, 26 Nov 2000 09:35:31 -0800 (PST) Received: from [216.8.6.8] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 571308; Sun, 26 Nov 2000 12:14:43 -0500 Message-ID: <3A2145DD.BB4800D@21rst-century.com> Date: Sun, 26 Nov 2000 12:18:21 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: luby@digitalfountain.com CC: Toerless Eckert , Tom Pusateri , "Kevin C. Almeroth" , Scott.Millington@edt.ericsson.se, ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Luby wrote: > > > I'm still a little confused about why it is such a big deal for collisions > to be happening. First off, aren't the collisions only going to occur at > the edge of the network on some local shared LAN? Aren't all the router and > switches in the middle smart enough to understand the channel address (S,G) > and not the hashed MAC address of this and thus will only care if the pair > (S,G) is unique? Aren't clients only going to receive the packets they have > asked for unless they are on a shared LAN (in which case they should filter > them out)? Maybe some networking expert could explain exactly where the > problem could occur of colliding at the MAC level, and how many end users in > the Internet today and in the future are likely to be susceptible to such a Dear Mike; Sorry for being so wordy about this, but... You are correct, collisions only will happen at the edge of the network. Don't forget, though, that ALL of the audience is at the edge of the network :) Our surveys indicate that the current audience "passed" by broadband multicasts is (conservatively) on the order of 1 to 2 million people. Of these, almost all are on LANs. Most DSL providers have problems with multicasting, due to under-provisioning between the last-hop router and the DSLAM; while many ISDN users can get multicasts, this is clearly not the future of broadband. If there are any reports of Cable Modem providers supporting multicasting, I would love to hear of it. Pretty much everyone else with broadband is on a LAN of some sort, generally some flavor of Ethernet, and a subset of these people is the early audience for multicasting. Even as broadband gets into people's houses, you won't have a separate line for each computer / device in the house - you'll have one hub / router that talks to the line, and a LAN (maybe wireless) that hooks everything else together. Basically everyone I know who has broadband (DSL/ISDN/Cable Modem, etc.) does something like this already. This indicates that collision problems will not go away. > problem? This would be very enlightening to me, as then I would understand > the full scope of the issue and the pros and cons on both sides. I'd also > like to point out that anybody who is deploying commercial grade > applications will obviously have an application level filter to make sure > that they are receiving the correct packets and make sure to throw out > packets that weren't requested, and not just rely on the networking Of course, layer 3 will filter this. However, if you are getting colliding video streams, at the least your performance will suffer. This may prove to never be a problem - but if it does, it would be wise to have a mechanism in place to say who has to change their G address. > infrastructure to deliver requested packets. This is certainly something we > do. This at least solves the problem of accepting bad packets, but still > there is the wasted bandwidth issue that this doesn't deal with (wasted by > pulling in unintended packets). > > On the last point you made Marshall, one of the main attractions of SSM to > really large commercial broadcasters is that it frees them up from using the > same multicast address allocation that they have today in the 233 space. If > multicast is really successful, large broadcasters won't be using just a > couple of hundred multicast groups, but thousands and tens of thousands. > Thus, the old scheme of using AS numbers etc. is exactly one of the things Sure. And there is plenty of room - we have a /4 for multicasting, after all, and 23 non-colliding bits of address space (some 8 million choices)... The trouble is, we (multicast-tech) want to start SSM broadcasts NEXT MONTH. True, they'll be tests, but once they go up, we don't ever plan to take them down. So, IMHO, there needs to be two things : - Some means of picking SSM addresses immediately. "Do what thou wilt" seems to be whole of the current law - so we will pick from our (translated) "GLOP" space. If there is something better for the short term, it needs to be presented (at least) in San Diego. - Some means of getting non-colliding addresses assigned, whether static or not. There are plenty of such addresses - and I agree that GLOP is not an efficient means of doing so. Maybe the way to go is : 1.) Make some range of Class D addresses is available without warranty. You just pick them and use them - if you suffer collisions, that's your problem. These won't collide with #'s 1 and 2, but can collide with each other. 2.) Some small "GLOP type" address range is available on a reserved basis without any paperwork at all. 3.) Once you use this up (or come close), you can then justify getting a larger range from a different pool of addresses. This begins to sound (to me) a lot like what ARIN does. Maybe I'm just being a worry-wart here, but I worry that once people start obtaining revenues of a million dollars a minute from an SSM broadcast (not out of line for a major network, BTW), they will become VERY, VERY intolerant of anything that might interfere with their stream. Maybe the REAL long term solution is to buy a shorter MAC prefix for multicasting, so that collisions do not occur. > broadcasters (at least the ones we've talked with) have to get away from, > because they are already out of multicast addresses to use. This style of > static allocation restricts them to do no more than what they are doing > today, and this does not bode well for the commercial deployment of SSM if > this becomes the model. Thus, whatever we can do to make it the case that > SSM means (S,G) packets get delivered to a client based on the full channel > name is really going to help commercial deployment. > > One last point Marshall, with SSM wouldn't it be the pair (S,G) that the > broadcasters should be embedding in all those places, not just the group > address G? Maybe you can explain this more (about where these multicast > addresses would be embedded by the commercial broadcasters and why) to have > a more cogent understanding. Sure. Most of the Internet broadcasters that I am familiar with use a file (with the open source FreeAmp project and some others this has an extension of .pls) stored on the receiver's computer with various information required to decode the broadcasts, including a URL to describe the source. When you click the "play" button on the web page, this file gets put on your hard disk, the player reads it, and gets the stream. We are already embedding (S,G) in our version, so that it will be possible to use the same file type with SSM. (how to best detect that SSM is in use is another story). In any case, once you have the file, it's like having a bookmark - you can just push play (or toggle on a play list in the player) and get the stream without having to go back to the original web page. If you're trying to scale multicasts to millions of simultaneous listeners or viewers, then you are going to need to have this sort of information distributed somehow, to avoid packet storms (when the Superbowl starts, say). On a deeper level, the simple fact is, the (S,G) will not change for YEARS for some large broadcasters. It would be hard, to put it mildly, to prevent people from embedding this info, even if you wanted to. Now - people have talked about having a DNS type distributed database (or, putting the info into the DNS itself, maybe as "A" records). In that case foo.multicast.ssm might map into 232.111.111.111 and be coupled with some IP address for the source. So far, so good - you could embed domain name type information instead of actual IP addresses. This would be a VERY useful feature to have, for things like local advertising insertion. I don't think that it really helps this problem, though : changing the G name->address mapping is likely to be as painful as renumbering your regular IP addresses - yeah, it can be done, but you don't want to do it very often. (We encountered DNS caches on the network with 30 day !!! expiration times. Imagine CNN being unavailable for some large chunk of the net for days because the caching hasn't updated!) This "multicast DNS" would be useful for a lot of reasons, but IMHO frequent changes in the Class D addresses in use is not one of them, at least for large broadcasters. (BTW, I have asked around about multicast DNS, and several people have told me that something is in the works, and have even sent me drafts. These, however, have been about using multicasting to distribute DNS information, not about using the DNS to distribute multicast information, so I do not know what the real status is here.) > > Mike Let's get together at San Diego and discuss this further... maybe at a bar BOF. Marshall Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From luby@digitalfountain.com Sun Nov 26 16:01:07 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18372 for ; Sun, 26 Nov 2000 16:01:06 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA26053 for ; Sun, 26 Nov 2000 11:45:32 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id eAQJjVQ07819 for ; Sun, 26 Nov 2000 11:45:31 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id LAA05602 for ; Sun, 26 Nov 2000 11:44:48 -0800 (PST) Received: from petersburg (adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id LAA25286; Sun, 26 Nov 2000 11:25:43 -0800 X-Authentication-Warning: mail.webfountain.com: Host adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195] claimed to be petersburg Reply-To: From: "Michael Luby" To: "Jon Crowcroft" , "Mark Handley" Cc: Subject: RE: A better name than ISM Date: Sun, 26 Nov 2000 11:30:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3606.975252082@cs.ucl.ac.uk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Well, I view SSM as somewhere in between IP unicast and the original IP multicast model, and in fact I think of SSM as a natural interpolation between the two that has a lot of advantages over IP unicast and the original IP multicast model, as well as some of its own natural limitations. Thus, I'm not understanding why it is a very big departure from the entire IP world. It seems to me that unicast has the most explicit association: sender is explicitly named and not changable. receiver is explicitly named and not changable. SSM is next: sender is explicitly named and not changable. receiver set can vary dynamically. Then, the original multicast model: sender set can vary dynamically. receiver set can vary dynamically. And, yes, it is ok to use the word fashion instead of compelling, if fashion is defined to mean what people are *currently* putting a concerted effort into to deploy commercially and create a revenue stream. And you are right, it may be fashionable in a couple of years to want to deploy commercially applications that are more suitable to the original multicast model. Let's see. I'm sure we can continue this conversation at a beer BOF ... (sunday evening, monday evening?) Mike -----Original Message----- From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk] Sent: Sunday, November 26, 2000 7:21 AM To: Mark Handley Cc: ssm-interest@external.cisco.com; J.Crowcroft@cs.ucl.ac.uk Subject: Re: A better name than ISM right - ssm is not multicast. its really a very big departure from the entire IP world - the difference between unicast and deering's multicast at the fundamental service level was very thin - anyone can send to either, and anyone can receive what is sent to them, or choose not -the rest was address allocation and routing the channel model in SSM explicitly creates an association from address allocation, source, and receiver set that is much less flexible (although as everyone keeps saying, appears to cover the majroity of the _current_ "compelling", or as i prefer, fashionable applications:-) i'd prefer we change the name of SSM back to channel In message <26247.975114786@hazard.aciri.org>, Mark Handley typed: >> >>>At 12:32 PM 11/24/00, Hugh Holbrook wrote: >>>>I agree. I think we should raise this issue at maddogs. It feels >>>>kind of like a nit, but I think naming is really important -- bad >>>>names can cause SO much confusion... >>> >>>OK, there seems to be consensus that "Internet Standard Multicast"/ISM is >>>not the best name/acronym for the current multicast model. As for an >>>alternative - IMHO, either "Any-Source Multicast"/ASM or >>>"Source-Independent Multicast"/SIM would be better. Personally, I prefer >>>"SIM" for (as Mike noted) its symmetry with SSM (given that SSM stands for >>>"Source-Specific Multicast", *not* "Single-Source Multicast".) >> >>SIM is a rather overloaded abbreviation, and ASM implies the receivers >>have no control over which sources they listen to, which is no longer >>true with IGMPv3. >> >>The key difference is that in SSM receivers join a source/channel, >>whereas in ISM they join a group (or group of sources). The ideal >>name would probably be Group-Specific Multicast, but that acronym is >>taken. Source-Group Multicast would work too, but (informally at >>least) that acronym is also taken. How about Group-Addressed >>Multicast (GAM), Internet Group Multicast (IGM) or just Group >>Multicast (GM)? >> >>Cheers, >> Mark >> >> cheers jon From eckert@cisco.com Sun Nov 26 18:34:26 2000 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25189 for ; Sun, 26 Nov 2000 18:34:26 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA14002 for ; Sun, 26 Nov 2000 17:28:29 -0500 (EST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA20394; Sun, 26 Nov 2000 14:30:06 -0800 (PST) From: Toerless Eckert Message-Id: <200011262230.OAA20394@cisco.com> Subject: Re: A better name than ISM To: luby@digitalfountain.com Date: Sun, 26 Nov 2000 14:30:06 -0800 (PST) Cc: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft), mjh@aciri.org (Mark Handley), ssm-interest@external.cisco.com In-Reply-To: from "Michael Luby" at Nov 26, 2000 11:30:35 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok, so this is how i perceive the problem: a) For just the technology, it's completely arbitrarily how we abbreviate the "IP Multicast service as defined in RFC1112". b) From the perspective of being able to completely confuse users, it's ideal to change the abbreviation every once so often. I certainly would rather like to avoid this for the documentation i have to provide to our users. Is there any way on how we could please converge on some abbreviation for the "IP Multicast service as defined in RFC1112" - and i mean an abbreviation that would then be at least highly recommended to be used in all IETF related papers (rfcs, etc..) ? Od course, everybody is still free to call it the "IP Multicast service as defined in RCC1112". Just wondering. Given that it's just a word, it shouldn't be too difficult. Up to a few weeks ago, i would have thought of simply voting on this to be an easy solution to the issue, but in the meantime i've learned that there are certain challenges associated with counting votes here in this country... Cheers Toerless From tme@21rst-century.com Mon Nov 27 12:49:22 2000 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00754 for ; Mon, 27 Nov 2000 12:49:21 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA20056 for ; Mon, 27 Nov 2000 08:08:49 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eARG90v08595 for ; Mon, 27 Nov 2000 08:09:00 -0800 (PST) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id IAA23358 for ; Mon, 27 Nov 2000 08:08:42 -0800 (PST) Received: from [63.105.122.50] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 571415; Mon, 27 Nov 2000 10:40:49 -0500 Message-ID: <3A2280A7.E8EB312E@21rst-century.com> Date: Mon, 27 Nov 2000 10:41:28 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Toerless Eckert CC: luby@digitalfountain.com, Jon Crowcroft , Mark Handley , ssm-interest@external.cisco.com Subject: Re: A better name than ISM References: <200011262230.OAA20394@cisco.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Toerless Eckert wrote: > Ok, so this is how i perceive the problem: > > a) For just the technology, it's completely arbitrarily how we abbreviate > the "IP Multicast service as defined in RFC1112". > > b) From the perspective of being able to completely confuse users, it's > ideal to change the abbreviation every once so often. I certainly > would rather like to avoid this for the documentation i have to provide > to our users. > > Is there any way on how we could please converge on some abbreviation for > the "IP Multicast service as defined in RFC1112" - and i mean an abbreviation > that would then be at least highly recommended to be used in all IETF > related papers (rfcs, etc..) ? Od course, everybody is still free to > call it the "IP Multicast service as defined in RCC1112". > > Just wondering. Given that it's just a word, it shouldn't be too difficult. > Up to a few weeks ago, i would have thought of simply voting on this to be > an easy solution to the issue, but in the meantime i've learned that there > are certain challenges associated with counting votes here in this country... > > Cheers > Toerless Dear Toerless; Referring to "votes" in an IETF context (or at an IETF meeting) is a good way to get razzed. I would say that rough consensus exists on SSM and ISM. I therefore would say, don't change it. The worst arguments in a group tend to occur about things that do not matter, as there is no good way to resolve them, except by fiat... -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From luby@digitalfountain.com Mon Nov 27 16:21:50 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09095 for ; Mon, 27 Nov 2000 16:21:48 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA22360 for ; Mon, 27 Nov 2000 11:57:01 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eARJv6C01173 for ; Mon, 27 Nov 2000 11:57:06 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id LAA00887 for ; Mon, 27 Nov 2000 11:56:08 -0800 (PST) Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id LAA25479; Mon, 27 Nov 2000 11:32:26 -0800 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: "Mike Luby" To: "Hugh LaMaster" , Cc: "Michael Luby" Subject: RE: Use of SAP in a PIM SSM Network Date: Mon, 27 Nov 2000 11:32:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Are agreements and approvals also welcome? ;) -----Original Message----- From: Hugh LaMaster [mailto:lamaster@nren.nasa.gov] Sent: Monday, November 27, 2000 10:05 AM To: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network On Sat, 25 Nov 2000, Marshall Eubanks wrote: > SSM in intended for (or, is at least, ideal for) BROADCASTING. > In the real world, broadcasters > stay up for years at a time. They don't like down time, even for seconds. > They will NEVER want to renumber their class D addresses - these will > get embedded in too many places (including .pls type files at the receivers) > to make any such transition smooth. > If there is a MAC layer collision, for any reason, they will want a fast > means of resolving it. Now, I am sorry, > but this sounds awful much like a static address to me. > > SSM is very attractive for broadcasters. Please do not hinder it by insisting > on some theoretical purity that does not fit their business model. Two points: 1) This isn't a question of "theoretical purity". Lots of IPv4 multicast addresses are mapped to each Ethernet multicast address assigned for IPv4 multicast. That means that layer-2 filtering must be imperfect. On this mailing list, or, one of its cousins, there was discussion/complaint a few months ago about traffic to some multicast address like 225.0.0.1 getting forwarded to all hosts-- well, it isn't a bug, it is a feature! SSM effectively eliminates the shortage of IPv4 multicast addresses, but, it doesn't address the shortage of MAC addresses, which is really a function of the way IEEE looked at multicast MAC addresses way back when. MAC layer collisions are unavoidable by design. But, they can be reduced in number through intelligent design. 2) I don't agree that static IPv4 multicast application addresses should *ever* be hardcoded. Just the opposite: application addresses should never, ever be hardcoded. The possibility should always exist for moving the address. Certainly, some broadcasters using SSM may not want to change the addresses every day, but, if someone mistakenly chooses an address with a serious collision problem of some kind, they should be prepared to change it. Applications with hardcoded addresses can create serious problems downstream. Disagreements and refutations welcome. -- ["I hate to say I told you so, but, I told you so." Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From eckert@cisco.com Mon Nov 27 16:29:38 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10955 for ; Mon, 27 Nov 2000 16:29:36 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA10420 for ; Mon, 27 Nov 2000 12:15:18 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA25510; Mon, 27 Nov 2000 12:14:30 -0800 (PST) From: Toerless Eckert Message-Id: <200011272014.MAA25510@cisco.com> Subject: Re: Use of SAP in a PIM SSM Network To: luby@digitalfountain.com (Mike Luby) Date: Mon, 27 Nov 2000 12:14:30 -0800 (PST) Cc: lamaster@nren.nasa.gov (Hugh LaMaster), ssm-interest@external.cisco.com, luby@digitalfountain.com (Michael Luby) In-Reply-To: from "Mike Luby" at Nov 27, 2000 11:32:36 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > MAC layer collisions are unavoidable by design. But, they can > be reduced in number through intelligent design. Well, i don't think that a protocol to solve this issue would be too difficult, the question really is, how much it would be needed at all! I would go so far as to say that most MAC layer switched networks will be able to sustain the level of MAC mapping ambiquity resulting from normal application use. Like: there is sufficient bandwidh to sustain that excess receipt traffic, and typical hosts (PCs, set-top boxes) are of equal - fast - speed. As soon as you modify these parameter - like what Bill suggested, connecting a poor lightbulb and a PC to the same MAC switched network, then you are stretching the simple MAC mapping function of RFC1112 too far, and you should look for a better solution, like a protocol to dynamically map (S/*,G) to individual MAC addresses, or better use layer3 switching instead of layer2 switching. Cheers Toerless From mjh@aardvark.aciri.org Mon Nov 27 16:52:23 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16830 for ; Mon, 27 Nov 2000 16:52:22 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA05206 for ; Mon, 27 Nov 2000 12:39:47 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eARKduR17805 for ; Mon, 27 Nov 2000 12:39:56 -0800 (PST) Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id MAA24098 for ; Mon, 27 Nov 2000 12:39:39 -0800 (PST) Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.11.1/8.11.1) with ESMTP id eARKRAc93957; Mon, 27 Nov 2000 12:27:10 -0800 (PST) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: pim@catarina.usc.edu, ssm-interest@external.cisco.com Subject: New version of PIM-SM spec available Date: Mon, 27 Nov 2000 12:27:10 -0800 Message-ID: <93955.975356830@aardvark.aciri.org> Sender: mjh@aciri.org A new version of the PIM-SM spec is available from: http://www.aciri.org/mjh/draft-ietf-pim-sm-v2-new-01.ps and http://www.aciri.org/mjh/draft-ietf-pim-sm-v2-new-01.txt We'd recommend the PostScript version if you're going to print it - it's much more readable. It was submitted to the I-D editor on Friday, so should appear in the I-D archives in due course. The main changes from the previous version are: - added (*,*,RP) state, state machines, and rules. - added a section clarifying the subset needed for PIM-SSM-only routers. - added a lot more explanation of some of the state machines In addition there have been a large number of corrections and clarifications - please see the changebars for these. Our thanks in particular go to John Zwiebel for his very detailed comments on the first version of this spec. As always, more comments and feedback would be much appreciated! - Bill, Mark, Hugh and Isidor From bwilliam@cisco.com Mon Nov 27 18:46:23 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22366 for ; Mon, 27 Nov 2000 18:46:23 -0500 (EST) Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA06402 for ; Mon, 27 Nov 2000 09:53:33 -0800 (PST) Received: from bwilliam-8000.cisco.com (bwilliam-isdn1.cisco.com [171.70.247.82]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA13989; Mon, 27 Nov 2000 09:52:55 -0800 (PST) Message-Id: <4.3.2.7.2.20001127114830.00b7adc0@mail1.cisco.com> X-Sender: bwilliam@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Nov 2000 11:52:38 -0800 To: Mark Handley , Bill Fenner From: Beau Williamson Subject: Re: Use of SAP in a PIM SSM Network Cc: sob@harvard.edu, ssm-interest@external.cisco.com In-Reply-To: <36853.975182314@hazard.aciri.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:58 AM 11/25/2000, Mark Handley wrote: >>>From my hallway discussions about MAC-layer collisions, I think the fear >>is that the light switch will join the ALL-LIGHT-SWITCHES group, and if >>that happens to collide at the MAC layer with a 25Mbps video stream the >>light switch's CPU will be too busy dropping traffic to turn the light on. >>Only a layer 3 device could save the light switch, since a layer 2 device >>(even an IGMP-snooping one) can still only filter on the MAC address. > >In almost all cases, having IP-aware NICs seems to be a bad thing in >the long run. This might just be one of those rare cases when it >isn't. > >If multicast ever becomes common enough for this to be a real problem, >I'd think this would be a point on which products can differentiate >themselves. Exactly. I personally think that IGMPv3 should be clear signal to switch designers that tomorrow's switches will not be able to make forwarding decisions solely at the MAC layer as they have in the past. Instead, they will need to maintain more L3 state in order to perform their tasks efficiently. Beau Williamson From lamaster@nren.nasa.gov Mon Nov 27 20:18:27 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12851 for ; Mon, 27 Nov 2000 20:18:25 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA27919 for ; Mon, 27 Nov 2000 10:24:06 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eARIOBA13457 for ; Mon, 27 Nov 2000 10:24:12 -0800 (PST) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.132.150]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id KAA06082 for ; Mon, 27 Nov 2000 10:23:57 -0800 (PST) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id KAA03963 for ; Mon, 27 Nov 2000 10:05:02 -0800 (PST) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Mon, 27 Nov 2000 10:05:02 -0800 (PST) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: ssm-interest@external.cisco.com Subject: Re: Use of SAP in a PIM SSM Network In-Reply-To: <3A1FE188.7BB9B54D@21rst-century.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 25 Nov 2000, Marshall Eubanks wrote: > SSM in intended for (or, is at least, ideal for) BROADCASTING. > In the real world, broadcasters > stay up for years at a time. They don't like down time, even for seconds. > They will NEVER want to renumber their class D addresses - these will > get embedded in too many places (including .pls type files at the receivers) > to make any such transition smooth. > If there is a MAC layer collision, for any reason, they will want a fast > means of resolving it. Now, I am sorry, > but this sounds awful much like a static address to me. > > SSM is very attractive for broadcasters. Please do not hinder it by insisting > on some theoretical purity that does not fit their business model. Two points: 1) This isn't a question of "theoretical purity". Lots of IPv4 multicast addresses are mapped to each Ethernet multicast address assigned for IPv4 multicast. That means that layer-2 filtering must be imperfect. On this mailing list, or, one of its cousins, there was discussion/complaint a few months ago about traffic to some multicast address like 225.0.0.1 getting forwarded to all hosts-- well, it isn't a bug, it is a feature! SSM effectively eliminates the shortage of IPv4 multicast addresses, but, it doesn't address the shortage of MAC addresses, which is really a function of the way IEEE looked at multicast MAC addresses way back when. MAC layer collisions are unavoidable by design. But, they can be reduced in number through intelligent design. 2) I don't agree that static IPv4 multicast application addresses should *ever* be hardcoded. Just the opposite: application addresses should never, ever be hardcoded. The possibility should always exist for moving the address. Certainly, some broadcasters using SSM may not want to change the addresses every day, but, if someone mistakenly chooses an address with a serious collision problem of some kind, they should be prepared to change it. Applications with hardcoded addresses can create serious problems downstream. Disagreements and refutations welcome. -- ["I hate to say I told you so, but, I told you so." Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*.