Re: An alternative to TCP (part 1)
>> > The host *is* the edge of the network. >> >> I'm sorry to have not mentioned that I consider the host nodes, >> or the end nodes, are not edges but instead something attaching >> on network edges. I consider the very last hub, or the access router >> which the end nodes connected to as the 'network edge'. > So there's no network between me and another computer on the > same unswitched Ethernet? >For example the old 10Base2 ethernet links? Or a cross-link twisted-pairs? >I can say the full length of the 10Base2 link can be regarded as a (passive) repeater hub. >I think 'network edge' is somewhat a arbitrary definition. Maybe I'm not correct but I >believe distinguishing 'network edge' from 'end node' may provide some convenience for >further discussion on the congestion control and avoidance mechanism. If I'm not wrong the ethernet is a type of LAN (local area NETWORK) and therefore there is a network even without routing or switching devices; the edges of the networks are the hosts. Anyway, I agree with Mr Gao that it will be usefull to have a distinguishing name for the last network element, something like ONE "outest network element" or END "edge netework device" or any other that may be chosen. Joaquin Rivera
Re: An alternative to TCP (part 1)
> you should probably redirect this conversation to > the end2end-interest list: > <[EMAIL PROTECTED]> > > the entire IETF list is probably the wrong place for substantive technical > discussion of this type. I agree. I've subscribed to [EMAIL PROTECTED] by visiting http://www.postel.org/mailman/listinfo/end2end-interest I use another email account: Jason Gao [[EMAIL PROTECTED]]. Further information on ATP will be posted on it. The structure of the full essay is: Asymmetric Transport Protocol -- An alternative to TCP in IPv6 internetworking Part I Motivations and Key points Part II Protocol Header Part III Setup and Release of an ATP Connection Part IV Reliable Data Transport Part V Flow Control and Congestion Avoidance Part VI Event Handling and State Transition Part VII Quality of Service Issues and Security Issues Part VIII Miscellaneous -- ATP and ECN, ATP Congestion Control: Why not only round-trip feedback -- ATP and DNS, Resource Catalog or Directory Service -- ATP APIs and Migration Issue -- Possibility to consolidate the key features of RSVP, ISAKMP, IPSec/TLS and IPComp. Jason Gao
Managing Complex Organizations in a Complex World
MANAGING COMPLEX ORGANIZATIONS IN A COMPLEX WORLD: Leadership in Rapidly Changing Business Environments - Learning and Adapting in Time NECSI Executive Education Programs May 31-June 1, 2001 Charles Hotel, Harvard Square, Cambridge, MA Speakers: YANEER BAR-YAM, NECSI and Harvard University TOM PETZINGER, JR., Author, The New Pioneers, and CEO LaunchCyte PETER SENGE, Society for Organizational Learning and MIT Sloan School of Management JOHN STERMAN, MIT Sloan School of Management This is a two-day practical experience on working with chaos and complexity - in the global economy, in national markets, in business to business interactions and within the organization itself. We will use new insights and concepts from the field of complex systems to discuss innovative ways to survive and thrive in today's new/old economy. Information and registration: http://necsi.org/education/exec/ Objectives: We will identify the key properties of successful complex organizations - their structure, dynamics, information flows, and relationships - and the essential roles of leadership in responding to the rapidly changing complex world. Participants will leave prepared to pay attention to new information, ask new questions, make better decisions - to identify the right time to adapt quickly and when to stay as they are. Approach: The presenters will interact with participants in exploring the key concepts of managing organizations as complex systems. Questions are welcome and discussion time will be a key part of the program. Speakers will present a cutting-edge perspective on managing business as it is - human and complex. Audience: This seminar is created for key decision makers and those who advise them - executives, senior management, public administrators, management consultants, organizational development professionals and business educators. Results: At the end of the seminar participants will be able to: * Identify key success factors in rapid and early adaptation to changes in the business and political climate * Value critical organizational connections - know when to create them and when to cut them * Gain insights and skills to make better decisions in uncertain situations * Manage the use of new tools - including simulation and system modeling - to analyze the behavior of complex organizations Speakers: YANEER BAR-YAM is President of the New England Complex Systems Institute, Chairman of the International Conference on Complex Systems, Managing Editor of InterJournal, and author of Dynamics of Complex Systems (1997), the only textbook to address the entire field of complex systems. Bar-Yam uses complex systems concepts to understand how organizations and patterns of behavior arise, evolve, adapt, and how we can use multiscale representations to relate fine and large scale, short and long term perspectives. Applications are to the relationship of structure and function and meeting complex challenges at all scales. THOMAS PETZINGER, JR., the author of "The New Pioneers: The Men and Women Who Are Transforming the Workplace and Marketplace", spent 22 years at The Wall Street Journal as a weekly columnist, beat reporter, investigative reporter, bureau chief, and Washington ecomomics editor. From 1995 to 1999 he wrote the paper's Front Lines column, a weekly exploration of entreprenurial ideas and management trends. He also edited the paper's special edition for Jan. 1, 2000. Petzinger's earlier books are Oil & Honor: The Texaco-Pennzoil Wars" (Putnam, 1987) and "Hard Landing: The Epic Contest for Power and Profits that Plunged the Airlines into Chaos" (Random House, 1995). Petzinger is applying his knowledge of complex systems in the new economy as founder, director, and CEO for LaunchCyte, a biotechnology incubator. PETER M. SENGE is a Senior Lecturer at the Massachusetts Institute of Technology and Chairperson of the Society for Organizational Learning (SoL), a global community of corporations, researchers, and consultants dedicated to the "interdependent development of people and their institutions." He is the author of the widely acclaimed book, The Fifth Discipline: The Art and Practice of The Learning Organization (1990) (over 750,000 in circulation) and co-author of three field books, The Fifth Discipline Fieldbook: Strategies and Tools for Building a Learning Organization (1994), and The Dance of Change: The Challenges to Sustaining Momentum in Learning Organizations (1999), and Schools That Learn: A Fifth Discipline Fieldbook for Educators, Parents, and Everyone Who Cares About Education(2000). Harvard Business Review has identified The Fifth Discipline as one of the seminal management books of the past 75 years. The Journal of Business Strategy named Dr. Senge as one of the 24 people who had the greatest influence on business strategy over the last 100 years. JOHN D. STERMAN, Stand
Network Edge definition (Re: An alternative to TCP (part 1))
At 09:17 08/02/2001 +0100, [EMAIL PROTECTED] wrote: >Anyway, I agree with Mr Gao that it will be usefull to have a distinguishing >name for the last network element, something like ONE "outest network element" >or END "edge netework device" or any other that may be chosen. I think the (layer 3) network edge is inside my computer, where the TCP stacks interfaces to the applications. The layer 7 network edge is even further in. A much mmore interesting edge is the edge of a control area (where the corporate edge meets the ISP edge, or where the corporate network meets my in-house network, for instance). Very few things change where my drop-cable plugs into my hub. -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED]
To whom is ICANN answerable?
I found this news report of some concern, not because of what ICANN is supposed to have done or not done, but because it seems there is a presumption by some that ICANN is answerable to US Congress. I understood that the whole purpose of setting up ICANN was to provide Internet governance that was trans-national, not answerable to US Government. #g -- "ICANN Faces Hearing in Congress Over Domain Selections" Computerworld Online (02/02/01); Thibodeau, Patrick On Feb. 8, the House Commerce Committee will hold a hearing to examine whether ICANN's approval of only seven new top level domains hampers competition. Critics of ICANN will likely request that the committee make ICANN reopen the selection process. Congress might even attempt to get the Department of Commerce to keep the new TLDs from being introduced, according to insiders. DotTV CEO Lou Kerner has been discussing the issue with the House Commerce Committee and might testify at the coming hearing. Other critics include the ACLU and many of the unsuccessful TLD applicants, several of which might take ICANN to court. Others think ICANN's limited introduction was wise. ICANN's former chairwoman, Esther Dyson, wanted to introduce more TLDs, but she sides with ICANN, saying that the organization needed to limit the number of TLDs because of technical concerns. ICANN's choice was "reasonable" at the time, asserts Dyson. "It's pretty obvious that more TLDs means more opportunity for small businesses and entrepreneurs to get meaningful domain names that reflect their business interests as well as [their] free speech interests," says Domain Name Rights Coalition President Mikki Barry. The controversy ought to be expected, as there would be no need for ICANN if there were no difficult decisions to be made, asserts Jonathan Zittrain, the co-director of the Berkman Center for Internet & Society at Harvard University. The government would not have the support of businesses if it attempted to resume control over the domain name process, asserts Rick Lane, director of e-commerce and Internet technology at the U.S. Chamber of Commerce. http://www.infoworld.com/articles/hn/xml/01/02/02/010202hnicann.xml Graham Klyne ([EMAIL PROTECTED])
Re: To whom is ICANN answerable?
>I found this news report of some concern, not because of what ICANN is >supposed to have done or not done, but because it seems there is a >presumption by some that ICANN is answerable to US Congress. I understood >that the whole purpose of setting up ICANN was to provide Internet >governance that was trans-national, not answerable to US Government. If you look at the corporate charter and articles of incorporation for ICANN, it is a California-based nonprofit public benefit corporation. There is no mention that I can find of ICANN being subject to the control of laws or policies of any governmental entities outside the U.S. The prevailing view seems to be "the Commerce Department giveth, and the Commerce Department can taketh away." Deep down, the U.S. still thinks it owns the Internet. Sigh. Cheers, RGF Robert G. Ferrell, CISSP Who goeth without humor goeth unarmed.
Re: To whom is ICANN answerable?
> I found this news report of some concern glad to hear it. but it does not seem to be an internet ENGINEERING issue. randy
Re: To whom is ICANN answerable?
--On Thursday, 08 February, 2001 10:54 + Graham Klyne <[EMAIL PROTECTED]> wrote: > I found this news report of some concern, not because of what > ICANN is supposed to have done or not done, but because it > seems there is a presumption by some that ICANN is answerable > to US Congress. I understood that the whole purpose of > setting up ICANN was to provide Internet governance that was > trans-national, not answerable to US Government. Graham (and others), Speaking for myself only... >From my point of view, one of the purposes of ICANN is to draw and deal with as much of the fire that comes from making those administrative/ political decisions about the Internet as possible, keeping it away from the IETF so we can proceed with the technical work. Whether their decisions, administration, or control structure are right or not, they have mostly succeeded in that regard: when we cycle into discussions of politics and religion on this list (ICANN-related or otherwise), it is usually our own fault. And I would encourage you to take this question and any discussion of it elsewhere, e.g., to one of the ICANN or ICANN-haters lists, rather than turning up the noise level on the IETF list again. Anyone who doesn't want to hear more about the swamp, stop reading here. Anyone looking for strong statements from me for or against ICANN might as well stop reading too -- I want to say a few things in the hope of avoiding days of flaming, but they are going to be as balanced and neutral as I can make them. First of all, without commenting on this particular story, everyone who is (or has been) concerned about the ICANN topic should be aware that its entire history, and most of its pre-history, has been characterized by various interest groups who will seek any forum they can find to advance their positions. Many of them are extremely good at manipulating the press and getting unbalanced stories published, at finding politicians who see opportunities to impress their constituents and others with how Internet-involved they are, and so on. Most of the news stories have at least some roots in the truth, but the slant, spin, or interpretations can sometimes be quite impressive. These groups and individuals run the either spectrum: some are commercially self-serving, starting from the belief that ICANN is (or could) prevent them from getting rich (or richer) or that some non-ICANN arrangement might be more favorable to them. Others see vast opportunities in the Internet for a better world: better communication, universal democracy, and so on, and believe ICANN is failing by not facilitating those goals (or demonstrating their feasibility). There are group who see ICANN as a threat to their ideas to steal the world (or a large fraction of some of its resources), and those who believe ICANN isn't doing enough, quickly enough, to prevent that. And there are groups of people who, sometimes unknowingly, believe that the laws of physics or mathematics are unfair or inconvenient and that ICANN provides an opportunity to repeal them. And, of course, there are those who believe that, if the Internet evolved into a world of NATs (where no one had to allocate addresses to be sure that they were unique) and choose-it-yourself DNS roots and structures (where no one had to worry about uniqueness of names and each structure made up its own rules for dealing with potential conflicts). Some of them just ignore ICANN and go their own ways; others feel that the Internet would be better served if ICANN self-destructed and would like to help with that. Tough situation. I, for one, am glad we (IETF) don't have to solve it. There have been times when the technical side of the community has had to take fairly strong positions with ICANN, especially when they have been under pressure to repeal laws of physics. Documents like RFC 2826 and the IAB's effort to separate infrastructure from international organizations (and politics) in the DNS (see http://www.iab.org/iab/DOCUMENTS/statement-on-infrastructure-dom ains.txt) are symptoms of that process. It has been quite painful at times, but ICANN has, at least so far, made policy decisions consistent with technical constraints as we have explained them. Now, it would clearly be better if each change in the US political tides didn't bring a new set of inquiries into ICANN with all that implies about their ability and intent to interfere. And I would be a good deal happier if the original plans for US Govt handoff of whatever authority it claimed had happened sooner. The slowness may be due to conspiracy, or incompetence, or just the friction created by all of the forms of resistance and friction (and desire to get things right) outlined above. From an IETF perspective, it probably doesn't make a lot of difference -- if you want to debate that point, please take it elsewhere. But one unfortuate reality is that ICANN needs to be located somewhere, and, wherever it is and much as
Re: To whom is ICANN answerable?
On Thu, Feb 08, 2001 at 06:21:16AM -0800, Randy Bush wrote: > > I found this news report of some concern > > glad to hear it. but it does not seem to be an internet ENGINEERING issue. > > randy > It is a constraint. It defines the limits of the practicable. David Schutt [EMAIL PROTECTED]
Re: To whom is ICANN answerable?
On Thu, Feb 08, 2001 at 10:54:45AM +, Graham Klyne wrote: > I found this news report of some concern, not because of what ICANN is > supposed to have done or not done, but because it seems there is a > presumption by some that ICANN is answerable to US Congress. I understood > that the whole purpose of setting up ICANN was to provide Internet > governance that was trans-national, not answerable to US Government. > > #g > -- > > > > > Graham Klyne > ([EMAIL PROTECTED]) > The U.S. Dept. of Commerce has control of the legacy root zone, and will likely be keeping that control for some time to come. They cannot give away that responsibility without jumping through some considerable hoops, and have made statements that they won't do this in the near future. So, anything that ICANN does w.r.t. the root zone has to be approved by DOC, thus making ICANN subject to review by the U.S. Government. David Schutt [EMAIL PROTECTED]
Re: To whom is ICANN answerable?
So, who's issue is it then? ravi. Randy Bush wrote: > > I found this news report of some concern > > glad to hear it. but it does not seem to be an internet ENGINEERING issue. > > randy
RE: An alternative to TCP (part 2)
I do agree with your point regarding the possibility of differentiated services QoS degrading router performance. In my opinion it may add slight delays in transport. However, I do see a benefit in offering more than two service levels. I guess that you can say that assured forwarding and expedited forwarding can be combined and implemented as the "real-time" service level. This is another topic of discussion though. Tina Iliff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 7:44 PM To: [EMAIL PROTECTED] Subject: RE: An alternative to TCP (part 2) > I have a question: > If the traffic class field in the IPv6 header was changed, as suggested, to > a set of flags, then how would a full gammit of differentiated services be > indicated? In other words, if there is only one flag indicating type of > service, then different levels of, for example, assured forwarding or > expedited forwarding cannot be supported or implemented. I think for the sake of routing system performance it's better to provide only two classes of services: real-time (expediated forwarding) and best-effort (classical IP service level). I think it's better not to implement assured forwarding in routing system, or the network layer but instead in the end-node system, or the transport protocol layer. Other quality of service parameter such as peak bit rate, sustained bit rate, guarranteed frame rate may be associated with the IPv6 flow label.
Re: An alternative to TCP (part 1)
Kevin Farley wrote: > So you think your PC is the edge of the Internet? Isn't that what the end-to-end principle means? -- /=\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist || |eCal Corp. |World domination should never be left to chance.| |[EMAIL PROTECTED]|| \=/
NECP
This is not meant to start any religious wars. So dont use it as an excuse. I am curious as to what happened to NECP. All the drafts have expired and there doesnt seem to be any renewal effort happening. Could someone please help me out here? cheers, jamal
RE: To whom is ICANN answerable?
Hiding under "engineering" as if it were a warm fuzzy blanket that somehow depoliticizes your work, won't help to keep the Internet open and free. Thank you Graham for posting this to this group. -Original Message- From: Randy Bush [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 08, 2001 07:21 To: Graham Klyne Cc: [EMAIL PROTECTED] Subject: Re: To whom is ICANN answerable? > I found this news report of some concern glad to hear it. but it does not seem to be an internet ENGINEERING issue. randy
Re: To whom is ICANN answerable?
>>> I found this news report of some concern >> glad to hear it. but it does not seem to be an internet ENGINEERING >> issue. > So, who's issue is it then? first, i don't know whose issue grape juice is either. i just know it's not an ietf issue. the ietf is not the internet's default garbage can. second, i suspect that the icann has mailing lists. you may want to look for them. randy
Re: To whom is ICANN answerable?
> The prevailing view seems to be "the Commerce Department giveth, and the > Commerce Department can taketh away." the major premise is false.
Re: To whom is ICANN answerable?
1. The web page of IETF which gives an overview of IETF (http://www.ietf.org/overview.html) says: > The Internet Engineering Task Force (IETF) is a large > open international community of network designers, operators, > vendors, and researchers concerned with the evolution of the > Internet architecture and the smooth operation of the Internet. > It is open to any interested individual. So, IETF is not just a body of ENGINEERING people. 2. IETF mailing list, which is a "general mailing list related to internet" need not be so much concerned about grape juice, but ICANN, may be yes. 3. As suggested by John C Klensin, I want to avoid flame-fest on this list. I will take this up in more ICANN specific forum. I will not be replying on this topic any more. regards, ravi. Randy Bush wrote: > >>> I found this news report of some concern > >> glad to hear it. but it does not seem to be an internet ENGINEERING > >> issue. > > So, who's issue is it then? > > first, i don't know whose issue grape juice is either. i just know it's not > an ietf issue. the ietf is not the internet's default garbage can. > > second, i suspect that the icann has mailing lists. you may want to look > for them. > > randy
RE: An alternative to TCP (part 1)
Yes, however, I think we have three terms here: 1. end-to-end: path from host to host 2. Network edge: Internet access edge 3. Network edge: LAN edge Maybe, start using local edge to indicate the LAN edge Tina Iliff -Original Message- From: John Stracke [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 08, 2001 9:18 AM To: [EMAIL PROTECTED] Subject: Re: An alternative to TCP (part 1) Kevin Farley wrote: > So you think your PC is the edge of the Internet? Isn't that what the end-to-end principle means? -- /=\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist || |eCal Corp. |World domination should never be left to chance.| |[EMAIL PROTECTED]|| \=/
john klensin evaluates ICANN
>From: John C Klensin <[EMAIL PROTECTED]> > >First of all, without commenting on this particular story, >everyone who is (or has been) concerned about the ICANN topic >should be aware that its entire history, and most of its >pre-history, has been characterized by various interest groups >who will seek any forum they can find to advance their >positions. Many of them are extremely good at manipulating the >press and getting unbalanced stories published, at finding >politicians who see opportunities to impress their constituents >and others with how Internet-involved they are, and so on. Most >of the news stories have at least some roots in the truth, but >the slant, spin, or interpretations can sometimes be quite >impressive. ... >choose-it-yourself DNS roots and structures (where no one had to >worry about uniqueness of names and each structure made up its >own rules for dealing with potential conflicts). Pot. Kettle. Black. -- /"\ / http://www.dnso.com \ / ASCII RIBBON CAMPAIGN / http://www.open-rsc.org X AGAINST HTML MAIL/ http://dns.vrx.net/tech/rootzone / \ AND POSTINGS/ http://www.vrx.net http://support.open-rsc.org
Re: Network Edge definition (Re: An alternative to TCP (part 1))
Harald Alvestrand wrote: > > At 09:17 08/02/2001 +0100, [EMAIL PROTECTED] wrote: > >Anyway, I agree with Mr Gao that it will be usefull to have a distinguishing > >name for the last network element, something like ONE "outest network element" > >or END "edge netework device" or any other that may be chosen. > > I think the (layer 3) network edge is inside my computer, where the TCP > stacks interfaces to the applications. The layer 7 network edge is even > further in. > > A much mmore interesting edge is the edge of a control area (where the > corporate edge meets the ISP edge, or where the corporate network meets my > in-house network, for instance). The 'edge' of the network is like the 'end' of end-to-end- it starts/ends exactly where I begin/cease to care. I.e., if you can kick it, it's hardware. if you need to muck with it, it's in the edge. Joe
Re: john klensin evaluates ICANN
you have a new email address for me to add to the sociopath filter, eh? randy
Re: An alternative to TCP (part 1)
Jun'an: Now that I have scanned through most of this thread I am going to pick up on this and reply :-) I have been in a FreeBSD driver Hell so please forgive my tardy response :-0 My bottom line thoughts after having scanned thread is have you looked at SCTP? We have just finished almost 2 years of work and it solves some if not all of your issues... Jun'an Gao wrote: > > Motivations > > 1. There are two annoying incompetence of TCP. One is that TCP does not >distinguish packet loss caused by network transmission error from that >caused by network congestion. The congestion control and avoidance mechanism >makes TCP drop its transmit window upon detecting a packet loss, thus lowers >the transmit rate even if the loss is caused by physical link transmit error. >This results in an unnecessary reduction in link bandwidth utilization, >especially in the environment of wireless physical links. This one seems to me a bit hard to solve. I think ECN is right now the only answer and it is supported by SCTP. In either case TCP or SCTP the solution is available in this form. It is not 100% and of course not totaly deployed.. but that and some of the PILC work is I think the way to go.. > >The other is that the unit of TCP sequence number is byte (octet) while the >the sequence number is only 32 bit wide. It is not a big problem for a >no-more-than-100Mbps network. But in a modern gigabit network, it takes only >about 36 seconds to consume the whole sequence number space when transmitting >at the maximum bit rate. SCTP does solve this one. Since it does not track bytes but instead Chunks. A chunk can contain close to 1 MTU of data. So in your 100Gig e-net scenario instead of 360 ms (I think I remember this is your claim) you now have 360ms X 1460 a bit longer.. but still finite.. as anything is :-0 > > 2. There is an observation that congestion control is somewhat the obligation >of routing system. If it were to be done by the end host, an end host >application might exploit UDP to avoid the congestion control of TCP. >In fact the video stream applications have caused some networkcongestion >troubles. > And this is not a good thing... Eventually you may see UDP packets dropped more often when within un-responsive packet flows > 3. Abundant IPv6 addresses, especially the 64 bit interface ID space, makes >transport layer multiplexing is somewhat unnecessary. IPv6 has the built-in >support for multiple simultaneous addresses. It further recalls the necessity >of transport layer multiplexing. And quite a number of users (would?) prefer a >new IP address in each new connection, for the sake of anonymity. I don't see how this is a big benefit.. it seems to me that ports provide a useful abstraction within the network as well as the de-muxing aspect. I know Keith Moore mentioned using a "name" with a SYN packet.. but I think a look at what the wg Rserpool is doing is beneficial in providing the fail-over that Keith mentions... > > 4. There is no checksum field in the IPv6 fixed header. The designers of IPv6 >count on link layer and transport layer error check and/or correction mechanism >to ensure data transmit reliability. So transport layer should somehow enhance >the error check and/or correction mechanism. Besides, the IPv6 authentication >header provides a much stronger data integrity check mechanism than traditional >TCP/IP checksum. A new transport protocol should try to take advantage of AH. Well, here SCTP does not do so. It uses the Adler32 sum. And the work with SCTP and IPsec is just getting going :/ > > 5. Some applications such as stream media or interactive TVs do not require >reliability that TCP provides, but need to preserve data transmission order >and the connection state for a considerable duration of packet exchange or >transmission. And here SCTP can help again. There is a extension draft currently bubbling through the IETF that allows N retransmit where N can be anywhere from 0 to ?. N is how many attempts an individual data chunk can be given. See draft-ietf-sigtran-usctp-00.txt > > 6. Doing traffic shaping at the network edge is better than on the host node for > the sake of application programming. Yes, this is what ECN helps you do... but you still need to rely on the drop packet for harsh sudden overloads of an individual router... > > Key Points > 1. Designed for IPv6. Free of constraint bestowed by IPv4. SCTP will work on both IPv6 and IPv4.. in fact you can have an individual association (something akin to a connection) that spans both an IPv6 AND an IPv4 network... > 2. No upper layer port as in TCP. This is debatable.. I don't see removing the port gains you anything. > 3. There may be a number of IPv6 addresses for a physical server, each address >is bound to one (and only one) logical network service. The services could be >re
RE: An alternative to TCP (part 1)
>Is this really a problem? Yes. >How often would a single TCP session have allocated to itself an >entire gigabit link? Think server-less backup on a Storage Area Network. >I'm not aware of any end systems or apps that generate data at this rate ( >especially for any extended length of time), much less accept it. >Maybe I'm looking at this wrong. IP-based Storage Area Networks will generate data at this rate and higher. We will have a 10 Gb Ethernet standard soon, and IP-based SAN vendors intend to be ready with NICs and storage systems that can run at that rate. Furthermore, the IEEE tends to up Ethernet by an order of magnitude every 3 years or so. That means that by 2011 we should be planning for 10,000 Gbps Ethernet. = Thought for the day: "This is no IP network. It's their love child, man" -- Dennis Hopper
Re: john klensin evaluates ICANN
> >choose-it-yourself DNS roots and structures (where no one had to > >worry about uniqueness of names and each structure made up its > >own rules for dealing with potential conflicts). > > Pot. Kettle. Black. Somebody is unclear on the concept of "metaphor" I think. I'm not aware of John attempting to choose his own root or make up his own uniqueness magic.
Re: To whom is ICANN answerable?
>> Critics of ICANN will likely request that the committee make ICANN >> reopen the selection process. ... Other critics include the ACLU and >> many of the unsuccessful TLD applicants, several of which might take >> ICANN to court. With any luck, ICANN will be replaced with something that the current critics find even more upsetting. > The controversy ought to be expected, as there would be no need for > ICANN if there were no difficult decisions to be made, asserts > Jonathan Zittrain, the co-director of the Berkman Center for Internet > & Society at Harvard University. Well, I'm glad to see there's at least one grown-up involved. Noel
Re: An alternative to TCP (part 1)
From: Mark Allman <[EMAIL PROTECTED]> Date: Wed, 07 Feb 2001 16:12:52 -0500 I am fairly unconvinced in the arguments made by Mr. Gao. However, maybe a TCPng is the wrong way to look at things. A better model, it seems to me, is the one followed by SCTP. In other words, let's build a new transport that has semantics that are different from TCP. As long as it is safe (i.e., follows good congestion control), why should we care how many of these protocols are defined? After we ensure the protocols are safe we can just let Darwinism take its course. Does SCTP really have different semantics from TCP? I thought it was more of a superset. - Ted
Re: An alternative to TCP (part 1)
> My bottom line thoughts after having scanned thread is > have you looked at SCTP? We have just finished almost > 2 years of work and it solves some if not all of your > issues... Before I posted the long (and maybe annoying~_~) essays about ATP I've reviewed a few of the articles about the enhancement to TCP, and other (reliable or partial-order) transport protocols, namely SCTP, RTP+UDP, RTSP+UDP (although RTSP is not designed as a pure transport layer protocol, and may run over transport protocol such as RDP other than UDP) and XTP. It is said that TP4 is obselete so I haven't reviewed it. I think the enhancements of TCP are effective and quite easy to be implemented in a small set of hosts, but unlikely to be adequately deployed in the wide Internet in a duration shorter than migrating IPv4 to IPv6. So why not make a new transport protocol optimized for IPv6 instead of patching TCP? The migration costs may be on the same level while the benefits may not. I think XTP is low efficient. SCTP is a functional superset of TCP, RTP+UDP and RTSP+UDP in the unicast scenario. Different points of SCTP and ATP are: 1. ECN. (But no way to prevent SCTP to exploit ECN). I think explicit congestion notification is a fundamental enhancement to TCP. It is developed later than SCTP. As far as I perceive SCTP had no chance of taking into account the rationales of backward or forward ECN (and early congestion detection), administion control and traffic shaping when it was firstly designed. Behind adopting ECN in ATP there is an observation: Choose the right entity to do the right thing. ECN is not a pure end2end issue, so does ATP. ATP counts on the routing system to CONTROL congestion and cooperates with the routing system to AVOID congestion. 2. Negative Acknowledgement (and the motivation behind it). There is no send timeout except when sending the connection initiating packet (SYN packet) in ATP. The sender resends a packet only at the explicit request of the receiver. That is, the time-out clock is moved to the receiver side. At first sight it makes no difference. Imagine a welcomed network application service encounts heavy load. A request sent by a client may be dropped because the upper layer application cannot handle it. In this case the client has to abort, considerably slow-down or resend the request. The user won't feel well if to abort or slow down while resending the request is not a good news for the heavy-loaded server, maybe nor a good news for some intermediate routers. Or the request may be acknowledged by the transport layer protocol engine. The acknowledgement may make the transport layer such as TCP engine increase its send window (congest window). Thus the client may increase its transmit rate, which is not a good news for the heavy-loaded server. We may call such a problem 'upper layer application congestion' or 'application layer congestion'. It isn't uncommon for ftp or http servers to limit the number of simultaneoues connected users to avoid the application layer congestion. Yet how much TCP should be condemned for the performance degradation in the heavy load time is itself problematic. Though it is expected that ATP may solve such a problem, I have not make it a motivation of ATP. 3. SCTP intrinsically supports multi-homed site. ATP doesn't. The reason: it is still unclear how to support multi-home in IPv6 environment without trading off routing hierarchy (I think the proposal of Jieyun (Jessica) Yu is a good feasible choice 'IPv6 Multihoming with Route Aggregation', draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt). I think SCTP is superior in this point. 4. SCTP supports multi-streams in a single connection. I cannot perceive the necessity clearly. 5. The raise of the consideration of consolidating the key features of RSVP, ISAKMP, IPSec and IPComp in the unicast scenario. I have yet no clear idea about how to do the job in ATP.
unsubcribe me !!
Hello all, I have been reading up a few mails on this group n found that it was too above my head, so i would kindly request youi to unsubscribe me. Regards Sourav = Sourav Sengupta __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
RE: An alternative to TCP (part 1)
>As long as it is safe (i.e., follows good congestion control), >why should we care how many of these protocols are defined? After >we ensure the protocols are safe we can just let Darwinism take its >course. Because a customer with sufficient $ would inevitably request the Frobnitz Transport, since it garnered the IETF imprimateur and the code base would eventually collapse under the weight of all this "innovation". Thought for the day: "If farmers can be paid not to grow wheat, why can't IETF WGs be paid not to develop protocols?"
