Print 

Gigabit Ethernet Rides Economy of Scale

As It Erases LAN WAN Boundary Gigabit Ethernet Makes Network Less Complex, Easier to Manage -- 10 Gig Standards Will Demand Choices Affecting ATM SONET WAN Functionality

pp 1-10, 27

We interviewed Dan Dov Principal Engineer for LAN physical Layers with Hewlett-Packard's networks division and Mark Thompson product marketing manager for HP's ProCurve Networking Business on December 6. In Smart Letter 30 on 12/9/99 David Isenberg wrote the following very good summary of why Gigabit Ethernet is hot. "Since there are many more LANs than WANs, GigE, due to its Ethernet LAN heritage, has huge economies of scale. (Every flavor of Ethernet that has hit the marketplace has slid down a 30% per year price reduction curve.) GigE's use in both LAN and WAN gives greater scale yet. Plus by erasing the LAN/WAN boundary, GigE decreases the complexity of the network, making it even stupider, easier to manage and easier to innovate upon. So it looks like the Stupid Network will be built of GigE over glass."

In the Interview Dov takes us through the technology reasons for Ethernet's increase in speed as its importance in LANs has grown and LANs themselves get larger and more bandwidth hungry. Ethernet, in short, is leveraging its ubiquity, low cost and open standards on the back of the growing importance of the Internet and its increased bandwidth. In doing so it is playing a significant role in making new industries like Application Service provision possible.

Dov concludes that "the reason that the Ethernet succeeded as well as it has, its simplicity. Ethernet is a very simple, yet elegant protocol. But because of its simplicity, it's extremely inexpensive to develop and to manufacture Ethernet-compliant devices." Many people are taking gigabit Ethernet and applying it to wide area networking because of its simplicity, ease of access and simplicity of its framing.

In its relationship between volume and pricing Gigabit Ethernet offers significant values. Gigabit Ethernet initially was being installed in the local area network to provide interconnection between boxes that were connecting 100 megabits, and 10megabits, to the desktop. The volume of that kind of traffic quickly becomes very large. For these applications over short distances, compared to OC-24, gigabit Ethernet is actually cheaper, even though it provides more bandwidth. What people started to realize, because of the volume of gigabit Ethernet traffic that was going out and the relative simplicity of it, the cost of gigabit Ethernet ran under cut that of OC-24 pretty quickly. And the result is that people who are making the decisions as to what will be used to hook LANs to each other and to the Internet started deciding to go with gigabit Ethernet, rather than with the OC-24 or OC-48. Gigabit Ethernet's application is at the periphery of the internet Therefore it is not being looked tofor the elimination of SONET add/drop multiplexers.

With ten gigabit Ethernet some people are proposing to basically take the ten gigabit Ethernet media access controller, the MAC, and packetize the data, just like we currently do in Ethernet at ten times the rate. But they then want to send it into a SONET framer. The SONET framer will then take that data and chop it up and put it into the SONET frame. The framer will send it across the network and when it gets received on the other side, it will be effectively deframed. There are also people that are more focused on taking the current, simple Ethernet approach, which is just, take the data, put it onto an optical fiber and ship it on across the link. They don't want to get into the complexity of SONET framing and so on.

HP's Thompson offered the following analogy: " It's sort of like the subway system versus the inter city train system. Once, historically, if you wanted to ride the "train" from the center of one city to the center of another, you rode the subway system to get out to the train station, took a train and then subway back into a city. So what we're talking about now is Ethernet making it robust enough and fast enough so that your subway car can simply ride from one city to the next and that you don't have to change the vehicles that are riding on the tracks, the fiber, in the meantime." In other words a simplistic design that would work for the people who are working in the local area networks would also go for people who wanted to do optical transmission with Ethernet framing cross- country" The interview concludes with a discussion of the issues being faced in the development of 10 gigabit Ethernet standards

Explosion in Capacity Chased by Explosion in Use Fiber to the Home from HP Oracle and Power Companies For Less than $15 a Month -- Abovenet on the Need to Own Fiber

