From owner-Big-Internet@munnari.OZ.AU Fri Dec 6 02:26:18 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA11030; Fri, 6 Dec 1996 02:26:18 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA16734; Fri, 6 Dec 1996 02:25:48 +1100 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16706; Fri, 6 Dec 1996 02:06:06 +1100 Received: from gomez.cs.pitt.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA10601; Fri, 6 Dec 1996 02:05:57 +1100 (from znati@cs.pitt.edu) Received: from ra.cs.pitt.edu (ra.cs.pitt.edu [136.142.79.32]) by gomez.cs.pitt.edu (8.8.3/8.8.3) with ESMTP id KAA06370 for ; Thu, 5 Dec 1996 10:05:54 -0500 (EST) From: Taieb Znati Received: (from znati@localhost) by ra.cs.pitt.edu (8.8.3/8.8.3) id KAA04127 for big-internet@munnari.OZ.AU; Thu, 5 Dec 1996 10:05:53 -0500 (EST) Message-Id: <199612051505.KAA04127@ra.cs.pitt.edu> Subject: DMS97 CFP To: big-internet@munnari.OZ.AU (Potential Authors 10) Date: Thu, 5 Dec 1996 10:05:53 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk CALL FOR PAPERS 1997 Pacific Workshop on Distributed Multimedia Systems University of British Columbia, Vancouver, Canada July 24-25, 1997 The last few years have seen an explosive growth of multimedia computing, communication and applications. This revolution is transforming the way people live, work, and interact with each other, and is impacting the way businesses, government services, education, entertainment, and health care are operating. It is safe to say that the multimedia revolution is underway. Yet, several issues related to modeling, specification, analysis and design of distributed multimedia systems and applications are still challenging to both researchers and practitioners. The purpose of this workshop is to serve as a forum for the exchange of ideas among practicing engineers and researchers from around the world, as well as highlight current activities and important topics in the field of distributed multimedia systems and technology. The paper session is designed to promote discussion of concepts, methodologies, and results between the authors and the audience, and provide for a degree of collegiality and continuity in the discussions of these various topics among the participants. In addition, tutorials will be held on June 25 and 26 to provide participants with the opportunity to interact with experts in various fields of distributed multimedia systems. The workshop organizers seek contributions of high quality papers, panels or tutorials, addressing various aspects of distributed multimedia systems and applications, for presentation at the conference and publication in the workshop proceedings. Topics of interest include, but are not limited to: [*] Distributed Multimedia Databases and Computing [*] Multi-paradigmatic Information Retrieval [*] Modeling and Analysis of Distributed multimedia systems [*] OS Support for Distributed Multimedia systems [*] Multimedia Communications and Networking [*] Multimedia Digital Libraries and Mail Systems [*] Multimedia Human-Computer Interaction [*] Visual and Multidimensional Languages for multimedia applications [*] Multimedia Workflows [*] Multimedia Stream Synchronization [*] Virtual Reality, Virtual Environment, and their Applications The use of prototypes and demonstration video for presentations is encouraged. Workshop Site: The workshop will be held at the University of British Columbia, Vancouver, Canaca. Special arrangement will be made with local hotels for a limited number of rooms at the special workshop rate. Information for Authors: Submit four copies of panel or tutorial proposals or manuscripts (maximum of 20 double-spaced pages) including abstract, keywords and complete information of a contact person to one of the following program co-chairs: Professor Taieb Znati Dept. of Computer Science University of Pittsburgh Pittsburgh, PA 15260 USA Tel: +1 412-624-8417 Fax: +1 412-624-8854 Email: znati@cs.pitt.edu Professor An-Chi Liu Dean, College of Engineering Fong-Chia University Tai-Chung, Taiwan Tel: +886-4-252-7110 Fax: +886-4-323-9903 Email: liu@fcusqnt.fcu.edu.tw Papers, tutorials and panels can also be directly deposited by anonymous ftp at ftp.cs.pitt.edu:/pub/DMS97/Paper-Deposit. Submitted files must be in PostScript format with all figures and tables included. Important Dates: * January 15, 1996: Paper\Proposal submission deadline * March 15, 1997: Notification of acceptance * April 15, 1997: Final manuscript due Sponsored by: * Knowledge Systems Institute, USA * University of British Columbia, Canada * University of Pittsburgh, USA * Fong-Chia University, Taiwan Workshop Co-Chairs: * Son T. Vuong, University of British Columbia, Canada * S. K. Chang, University of Pittsburgh, USA Program Committee Co-Chairs: * Taieb Znati Univ. of Pittsburgh, USA * An-Chi Liu Fong-Chia University, Taiwan Local Arrangement Chair: * Panos Nasiopoulos University of British Columbia, Canada Program Committee: * Hong-Mei Chen Univ. of Hawaii, USA * Wen-Tsuen Chen National Tsing Hua University * Yanghee Choi Seoul National University * Jean-Pierre Courtiat Centre National de Recherche Scientifique, France * Gerald Neufeld University of British Columbia * Dieu D. Phan National Program on Information Technology, Vietnam * Anindya Datta University of Arizona, Tucson AZ * David H. C. Du Univ. of Minnesota, USA * Nicolas D. Georganas Depart. of Elec. and Comp. Eng., Univ. of Ottawa * Norm Hutchinson University of British Columbia BC * William Grosky Wayne State Univ., USA * Venkat N. Gudivada University of Missouri-Rolla * Arding Hsu Siemens Corporate Research, USA * Oscar Ibarra Univ. of Cal., Santa Barbara, USA * Stephen Y. Itoga University of Hawaii * Paul Lin CCL, Taiwan * Tom D.C. Little<\b> University of Boston , USA * Ralph Martinez ECE, Radiology, & Pathology Dept. Univ. of Arizona * J. Mizusawa NTT Multi-media Network Laboratories * Ming-Chien Shan Hewlett Packard Labs * Olivia R. Liu Sheng HKUST, Hong Kong * Jaideep Srivastava Univ. of Minnesota, USA * Kazuo Sugihara Univ. of Hawaii, USA * Joseph E. Urban Arizona State Univ., USA * Chun-Chia Wang Tamkang University, Taiwan, R.O.C. * Don-Lin Yang Feng Chia University, Taichung, Taiwan For additional information, please send mail to znati@cs.pitt.edu or liu@fcusqnt.fcu.edu.tw. Updated conference announcement and information are accessible by anonymous ftp at ftp.cs.pitt.edu:/pub/DMS97 or by directly accessing the conference home page at http://www.cs.pitt.edu/DMS97. From owner-Big-Internet@munnari.OZ.AU Thu Dec 19 04:31:47 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA18612; Thu, 19 Dec 1996 04:31:47 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA02724; Thu, 19 Dec 1996 04:30:48 +1100 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA02707; Thu, 19 Dec 1996 04:23:27 +1100 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA08094; Thu, 19 Dec 1996 04:23:18 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15345; Wed, 18 Dec 96 12:12:03 -0500 Date: Wed, 18 Dec 96 12:12:03 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9612181712.AA15345@ginger.lcs.mit.edu> To: huitema@bellcore.com, mo@uu.net Subject: Re: A connection-based Internet? Cc: big-internet@munnari.OZ.AU, flows@research.ftp.com, jkr@netstar.com, tagswitch@cisco.com Precedence: bulk From: "Mike O'Dell" the fundamental problem is that the model of "ip destination-only" forwarding is not powerful enough to build the networks required for the current Internet, much less the future. Much as I am very interested in the basic question under debate here, I think this discussion is fundamentally pointless, if not "out of order", *in this forum*. Experience in the IETF has shown, over and over again, that we'll argue about this for months, and when the dust settles, very few minds will have been changed, and the situation will not have been resolved. In the meantime, much time/energy of the WG-to-be will have been wasted. So, I will say again: this is not an effort to formally get the IETF as a whole to agree to switch to flows as a fundamental paradigm. It is a forum for people who like a certain set of ideas to come up with specifications which implement those ideas. If you think the ideas are crazy/impossible, that's fine, just please sit quietly and watch as other people waste their time, and let the rest of the group get on with doing their thing. nobody is arguing for "end to end VCs". that's just silly. One of the things that continually annoys me no end is the apparent inability of some people to grok that there is a lot (anything?) in the middle of the spectrum between the extremes of pure-stateless-datagram (a la IPv4), and old-style-virtual-circuits (a la X.25). It seems like anytime someone stands up and says "maybe we need to do something other than pure datagram", there are always people accuse you of wanting to do VC's. The fact that the proposer is well aware of the problems of pure VC's, and doesn't want to do a pure VC network, is usually completely missed. They also don't usually seem to have bothered to take the time to understand what it is you actually *are* proposing. Needless to say, after a while it all, especially the latter bit, gets pretty unfuriating. Someone at the just-passed IETF described this as a "four-legs-good, two-legs-bad" model of reality, and that's right on target. I find, over and over again in the IETF (and it was very obvious with the past debate on variable length addresses), that many minds are already made up, and no real objective, open-minded, thoroughgoing, from-scratch analysis of the engineering good and bad points of new approaches are made. Instead, they are dismissed with an immediate, simplistic, and unstudied "two-legs-bad" kind of reaction that's all to apparent, after you've been on the receiving end enough times. The good thing about reactions like that is that you soon figure out that since there is little deep analysis behind them, you can just blow them off. If you think reasoned debate is going to change them, think again - been there, tried that. The packet world is a victim of its own sucess. The people who would, in the 60's, have been *outside* saying "it's new, and therefore won't work" are now *inside* saying "it's new, and therefore won't work". what we are talking about is switching flows, where there is some efficiency to be gained in establishing soft state in the forwarding paths. Be careful with the use of the term "soft state". As far as I can tell, it means different things (in terms of operational considerations like who establishes it, who maintains it, who removes it, what happens when it's missing, etc) to just about everyone who uses the term. In fact, it seems to have fallen victim to "four-legs-good" disease, in that schemes that someone likes are inevitably described as being "soft state", whereas schemes they don't like are always described as "hard state". (One's own scheme is *always* "soft state", no matter how the definition of that has to be twisted to fit.) Given that the routing tables used in the current pure-stateless-datagram model are the hardest of hard state, I wonder exactly how they fit into the simplistic "hard-state-bad" view of reality that seems to be common among those who adhere most tenaciously to the PSD model, but I digress. the ability to place bandwidth between the points where it needed, as best approximated by where you can actually get it, and then place the traffic of interest on that path without going crazy screwing with IP metrics Some of us might point out that the current fundamental routing architecture of the 'Net, one inherited basically unchanged from the Baran work in the early 60's, and one intended for far smaller networks with different requirements, is really not the paradigm we ought to be working within - but that's a different WG! :-) in other networks ... the flows are much larger, aggregate objects which have little to do with any particular IP prefix, other than it and a bunch of others directly connect to the infrastructure off a particular superhub. (this is where the mapping between randomly-assigned IP address and physical proximity happens.) Too bad addresses in packets don't exclusively reflect something that's actually useful to the packet-forwarding fabric, like where you are, or anything. Nah, that's too obvious. link-state technology tries to duck the question by letting everyone pretend they know everything. there's something deeply unscalable about this notion of "just tell everyone everything". Depending on exactly what you mean by "link-state", sorry to disappoint you, but this statement has been untrue for at least 10 years. ("Four legs good...") See: Josh Seeger and Atul Khanna, "Reducing Routing Overhead in a Growing DDN", MILCOMM '86, IEEE, 1986. for an early one, and of course the IETF's own OSPF also somehow seems to work without global knowledge. It's this kind of simplistic statement which leads less-knowledgeable people down the path, and I hope people will cease and desist with them? Noel From owner-Big-Internet@munnari.OZ.AU Thu Dec 19 05:10:53 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA17688; Thu, 19 Dec 1996 05:10:53 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA02792; Thu, 19 Dec 1996 05:10:43 +1100 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02770; Thu, 19 Dec 1996 05:01:58 +1100 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA08223; Thu, 19 Dec 1996 05:01:56 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15581; Wed, 18 Dec 96 13:01:53 -0500 Date: Wed, 18 Dec 96 13:01:53 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9612181801.AA15581@ginger.lcs.mit.edu> To: huitema@bellcore.com, jnc@ginger.lcs.mit.edu, mo@uu.net Subject: Re: A connection-based Internet? Cc: big-internet@munnari.OZ.AU, flows@research.ftp.com, jkr@netstar.com, jnc@ginger.lcs.mit.edu, tagswitch@cisco.com Precedence: bulk From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Much as I am very interested in the basic question under debate here, I think this discussion is fundamentally pointless, if not "out of order", *in this forum* PS: Sorry I forgot to mention this on the original message, but if you feel a need to reply to this, please do so only on the "tagswitch" mailing list. I CC'd "flows" and "big-i" since I felt that the points I had to make might be of interest to people there as well. Noel From owner-Big-Internet@munnari.OZ.AU Fri Dec 20 05:12:21 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA11424; Fri, 20 Dec 1996 05:12:21 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA04173; Fri, 20 Dec 1996 05:11:10 +1100 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA04154; Fri, 20 Dec 1996 04:58:07 +1100 Received: from mailhost.ipsilon.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA00270; Fri, 20 Dec 1996 04:58:04 +1100 (from minshall@ipsilon.com) Received: from red.ipsilon.com (red.Ipsilon.COM [205.226.1.58]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id JAA28718; Thu, 19 Dec 1996 09:57:22 -0800 Received: from red.ipsilon.com by red.ipsilon.com (8.6.12) id JAA04528; Thu, 19 Dec 1996 09:58:30 -0800 Message-Id: <199612191758.JAA04528@red.ipsilon.com> X-Mailer: exmh version 1.6.4 10/10/95 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: huitema@bellcore.com, mo@UU.NET, big-internet@munnari.OZ.AU, flows@research.ftp.com, jkr@netstar.com, tagswitch@cisco.com Subject: Re: A connection-based Internet? In-Reply-To: Your message of "Wed, 18 Dec 1996 12:12:03 EST." <9612181712.AA15345@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Dec 1996 09:58:29 -0800 From: Greg Minshall Precedence: bulk Noel, > I find, over and > over again in the IETF (and it was very obvious with the past debate on > variable length addresses), that many minds are already made up, and no real > objective, open-minded, thoroughgoing, from-scratch analysis of the > engineering good and bad points of new approaches are made. Instead, they are > dismissed with an immediate, simplistic, and unstudied "two-legs-bad" kind of > reaction that's all to apparent, after you've been on the receiving end enough > times. You have to be a bit careful here. There are twin dangers in designing: one, as you point out, is "different is bad"; the other is what i term "the tyranny of analytic thinking", which is to say "if i can *prove* something thru some logical process to be true, that means it is, in fact, true". The problem with the latter is that there are many things that have been "proven" over the years, but don't, in fact, work (or, in the math space, 'theorems' that have been 'proved' but aren't, in fact, true). Thus, basing things on what we currently know is by no means a stupid thing to do. On the other hand, trying something new, and getting experience with it, is also a very good idea; it's just that you shouldn't expect people to "salute" because of a closed form proof -- working code is much more persuasive! Greg From owner-Big-Internet@munnari.OZ.AU Fri Dec 20 06:51:34 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA12645; Fri, 20 Dec 1996 06:51:34 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA04296; Fri, 20 Dec 1996 06:51:12 +1100 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA04279; Fri, 20 Dec 1996 06:39:31 +1100 Received: from linux.silkroad.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA10916; Fri, 20 Dec 1996 06:39:23 +1100 (from bass@linux.silkroad.com) Received: (from bass@localhost) by linux.silkroad.com (8.7.3/8.6.9) id OAA12464; Thu, 19 Dec 1996 14:38:59 -0500 From: Tim Bass Message-Id: <199612191938.OAA12464@linux.silkroad.com> Subject: Re: A connection-based Internet? To: minshall@Ipsilon.COM (Greg Minshall) Date: Thu, 19 Dec 1996 14:38:58 -0500 (EST) Cc: jnc@ginger.lcs.mit.edu, huitema@bellcore.com, mo@uu.net, big-internet@munnari.OZ.AU, flows@research.ftp.com, jkr@netstar.com, tagswitch@cisco.com In-Reply-To: <199612191758.JAA04528@red.ipsilon.com> from "Greg Minshall" at Dec 19, 96 09:58:29 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Noel laments: > and NO real objective, open-minded, thoroughgoing, from-scratch analysis > of the engineering good and bad points of new approaches are made. > Instead, they are dismissed with an immediate, simplistic, ..... Bravo!! Then, Greg responds: > ... working code is much more persuasive! Indeed, the Root of The Problem! EGP was 'working code' however, Eric himself stated EGP was NOT a valid routing protocol. Yet BGP was built on EGPs 'working code'. Then! many pointed out BGP was certainly flawed, concentrating on manually configurable 'routing policies' and a core topology, basically a 'modified-spanning-tree paradigm'; yet the working code was the foundation for the problematic IP exterior routing protocol of today. Let me remind everyone, the problem with scalability &c was documented in RFCs in the early 1980s, almost 20 years ago, yet modifying 'working code' based on a back-o-the- envelope, quick-and-dirty 'working code' paradigm, dominated (and continues to dominate) the process. The lesson learned might be thus: ----------------------------------------------------------------- Working code is persuasive, but not necessary the best development track! and certainly not the best design. ----------------------------------------------------------------- Both Noel and Greg are both correct. The IETF audaciously prides itself on hacking 'working code' and avoiding the painful but necessary step of analysis and broad peer review on important and far reaching issues such as global exterior routing paradigms. On the other 'business reality' hand... If 'someone' aggressively advocates a new routing paradigm, aggressively without broad peer review, and does it with an quiet eye toward a patent or financial gain; we shall just see the distasteful process repeated for the second time. We all agree it is not difficult to design a new, truly scalable, hierarchical protocol that works with meshed ADs and does not provide tacit advantages of one provider over another in the marketplace; however what is often in the best interest of the marketplace is rarely in the best interest of the established businesses with a very real interest in growing, not diminishing, market share and revenue. The IETF has never been immune to commercial influences and there is not a period in history where commerce did not dominate the decision making process. Let us not be deceived in fancying an Internet dominated by spiritual sages and selfless actions without the motive of profit. Best Regards, Tim -- mailto:bass@silkroad.com voice (703) 222-4243 http://www.silkroad.com/ fax (703) 222-7320 From owner-Big-Internet@munnari.OZ.AU Fri Dec 20 08:51:39 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA13675; Fri, 20 Dec 1996 08:51:39 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA04442; Fri, 20 Dec 1996 08:51:13 +1100 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA04436; Fri, 20 Dec 1996 08:47:41 +1100 Received: from red.jnx.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA20962; Fri, 20 Dec 1996 08:47:39 +1100 (from tli@jnx.com) Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id NAA17944; Thu, 19 Dec 1996 13:46:05 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id NAA23209; Thu, 19 Dec 1996 13:45:31 -0800 (PST) Date: Thu, 19 Dec 1996 13:45:31 -0800 (PST) Message-Id: <199612192145.NAA23209@chimp.jnx.com> From: Tony Li To: bass@linux.silkroad.com Cc: minshall@Ipsilon.COM, jnc@ginger.lcs.mit.edu, huitema@bellcore.com, mo@uu.net, big-internet@munnari.OZ.AU, flows@Research.Ftp.Com, jkr@netstar.com, tagswitch@cisco.com In-Reply-To: <199612191938.OAA12464@linux.silkroad.com> (message from Tim Bass on Thu, 19 Dec 1996 14:38:58 -0500 (EST)) Subject: Re: A connection-based Internet? Precedence: bulk BGP was built on EGPs 'working code'. Amazing. Tony From owner-Big-Internet@munnari.OZ.AU Fri Dec 20 09:51:36 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA24371; Fri, 20 Dec 1996 09:51:36 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA04525; Fri, 20 Dec 1996 09:51:14 +1100 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA04508; Fri, 20 Dec 1996 09:39:32 +1100 Received: from black-ice.cc.vt.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA22424; Fri, 20 Dec 1996 09:39:27 +1100 (from valdis@black-ice.cc.vt.edu) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.4/8.8.4) with ESMTP id RAA30534; Thu, 19 Dec 1996 17:39:01 -0500 Message-Id: <199612192239.RAA30534@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0alpha 12/3/96 To: Greg Minshall Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), huitema@bellcore.com, mo@uu.net, big-internet@munnari.OZ.AU, flows@research.ftp.com, jkr@netstar.com, tagswitch@cisco.com Subject: Re: A connection-based Internet? In-Reply-To: Your message of "Thu, 19 Dec 1996 09:58:29 PST." <199612191758.JAA04528@red.ipsilon.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <199612191758.JAA04528@red.ipsilon.com> Comments: Hyperbole mail buttons accepted, v04.01. Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-2039064254P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 19 Dec 1996 17:39:00 -0500 Precedence: bulk --==_Exmh_-2039064254P Content-Type: text/plain; charset=us-ascii On Thu, 19 Dec 1996 09:58:29 PST, Greg Minshall said: > The problem with the latter is that there are many things that have been > "proven" over the years, but don't, in fact, work (or, in the math space, > 'theorems' that have been 'proved' but aren't, in fact, true). Or even worse, are *truly* provably true within a given domain. See Euclid's parallel postulate and non-Euclidean geometry for an example. Just because something was demonstrably true 10 years ago doesn't mean that it will still be true once the next generation of comes along, and the nature of things changes. -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_-2039064254P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMrnEANQBOOoptg9JAQE/qwQAsHTQQQln9hsvhHg3JltpqiKL9hV9pp0k x1+2OnEVc6UnzLNmwwagdBO6F39xxXZgfIhwA1tHuYn2qF3k+cYeurOCfwIQUocL VDytWGzJqFrXc+odrGgBQChKmJS2V/mj9uhItVk8SV4zDd3h4oBjqWjwoc5L0M7g OEHGo2SWdwk= =q2Rv -----END PGP MESSAGE----- --==_Exmh_-2039064254P-- From owner-Big-Internet@munnari.OZ.AU Fri Dec 20 09:52:45 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA09622; Fri, 20 Dec 1996 09:52:45 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA04547; Fri, 20 Dec 1996 09:52:28 +1100 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA04505; Fri, 20 Dec 1996 09:34:28 +1100 Received: from linux.silkroad.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA28723; Fri, 20 Dec 1996 09:34:24 +1100 (from bass@linux.silkroad.com) Received: (from bass@localhost) by linux.silkroad.com (8.7.3/8.6.9) id RAA12892; Thu, 19 Dec 1996 17:29:07 -0500 From: Tim Bass Message-Id: <199612192229.RAA12892@linux.silkroad.com> Subject: Re: A connection-based Internet? To: tli@jnx.com (Tony Li) Date: Thu, 19 Dec 1996 17:29:07 -0500 (EST) Cc: minshall@Ipsilon.COM, jnc@ginger.lcs.mit.edu, huitema@bellcore.com, mo@uu.net, big-internet@munnari.OZ.AU, flows@research.ftp.com, jkr@netstar.com, tagswitch@cisco.com In-Reply-To: <199612192145.NAA23209@chimp.jnx.com> from "Tony Li" at Dec 19, 96 01:45:31 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk > > > BGP was built on EGPs 'working code'. > > Amazing. Sorry to cross swords with you in public, Monsieur BGP! For what other excuse can there be for such an 'policy based, manually configurable' core-tree paradigm that is not scalable (like EGP), exchanges no routing policies (like EGP) and looks like EGP with more features and 'advances' ? BGP was certainly not a radical departure from EGP like so many competing technologies and paradigms that for certain would require a complete rewrite. It certainly was not a new vision for a meshed AD topology providing zero dependence on the core-tree superstructure. However, if you claim that not one line of YOUR code was used for BGP from EGP, Monsieur, that may well be. However, based on the very close similarity between the two protocols in principle and paradigm, it stands to reason that SOMEONE other than yourself thought of EGP when considering BGP. One thing is certain, honorable Monsignor, we shall never agree in principle on the BGP development track. Some shall consider it 'a wonder of engineering', changing 'wings on airplanes in mid-flight', and other romantic tales from the net. Yet others, perfectly well educated and knowledgable engineers will disagree, and with acceptable reason. I beg you, Monsieur, to allow me to take leave of this dialog; because I am a critic of BGP, and after searching the entire IEEE publication database, printing, studying, reading all of the papers on the subject, and reading every paper printed on hierarchical routing. Yet! I still remain a critic of BGP, in spite of the romantic rhetoric. This criticism, however, is certainly not a personal one! My issues are with those who placed 'policy based routing' to enforce directed AUPs above clustering and scalability. This, as I currently see it, was the driving force that has lead ERP development down it's thorny path. Best Regards, Tim From owner-Big-Internet@munnari.OZ.AU Wed Dec 25 13:34:11 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id CA19423; Wed, 25 Dec 1996 13:34:11 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA10805; Wed, 25 Dec 1996 13:33:21 +1100 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA10787; Wed, 25 Dec 1996 13:13:11 +1100 Received: from tsbgw.wide.toshiba.co.jp by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id CA26491; Wed, 25 Dec 1996 13:13:08 +1100 (from hiroshi@isl.rdc.toshiba.co.jp) Received: (from uucp@localhost) by tsbgw.wide.toshiba.co.jp (8.7.3/8.7.3/%I%) with UUCP id LAA10275; Wed, 25 Dec 1996 11:12:34 +0900 (JST) Received: from mejiro.isl.rdc.toshiba.co.jp (hiroshi@mejiro.isl.rdc.toshiba.co.jp [133.196.16.1]) by mailhost.isl.rdc.toshiba.co.jp (8.8.4/8.8.3/2.11) with ESMTP id LAA24953 From: hiroshi@isl.rdc.toshiba.co.jp (Hiroshi Esaki) Message-Id: <199612250207.LAA24953@isl.rdc.toshiba.co.jp> Date: Wed, 25 Dec 1996 11:07:48 +0900 (JST) To: minshall@ipsilon.com Cc: jnc@ginger.lcs.mit.edu, huitema@bellcore.com, mo@UU.NET, big-internet@munnari.OZ.AU, flows@research.ftp.com, jkr@netstar.com, tagswitch@cisco.com In-Reply-To: <199612191758.JAA04528@red.ipsilon.com> (message from Greg Minshall on Thu, 19 Dec 1996 09:58:29 -0800) Subject: Re: A connection-based Internet? Precedence: bulk greg> Thus, basing things on what we currently know is by no means greg> a stupid thing to do. greg> On the other hand, trying something new, and getting greg> experience with it, is also a very good idea; it's greg> just that you shouldn't expect people to "salute" greg> because of a closed form proof -- working code is much more greg> persuasive! running and working code gives us the important feedback to the next code to fix the problem of old code. We believe that the experiences through the actually operating system is very important and is also the greate feedback to the mailing-list. Hiroshi Esaki (Toshiba Corp.) From owner-Big-Internet@munnari.OZ.AU Wed Dec 25 14:13:28 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id DA17485; Wed, 25 Dec 1996 14:13:28 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA10871; Wed, 25 Dec 1996 14:13:19 +1100 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA10851; Wed, 25 Dec 1996 14:00:19 +1100 Received: from necom830.hpcl.titech.ac.jp by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id DA18066; Wed, 25 Dec 1996 14:00:12 +1100 (from mohta@necom830.hpcl.titech.ac.jp) From: Masataka Ohta Message-Id: <199612250257.LAA06769@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA06769; Wed, 25 Dec 1996 11:57:32 +0900 Subject: Re: A connection-based Internet? To: hiroshi@isl.rdc.toshiba.co.jp (Hiroshi Esaki) Date: Wed, 25 Dec 96 11:57:30 JST Cc: minshall@ipsilon.com, jnc@ginger.lcs.mit.edu, huitema@bellcore.com, mo@UU.NET, big-internet@munnari.OZ.AU, flows@research.ftp.com, jkr@netstar.com, tagswitch@cisco.com In-Reply-To: <199612250207.LAA24953@isl.rdc.toshiba.co.jp>; from "Hiroshi Esaki" at Dec 25, 96 11:07 am X-Mailer: ELM [version 2.3 PL11] Precedence: bulk > greg> Thus, basing things on what we currently know is by no means > greg> a stupid thing to do. > greg> On the other hand, trying something new, and getting > greg> experience with it, is also a very good idea; it's > greg> just that you shouldn't expect people to "salute" > greg> because of a closed form proof -- working code is much more > greg> persuasive! > > running and working code gives us the important feedback to > the next code to fix the problem of old code. > We believe that the experiences through the actually operating > system is very important and is also the greate feedback to the > mailing-list. In good old days when not so much effort was spent for the implementation of Internet protocols, the running code principle was working to prevent developing unnecessary protocols and make developed protocols simple. Today, with so much investment on the Internet, the running code principle is hardly working any more. People says "it's too late to change spec", even before a protocol becomes a PS. Masataka Ohta