pp.10, 27

As price on IRU's for large bandwidth circuits drop, David Rand of AboveNet explains the need to hold fiber. An explanation that seems to be well verified by announcements from Sierra Pacific, HP, and Oracle of their joint project to make fiber to the home available in southern Nevada this summer for $15 a month. Announcement by Delta Airlines and Ford Motor Company of subsidized PC o\wnership and internet use for all employees also look to be the opening shots of another huge driver of bandwidth demand.

Role of Diffserv in the Development of QoS Tools

Kathy Nichols Explains How Pursuit of Viable QoS Protocols Is Transitioning from Centralized Model to Horizontally Organized Tool Chest from which ISPs Can Design Cross ISP Compatible Services

pp. 11 -19, 27

On November 16, we interviewed Kathy Nichols who with Brian Carpenter is co-chair of the very active Diffserv working group. We asked Kathy to put Diffserv in its historical context. She replied that originally people assumed that Quality of Service guarantees would be needed to do multimedia over the Internet. Integrated Services and RSVP came out of these assumptions. But RSVP had been designed by Lixia Zhang and others while Lixia was at Xerox Parc. The design was made with the assumption that you could put RSVP state into every router because you would always keep your application inside the network of a single provider. After several years of experimentation the emerging view is that RSVP should be seen as a generic signaling protocol or a way for a host to talk to a network. Other protocols would govern ways that hosts request things of a network to which they are talking. One should note that the original work with RSVP and Intserv was done before April 1995 when the NSFNet backbone was shut off and when the topology and traffic on the internet to which people were thinking about applying quality of service were radically different that what they are now (almost exactly five years later).

By the beginning of 1997 some ISPs were beginning to talk of QoS in terms of being able to give some of the traffic that they carried better treatment than other traffic a kind of better best effort. According to Kathy "the Differentiated Services discussion happened because some service providers were not happy with the Intserv approach. They weren't going to let state cross their boundary. They didn't see how something with that much state could work. And it also didn't seem to do exactly what they wanted, which included to be able to tell a customer that they could replace their leased line and give them at least equivalent service. And it would be a good deal, because they should be able to offer it cheaper and reuse their infrastructure."

Traffic for a premium class of service could be relegated into special queues for that traffic alone. Traffic for best effort and better best effort could remain in the same queue. In most network conditions the packets would be treated the same while in exceptional conditions the mere best effort packets might find themselves discriminated against. Some of the very best engineers and protocol designers in the Internet were coming up with schemes for how to do traffic marking and shaping to accomplish these goals. (The idea that the same queue can be used to have two different levels of service is the idea behind weighted RED.) Unfortunately their schemes - call them tools perhaps - were too often incompatible with each other. People were designing complex tools to work handle vast amounts of traffic in complex and rapidly changing situations. Diffserv was started as a way to bring order out of a very complex chaos. People wanted to structure a framework for which people could design their tools and to create a situation where if they designed them to be compatible with the framework they would be compatible and interoperable with each other. Diffserv may be thought of as a set of guidelines within which various quality of service tools may be implemented.

Kathy states that the only way to scale QoS is to aggregate packets. If we group them inside of a "cloud" or domain, we will put them into something called a "behavior aggregate." You create a behavior aggregate by saying that you will assign each packet that is to be a member of that aggregate a particular per hop behavior (PHB). PHB permits the assigning of the same forwarding treatment for all network traffic that labeled with a given PHB. You may then consider telling customers that they will pay a certain rate for traffic sent in conformance with the PHB aggregate they have purchased and let them know that your routers will drop traffic labelled as conformant with a given PHB that in reality is found by the router to be non conformant. One goal is to get the maximum amount of classification of what may be done with traffic out of a field that is no more than 6 bits per packet. What Diffserv is really doing for ISPs and for hardware vendor is helping them to work together to establish reasonable guidelines within which many different quality of service provisions can created. The idea is that the ISP is allowed to establish its own QoS offerings. Diffserv has created behavior aggregates and control planes that can be used to implement the policy goals of the behavior aggregate. Two ISP may be able to solve cross ISP policy issues by sitting down with each other and selecting Diffserv compatible tools that would not have to be the exact same tool. It is Diffserv's intention to give them tools by which they can achieve common QoS outcomes by means that inside their respective networks may be quite different.

All Responsibility Disintermediated from DNS Fix

New ICANN DOC Shared Registry System Enables Registrars, Shared Registry and ICANN to Disclaim Responsibility for All Actions that injure Registrants

pp. 20 - 26

In mid January Wired http://www.wired.com/news/technology/0,1282,33753,00.html published a delightful summary of the results of Beckwith Burr', ICANN's, and NSI's redesign of the DNS system. People were buying a domain name and paying for it at the time of purchase only to see it sold out from underneath them the very next day to someone else. For the little guy the Internet's domain name system had been put at risk by the Clinton Gore bureaucrats. No mater: the large, powerful and rich had the ICANN Uniform Dispute Resolution Policy and the even more Draconian cyber squatting legislation. ICANN had done a superb job of freeing the corporate trademark attorneys to do their thing. It had done this by creating a jury-rigged system where registrars could say that mistakes belonged to the registry which in turn could say it was playing by ICANN rules while ICANN disclaimed all responsibility for breakages in the system.

According to Wired, "ICANN said it was not responsible for domain name discrepancies between registrars and their customers.

The COOK Report reminds its readers that to be functional a domain name must be part of the registry database that determines what other names are taken and is responsible for getting the names into the root servers where down line DNS servers can find them. The operation of the new system has been rigged by ICANN so that, while the registry gets names to advertise, it gets no information about the owners of the names in whose interest it is doing the advertisement. This information is known to the Registrars whose agreements with ICANN give them enforceable rights vis-à-vis the Registry. But the customers who pay a registrar to act as the intermediary between them and the registry have no enforceable rights what so ever to the use of the domain names for which they pay.

We do not know who designed and put in place this truly bizarre system. It was ICANN. But the secret process by which it was done inside of ICANN has remained opaque to everyone on the outside. As far as we can tell, ICANN rules by having its Jones Day attorneys, Touton and Sims work with Esther Dyson and Mike Roberts to establish policy that disenfranchises every Internet user (who does not also pay the necessary fees to become a registrar) of any rights to receive the benefits of the products for which they have paid. The registrar is fee to do anything it chooses with the domain name that it sells to the registrant. The system is also dependent for its operation on a shared registry protocol that has been (according to the testimony of some outside experts who advised NSI on its design) implemented in such a way as to make any accountability to the registrants and even to the registrars unlikely. NSI has sought what non experts will take as endorsement from the IETF by asking for publication of the protocol as an informational RFC. One of the experts who advised NSI in the design has protested loudly against the move and asked NSI to free him from his non disclosure agreement so that he may publish his criticism to allow independent observers to make their own judgements. NSI has refused.

By the end of the month it was clear that the entire shared registry system was a design failure. As early as late December complaints of break downs were becoming evident. On December 23 on the Domain policy list at NSI list member "A" complained " Most whois clients query the public NSI Registry database first which only updates *once per day* so it's quite possible for someone to do a domain query and be shown the old whois information of the old registrar. Nothing is wrong.

To which list member "B" replied: No, nothing is wrong as far as the design goes. But of course that [just looking at the design] is not far enough, is it? Therefore leaving the ability for registrars to "Steal" domain names and/or create a domain name conflict from the get go. Doesn't say much for stability, does it? Our article summarizes debate from the IETF and Domain Policy lists that makes quite clear the absurdity that the White House and its ice president is visiting upon the Internet.

Froomkin and Auerbach Offer Eloquent testimony to ICANN's Most Recent Failures

pp. 27, 29, 30

Two who have tried to work with ICANN say foul in no uncertain and bitter terms to move by DNSO to censor DNSO GA mail list. ICANN Makes it clear it will tolerate no criticism.