- Test - lists.nanog.org

RE: Is anyone actually USING IP QoS?
by Andrew Odlyzko 19 May '99

19 May '99

Before throwing in my two cents' worth of comments, let me state that I used to believe in the need for QoS and usage-sensitive pricing (which go hand in hand). However, extensive studies of the economics of data networks and usage patterns have changed my mind, at least when it comes to the backbones of the Internet. The exchanges of Hank Nussbacher and Steve Riley have brought up the key issue that prices of transmission capacity play. However, some crucial issues have not been discussed. I expect that (i) prices will decrease, and that (ii) networks will be run at low utilization levels, making QoS unnecessary. However, (ii) does not follow from (i) directly. After all, how do we know that all those big new pipes won't get filled as soon as they are put into service? It has been pretty solidly established (see [1], for example) that on average people spend a constant amount of time traveling. You build a freeway, and now instead of driving 30 minutes over 10 miles of congested city streets, people decide they will buy a bigger house with more greenery in the suburbs and drive 30 minutes over 25 miles of freeway. In the last 30 years, the average commute time in the U.S. has not changed appreciably, but the distance traveled has gone up. Complaints about road congestion have not gotten less, though, as far as I can tell. It is not a priori inconceivable that this same phenomenon will not operate on the Internet. My argument for why (ii) will follow from (i) is based on studies of what people actually do. (The data and arguments are presented in detail in [2].) In particular, on expensive trans-oceanic links, even corporate private lines are congested. On the other hand, in the U.S., private lines are in most cases run at low fractions of their capacity. University connections to the Internet vary all over the lot in their utilization in the U.S., while in other countries they tend to be congested. What that suggests is that what people value is low transaction latency ("I want that Web page on my screen NOW," or "I want my database query to be processed NOW"), and not lots of bits. When prices are high, they put up with lousy quality, but when prices are lower, at the level of U.S. domestic prices, they opt for the quality they really want. That is what makes me think that the Internet is not like freeways, and that indeed we will have uniformly high quality IP transport without most of the QoS measures that are being developed. The Internet evolving to avoid QoS should not be too surprising. The computer industry was cited in these discussions by Steve Riley and others. It is an instructive example. There were all sorts of prioritization and pricing schemes for mainframes in computer centers. (One of the most interesting ones was due to two of my former colleagues [3]. It not only had some nice theoretical optimality properties, but was actually implemented at the Murray Hill Computer Center of AT&T Bell Labs, and worked very well to produce essentially full utilization of computing resources.) However, those guys aren't famous. The reason is that we don't have computer centers any more. They got displaced by PCs, which are run at ludicrously low fractions of their capacity. This "waste" is tolerated because people want the peak power of their 500 MHz Pentium III to bring up their PowerPoint presentations, etc. The key issue is the utility that people get from a resource (CPU power, transmission capacity, etc.) and their willingness to pay for it. The evidence from data networks is that it won't make much of a decrease in transmission prices to produce lower utilization rates and better quality. Another argument I make against QoS is that it pretty much requires usage-sensitive pricing. However, that is something that people dislike, and are willing to pay quite a bit to avoid. (See [4] for discussion, models, and references.) Finally, while I am skeptical of QoS, I should emphasize that I do see important roles for some forms of it in certain situations. One is in access networks, especially in the wireless area. It appears that there will continue to be a huge mismatch between the bandwidth available on fiber and over the air. Hence wireless bandwidth will be a (relatively) scare resource, and so it probably makes sense to ration it through QoS measures. The other role that I see for QoS is in the core of the network, but in forms that do not require any involvement on the part of the people at the edges of the network (both end users and administrators). Nothing is ever free, and while prices of transmission capacity are likely to plunge, total spending is likely to go up. That is what happened with computers, printers, etc. Thus there will still be an incentive to economize, but it will have to be done in ways that do not burden too many people. (Hence RED should be OK, since its operations are invisible to end users, but asking those folks to prioritize their packets is not likely to fly.) Again, we see that in other areas. Most folks could save at least half of their disk space by compressing with any of the widely available packages, but hardly any do. On the other hand, we do have many highly trained experts working on improvements to MPEG compression algorithms. References: [1] A. Schafer and D. Victor, The past and future of global mobility, Scientific American, Oct. 1997. Available at <http://www.sciam.com/1097issue/1097schafer.html>. [2] The economics of the Internet: Utility, utilization, pricing, and Quality of Service, A. M. Odlyzko. Available at http://www.research.att.com/~amo/doc/networks.html. [3] W. A. Gale and R. Koenker, Pricing interactive computer services, Computer Journal, vol. 27, no. 1 (1984), pp. 8-17. [4] Fixed fee versus unit pricing for information goods: competition, equilibria, and price wars, P. C. Fishburn, A. M. Odlyzko, and R. C. Siders, First Monday 2(7) (July 1997), http://www.firstmonday.dk/. Also available at http://www.research.att.com/~amo/doc/eworld.html. Addendum: Current high prices are already less of a problem than many folks claim. Hank Nussbacher cites as the extreme example of T3 pricing the $400K/month that a Tokyo-LA link costs. Now a T3 running at full capacity will transmit just about 15 TB (terabytes) in each direction per month. Let's suppose that we run the LA to Tokyo direction at 53% of capacity, so we will transport 8 TB. The quality won't be the greatest, but many carriers tolerate even higher utilizations on such high-cost links. That will give us a cost (ignoring traffic in the other direction) of $0.05 per MB. Now in the U.S., with the flat-rate modem access to the Internet at $20/month (and no local call fees, which constrain usage in other countries), the average customer downloads about 60 MB per month. (One way to derive that type of estimate is to take the average 55 minutes per day that AOL folks have been clocking recently, according to an AOL press release, and factor in an average data transfer rate of about 5 Kbps, about 20% of the maximal 28.8 modem rate.) Hence even if the Tokyo residential modem customers behaved like AOL ones here in the U.S., and all their Web surfing was in the U.S., the cost of transporting their traffic across the Pacific would still be only $3/month. ************************************************************************ Andrew Odlyzko amo(a)research.att.com AT&T Labs - Research voice: 973-360-8410 http://www.research.att.com/~amo fax: 973-360-8178 ************************************************************************

2 1

RE: Is anyone actually USING IP QoS?
by Steve Riley (MCS) 19 May '99

19 May '99

Hmm. It was interesting to read the various replies both on the list and personal. A number of people pointed out, rightly, that I'm thinking of the USA. That's true. They further gave examples of the exhorbitant costs that people elsewhere in the world pay for connections. While I certainly understand the desire to use some form of QoS to squeeze every bit of capacity from expensive skinny pipes, I believe that it is wrong to try to use a technological solution (usually poorly understood and implemented) to solve what is primarily a political problem. There is absolutely no technological reason why international rates are so much higher than domestic US rates. Regarding the idea of "free bandwidth," that's not what I said. I said that bandwidth is "essentially free." Of course there will always be a cost for bandwidth. But consider for a moment what's happened to disk storage. In 1990 I purchased my first PC. I paid $550 for an 80 MB hard drive -- that's $6.875 per megabyte. Today you can purchase a 25 GB hard drive for $450 -- that's $0.018 per megabyte. That's a 31,250% increase in capacity accompanied by a 99.73% reduction in price per megabyte. So you see, on a per megabyte basis, storage is "essentially free." The same thing has happened to CPU and memory. It will happen to bandwidth, too, and in many cases already has. For a time I worked in information technology architecture. One of the tennents of that field is that it's always cheaper to trade capacity for staff. You can overbuild now, while planning for growth, and save money over the alternative of continually tweaking and making minor improvements and upgrades which requires expensive time and personnel. QoS is an acceptable idea which in certain specific situations might be suitable for solving an existing problem. But since QoS is expensive to manage it simply is not viable in the long term. We in the networking and telecommunications industries need to redirect our energy away from bandages and instead toward making abundant bandwidth readily available to everyone. _________________________________________________________ Steve Riley Microsoft Telecommunications Practice in Denver, Colorado email: mailto:steriley@microsoft.com call: +1 303 521-4129 (cellular) page: +1 888 440-6249 or mailto:4406249@skytel.com Applying computer technology is simply finding the right wrench to pound in the correct screw. -----Original Message----- From: Vadim Antonov [mailto:avg@kotovnik.com] Sent: Monday, May 17, 1999 4:29 PM To: nanog(a)merit.edu; Steve Riley (MCS) Subject: RE: Is anyone actually USING IP QoS? Steve Riley (MCS) <steriley(a)microsoft.com> wrote: >Nice to see that I'm not the only one believing in the foolishness of QoS >hype. Er... me, agreeing with someone from Microsoft? Yeech! (just kidding :) >Allow me to point you to an interesting paper called "Rise of the Stupid >Network." Unfortunately that paper oversimplifies the whole congestion control issue by completely ignoring the fact that data traffic has a heavy-tailed distribution. Which pretty much means that no matter how much capacity is there, as long as there's oversubscription there will be at least transient traffic jams. Which means that the issue of what to do with different types of traffic when there's a congestion cannot be just pooh-poohed. The big problem with G.711 and its progeny is the lack of effective cooperative congestion control which would guarantee network stability (like TCP does). Fortunately, the bulk of network traffic is "canned" content, which can (and should) be transmitted with TCP. --vadim

9 8

Re: Is anyone actually USING IP QoS?
by Sean Donelan 19 May '99

19 May '99

nbastin(a)rbbsystems.COM (Nick Bastin) writes: >I'll concede this point. However, it's worth pointing out that >megabytes of disk space can actually be 'had', while bandwidth doesn't >really exist. Most of us, at least, have to pay for bandwidth by the >month, while we only pay for the same piece of storage space once (and >then we actually posess it). This is important because it impacts how >far this cost model can be extended, and for how long. Once upon a time you used to buy CPU seconds from the campus computer center at an exhorbitant rate. Now you just buy the whole CPU, and waste most of it running a screen saver of South Park characters making rude noises. Actually you can buy "bandwidth" much the same way. Stop thinking about buying 'bandwidth' in T1 or E3 size chunks, and instead think about buying 15,000 route miles of fiber for the flat fee of $20million. Ok, so that seems like a lot of money. Think of the difference between renting an apartment or buying a house, structure the financing correctly and the monthly payments are fairly reasonable. Throw in DWM advances in the last couple of years, and you can now sell 80 times more. Trans-oceanic fiber costs more, about $150million, and more political hurdles, but you can do much the same thing. The 'holy grail' of QOS has little to do with delivering bits, and a lot to do with pricing models. Personally I think QOS could be very successfull at the customer ingress/egress points, but it doesn't make a whole lot of sense anywhere in the middle. QOS is all about letting the customer buy more or less service than they could normally afford. Like the used car salesperson, the carrier wants to find the largest easy monthly payment you are willing to pay, for the worst piece of junk he can move off his lot. But in the middle, it is almost always cheaper and more efficient for the carrier just to throw more bandwidth at the problem. Bandwidth becomes a sunk cost, with a very short shelf-life. Next week, most of the QOS folks will be meeting down in San Francisco instead of Eugene. http://www.stardust.com/qosforum/ QOS has become such a marketing term, I hesitate to use it anymore. But it would take a much longer message for me to describe what I mean by QOS. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

RE: Is anyone actually USING IP QoS?
by Steve Riley (MCS) 19 May '99

19 May '99

Nice to see that I'm not the only one believing in the foolishness of QoS hype. Bandwidth is essentially free, and will always be cheaper than QoS. And since in the end nearly all decisions are based on economics, it should be apparent which is the more logical decision. Allow me to point you to an interesting paper called "Rise of the Stupid Network." Many of you here may have already seen this. It was written back in 1997 by David Isenberg, then a reasearcher at AT&T Labs (Isenberg is now an independent consultant). His paper profoundly changed my views on QoS and made me realize that networks perform best when we limit how smart they get and ensure that networks focus on transport only. I urge everyone to read it. Paper: http://www.rageboy.com/stupidnet.html Isenberg's site: http://www.isen.com/ _________________________________________________________ Steve Riley Microsoft Telecommunications Practice in Denver, Colorado email: mailto:steriley@microsoft.com call: +1 303 521-4129 (cellular) page: +1 888 440-6249 or mailto:4406249@skytel.com Applying computer technology is simply finding the right wrench to pound in the correct screw. -----Original Message----- From: Vadim Antonov [mailto:avg@kotovnik.com] Sent: Monday, May 17, 1999 12:28 PM To: nanog(a)merit.edu; pete(a)kruckenberg.com Subject: Re: Is anyone actually USING IP QoS? Yep. Altough not _all_ QoS schemes are broken-as-designed. The most trivial per-packet priority combined with ingress priority mix shaping works. Ths idea of end-to-end whatever reservations or guarantees is usually propounded by people who either neglected their CS courses or those who are trying to sell it. Yep. The biggest QoS secret is that nobody actually needs it. Bandwidth is cheap and is growing cheaper. The manpower needed to deploy and maintain QoS is getting more and more expensive. --vadim

8 10

Re: Routing loop between Qwest and Sprint?
by Sean Donelan 19 May '99

19 May '99

The routing loops I mentioned have been resolved. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Routing loop between Qwest and Sprint?
by Sean Donelan 18 May '99

18 May '99

>That'd lead me to believe that it's likely an issue internal to Sprint's >network, perhaps your query would be best directed to their NOC, versus NANOG. > I'd guess the greater majority of the NANOG distribution doesn't have access >to Sprint routers, so it's unlikely that they'll be able to correct the >problem. > >Directing your query to the Sprint NOC, or even Qwest NOC, is definitely much >more appropriate, assuming your concern is wrt regaining connectivity this >destination.. I tried opening a ticket by phone with Qwest's NOC. Guess what, I'm not a Qwest customer, so they couldn't find my account. I did send a message to Sprint. I haven't received a response from Sprint yet. I think if you check around, you'll find for those providers I have agreements with, I usually work out hairy problems with their senior network engineers pretty quickly, in private. For those providers who ditch me at their first-level support, I don't see an issue with bringing up the problem in other forum because I've found it helps get the problem fixed. However, like many things with routing, it is a bit simplistic to just say it is an issue internal to Sprint's network. It usually takes two providers to screw up inter-provider routing. This particular type of routing problem isn't that unusual, but it always seems to take a day for the two providers to stop saying call the other provider, and to actually clean everything up. It appears that Qwest announced a large set of more specific routes at one point in time for the CIDR block 205.169.0.0/16. Qwest tried to correct this at a later point, but it appears the problem in the software on some Sprint routers lost some of the route withdraws. odra-22>show ip bgp 205.169.153.240 255.255.0.0 longer [...] Network Next Hop Metric LocPrf Weight Path *>i205.169.0.0/16 192.41.177.120 100 0 286 209 i * 204.70.27.9 90 0 3561 209 i * 144.232.129.97 90 0 1239 209 i *> 205.169.17.0 144.232.129.97 90 0 1239 209 i *>i205.169.19.0 192.41.177.120 100 0 286 209 104 i * 204.70.27.9 90 0 3561 209 104 i * 144.232.129.97 90 0 1239 209 104 i *> 205.169.20.0 144.232.129.97 90 0 1239 209 i *> 205.169.21.0 144.232.129.97 90 0 1239 209 i *> 205.169.22.0 144.232.129.97 90 0 1239 209 i *> 205.169.23.0 144.232.129.97 90 0 1239 209 i *> 205.169.24.0 144.232.129.97 90 0 1239 209 i *> 205.169.25.0 144.232.129.97 90 0 1239 209 i *> 205.169.26.0 144.232.129.97 90 0 1239 209 i *> 205.169.27.0 144.232.129.97 90 0 1239 209 i *> 205.169.28.0 144.232.129.97 90 0 1239 209 i *> 205.169.29.0 144.232.129.97 90 0 1239 209 i *> 205.169.30.0 144.232.129.97 90 0 1239 209 i *> 205.169.37.0 144.232.129.97 90 0 1239 209 i *> 205.169.39.0 144.232.129.97 90 0 1239 209 i *> 205.169.40.0 144.232.129.97 90 0 1239 209 i *> 205.169.41.0 144.232.129.97 90 0 1239 209 i *> 205.169.42.0 144.232.129.97 90 0 1239 209 i *> 205.169.43.0 144.232.129.97 90 0 1239 209 i *> 205.169.45.0 144.232.129.97 90 0 1239 209 i *>i205.169.47.0 192.41.177.120 100 0 286 209 i * 144.232.129.97 90 0 1239 209 i * 204.70.27.9 90 0 3561 209 i *> 205.169.48.0 144.232.129.97 90 0 1239 209 i *> 205.169.49.0 144.232.129.97 90 0 1239 209 i *> 205.169.50.0 144.232.129.97 90 0 1239 209 i *> 205.169.51.0 144.232.129.97 90 0 1239 209 i *> 205.169.54.0 144.232.129.97 90 0 1239 209 i *> 205.169.55.0 144.232.129.97 90 0 1239 209 i *> 205.169.63.0 144.232.129.97 90 0 1239 209 i *> 205.169.68.0 144.232.129.97 90 0 1239 209 i *> 205.169.97.0 144.232.129.97 90 0 1239 209 i *> 205.169.101.0 144.232.129.97 90 0 1239 209 i *> 205.169.102.0 144.232.129.97 90 0 1239 209 i *> 205.169.105.0 144.232.129.97 90 0 1239 209 i *> 205.169.106.0 144.232.129.97 90 0 1239 209 i *> 205.169.107.0 144.232.129.97 90 0 1239 209 i *> 205.169.108.0 144.232.129.97 90 0 1239 209 i *> 205.169.112.0 144.232.129.97 90 0 1239 209 i *> 205.169.121.0 144.232.129.97 90 0 1239 209 i *> 205.169.122.0 144.232.129.97 90 0 1239 209 i *> 205.169.123.0 144.232.129.97 90 0 1239 209 i *> 205.169.124.0 144.232.129.97 90 0 1239 209 i *> 205.169.127.0 144.232.129.97 90 0 1239 209 i *> 205.169.134.0 144.232.129.97 90 0 1239 209 i *> 205.169.136.0 144.232.129.97 90 0 1239 209 i *> 205.169.137.0 144.232.129.97 90 0 1239 209 i *> 205.169.149.0 144.232.129.97 90 0 1239 209 i *> 205.169.153.0 144.232.129.97 90 0 1239 209 i *> 205.169.155.0 144.232.129.97 90 0 1239 209 i *> 205.169.158.0 144.232.129.97 90 0 1239 209 i *> 205.169.160.0 144.232.129.97 90 0 1239 209 i *> 205.169.163.0 144.232.129.97 90 0 1239 209 i *> 205.169.164.0 144.232.129.97 90 0 1239 209 i *> 205.169.165.0 144.232.129.97 90 0 1239 209 i *> 205.169.166.0 144.232.129.97 90 0 1239 209 i *> 205.169.170.0 144.232.129.97 90 0 1239 209 i *> 205.169.171.0 144.232.129.97 90 0 1239 209 i *> 205.169.174.0 144.232.129.97 90 0 1239 209 i *> 205.169.175.0 144.232.129.97 90 0 1239 209 i *> 205.169.177.0 144.232.129.97 90 0 1239 209 i *> 205.169.179.0 144.232.129.97 90 0 1239 209 i *> 205.169.180.0 144.232.129.97 90 0 1239 209 i *> 205.169.185.0 144.232.129.97 90 0 1239 209 i *> 205.169.188.0 144.232.129.97 90 0 1239 209 i *> 205.169.192.0 144.232.129.97 90 0 1239 209 i *> 205.169.198.0 144.232.129.97 90 0 1239 209 i *> 205.169.199.0 144.232.129.97 90 0 1239 209 i *> 205.169.200.0 144.232.129.97 90 0 1239 209 i *> 205.169.201.0 144.232.129.97 90 0 1239 209 i *> 205.169.203.0 144.232.129.97 90 0 1239 209 i *> 205.169.204.0 144.232.129.97 90 0 1239 209 i *> 205.169.205.0 144.232.129.97 90 0 1239 209 i *> 205.169.206.0 144.232.129.97 90 0 1239 209 i *> 205.169.207.0 144.232.129.97 90 0 1239 209 i *> 205.169.208.0 144.232.129.97 90 0 1239 209 i *> 205.169.210.0 144.232.129.97 90 0 1239 209 i *> 205.169.219.0 144.232.129.97 90 0 1239 209 i *> 205.169.222.0 144.232.129.97 90 0 1239 209 i *> 205.169.223.0 144.232.129.97 90 0 1239 209 i *> 205.169.226.0 144.232.129.97 90 0 1239 209 i *> 205.169.227.0 144.232.129.97 90 0 1239 209 i *> 205.169.228.0 144.232.129.97 90 0 1239 209 i *> 205.169.231.0 144.232.129.97 90 0 1239 209 i *> 205.169.232.0 144.232.129.97 90 0 1239 209 i *> 205.169.233.0 144.232.129.97 90 0 1239 209 i *> 205.169.234.0 144.232.129.97 90 0 1239 209 i *> 205.169.235.0 144.232.129.97 90 0 1239 209 i *> 205.169.237.0 144.232.129.97 90 0 1239 209 i *> 205.169.239.0 144.232.129.97 90 0 1239 209 i *> 205.169.245.0 144.232.129.97 90 0 1239 209 i *> 205.169.247.0 144.232.129.97 90 0 1239 209 i *> 205.169.251.0 144.232.129.97 90 0 1239 209 i *> 205.169.252.0 144.232.129.97 90 0 1239 209 i *> 205.169.254.0 144.232.129.97 90 0 1239 209 i odra-22> q later in the day, after my nanog message, it appears someone cleaned up that particular route. Notice the difference in the table below, 205.269.153.0 is no longer listed as a more specific. However, the other more specifics continued to be announced by Sprint. odra-22>show ip bgp 205.169.153.240 255.255.0.0 longer [...] Network Next Hop Metric LocPrf Weight Path *>i205.169.0.0/16 192.41.177.120 100 0 286 209 i * 204.70.27.9 90 0 3561 209 i * 144.232.129.97 90 0 1239 209 i *> 205.169.17.0 144.232.129.97 90 0 1239 209 i *>i205.169.19.0 192.41.177.120 100 0 286 209 104 i * 204.70.27.9 90 0 3561 209 104 i * 144.232.129.97 90 0 1239 209 104 i *> 205.169.20.0 144.232.129.97 90 0 1239 209 i *> 205.169.21.0 144.232.129.97 90 0 1239 209 i *> 205.169.22.0 144.232.129.97 90 0 1239 209 i *> 205.169.23.0 144.232.129.97 90 0 1239 209 i *> 205.169.24.0 144.232.129.97 90 0 1239 209 i *> 205.169.25.0 144.232.129.97 90 0 1239 209 i *> 205.169.26.0 144.232.129.97 90 0 1239 209 i *> 205.169.27.0 144.232.129.97 90 0 1239 209 i *> 205.169.28.0 144.232.129.97 90 0 1239 209 i *> 205.169.29.0 144.232.129.97 90 0 1239 209 i *> 205.169.30.0 144.232.129.97 90 0 1239 209 i *> 205.169.37.0 144.232.129.97 90 0 1239 209 i *> 205.169.39.0 144.232.129.97 90 0 1239 209 i *> 205.169.40.0 144.232.129.97 90 0 1239 209 i *> 205.169.41.0 144.232.129.97 90 0 1239 209 i *> 205.169.42.0 144.232.129.97 90 0 1239 209 i *> 205.169.43.0 144.232.129.97 90 0 1239 209 i *> 205.169.45.0 144.232.129.97 90 0 1239 209 i *>i205.169.47.0 192.41.177.120 100 0 286 209 i * 144.232.129.97 90 0 1239 209 i * 204.70.27.9 90 0 3561 209 i *> 205.169.48.0 144.232.129.97 90 0 1239 209 i *> 205.169.49.0 144.232.129.97 90 0 1239 209 i *> 205.169.50.0 144.232.129.97 90 0 1239 209 i *> 205.169.51.0 144.232.129.97 90 0 1239 209 i *> 205.169.54.0 144.232.129.97 90 0 1239 209 i *> 205.169.55.0 144.232.129.97 90 0 1239 209 i *> 205.169.63.0 144.232.129.97 90 0 1239 209 i *> 205.169.68.0 144.232.129.97 90 0 1239 209 i *> 205.169.97.0 144.232.129.97 90 0 1239 209 i *> 205.169.101.0 144.232.129.97 90 0 1239 209 i *> 205.169.102.0 144.232.129.97 90 0 1239 209 i *> 205.169.105.0 144.232.129.97 90 0 1239 209 i *> 205.169.106.0 144.232.129.97 90 0 1239 209 i *> 205.169.107.0 144.232.129.97 90 0 1239 209 i *> 205.169.108.0 144.232.129.97 90 0 1239 209 i *> 205.169.112.0 144.232.129.97 90 0 1239 209 i *> 205.169.121.0 144.232.129.97 90 0 1239 209 i *> 205.169.122.0 144.232.129.97 90 0 1239 209 i *> 205.169.123.0 144.232.129.97 90 0 1239 209 i *> 205.169.124.0 144.232.129.97 90 0 1239 209 i *> 205.169.127.0 144.232.129.97 90 0 1239 209 i *> 205.169.134.0 144.232.129.97 90 0 1239 209 i *> 205.169.136.0 144.232.129.97 90 0 1239 209 i *> 205.169.137.0 144.232.129.97 90 0 1239 209 i *> 205.169.149.0 144.232.129.97 90 0 1239 209 i *> 205.169.153.0 144.232.129.97 90 0 1239 209 i *> 205.169.155.0 144.232.129.97 90 0 1239 209 i *> 205.169.158.0 144.232.129.97 90 0 1239 209 i *> 205.169.160.0 144.232.129.97 90 0 1239 209 i *> 205.169.163.0 144.232.129.97 90 0 1239 209 i *> 205.169.164.0 144.232.129.97 90 0 1239 209 i *> 205.169.165.0 144.232.129.97 90 0 1239 209 i *> 205.169.166.0 144.232.129.97 90 0 1239 209 i *> 205.169.170.0 144.232.129.97 90 0 1239 209 i *> 205.169.171.0 144.232.129.97 90 0 1239 209 i *> 205.169.174.0 144.232.129.97 90 0 1239 209 i *> 205.169.175.0 144.232.129.97 90 0 1239 209 i *> 205.169.177.0 144.232.129.97 90 0 1239 209 i *> 205.169.179.0 144.232.129.97 90 0 1239 209 i *> 205.169.180.0 144.232.129.97 90 0 1239 209 i *> 205.169.185.0 144.232.129.97 90 0 1239 209 i *> 205.169.188.0 144.232.129.97 90 0 1239 209 i *> 205.169.192.0 144.232.129.97 90 0 1239 209 i *> 205.169.198.0 144.232.129.97 90 0 1239 209 i *> 205.169.199.0 144.232.129.97 90 0 1239 209 i *> 205.169.200.0 144.232.129.97 90 0 1239 209 i *> 205.169.201.0 144.232.129.97 90 0 1239 209 i *> 205.169.203.0 144.232.129.97 90 0 1239 209 i *> 205.169.204.0 144.232.129.97 90 0 1239 209 i *> 205.169.205.0 144.232.129.97 90 0 1239 209 i *> 205.169.206.0 144.232.129.97 90 0 1239 209 i *> 205.169.207.0 144.232.129.97 90 0 1239 209 i *> 205.169.208.0 144.232.129.97 90 0 1239 209 i *> 205.169.210.0 144.232.129.97 90 0 1239 209 i *> 205.169.219.0 144.232.129.97 90 0 1239 209 i *> 205.169.222.0 144.232.129.97 90 0 1239 209 i *> 205.169.223.0 144.232.129.97 90 0 1239 209 i *> 205.169.226.0 144.232.129.97 90 0 1239 209 i *> 205.169.227.0 144.232.129.97 90 0 1239 209 i *> 205.169.228.0 144.232.129.97 90 0 1239 209 i *> 205.169.231.0 144.232.129.97 90 0 1239 209 i *> 205.169.232.0 144.232.129.97 90 0 1239 209 i *> 205.169.233.0 144.232.129.97 90 0 1239 209 i *> 205.169.234.0 144.232.129.97 90 0 1239 209 i *> 205.169.235.0 144.232.129.97 90 0 1239 209 i *> 205.169.237.0 144.232.129.97 90 0 1239 209 i *> 205.169.239.0 144.232.129.97 90 0 1239 209 i *> 205.169.245.0 144.232.129.97 90 0 1239 209 i *> 205.169.247.0 144.232.129.97 90 0 1239 209 i *> 205.169.251.0 144.232.129.97 90 0 1239 209 i *> 205.169.252.0 144.232.129.97 90 0 1239 209 i *> 205.169.254.0 144.232.129.97 90 0 1239 209 i odra-22> q This afternoon, it appears someone has done some more cleanup. But hasn't gotten all of the more specifics yet. odra-22>show ip bgp 205.169.153.240 255.255.0.0 longer [...] Network Next Hop Metric LocPrf Weight Path *>i205.169.0.0/16 192.41.177.120 100 0 286 209 i * 204.70.27.9 90 0 3561 209 i * 144.232.129.97 90 0 1239 209 i *>i205.169.19.0 192.41.177.120 100 0 286 209 104 i * 204.70.27.9 90 0 3561 209 104 i * 144.232.129.97 90 0 1239 209 104 i *> 205.169.20.0 144.232.129.97 90 0 1239 209 i *>i205.169.47.0 192.41.177.120 100 0 286 209 i * 144.232.129.97 90 0 1239 209 i * 204.70.27.9 90 0 3561 209 i *> 205.169.48.0 144.232.129.97 90 0 1239 209 i *> 205.169.49.0 144.232.129.97 90 0 1239 209 i *> 205.169.50.0 144.232.129.97 90 0 1239 209 i *> 205.169.51.0 144.232.129.97 90 0 1239 209 i *> 205.169.54.0 144.232.129.97 90 0 1239 209 i *> 205.169.121.0 144.232.129.97 90 0 1239 209 i *> 205.169.134.0 144.232.129.97 90 0 1239 209 i *> 205.169.164.0 144.232.129.97 90 0 1239 209 i *> 205.169.223.0 144.232.129.97 90 0 1239 209 i *> 205.169.237.0 144.232.129.97 90 0 1239 209 i *> 205.169.239.0 144.232.129.97 90 0 1239 209 i odra-22>q -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 18 May '99

18 May '99

Oleg Tabarovsky <olg(a)amt.ru> wrote: >Current state of IP multicast technology development looks more and more >similar to ATM stuff, both in development speed and complexity. >The same end ? :-) Yep. Simply people try to patch fundamental problems with hacks. That never worked, but then, that fact never discouraged from trying. Particularly when there's a significant population of marks who believe everything written in the trade rags. >Proper inter-domain multicast implementation will make state >volume manageable. Handwaving. How is it going to make it manageable, exactly? >> In any case, L3 mcasting seems to be pretty much dead. Replicating >> canned content is better done with caches, and conferencing requiries >> real MCUs which do things like speaker selection and noise suppression. >What about broadcasting ? Caches will not help. They particularly help in case of broadcasting, because content reuse rate is high. You can think of multicasting as of caching where each cache has zero retention time. (Caches do not have to delay delivery until the entire file/stream is loaded). >And, IMHO, any real life conferencing can pretty well live without multicast at all. Yep. I would say it is hard to implement a useful multiparty conferencing _with_ multicasting. (Yes, i'm fed up with H.323, H.225, H.245, Q.931, RTP, G.711, G.729, CSTA, TAPI, Megaco/MGCP, and the rest of the crap). --vadim

2 1

RE: Is anyone actually USING IP QoS?
by Vadim Antonov 18 May '99

18 May '99

Alex Rudnev wrote: >On the other hand, why don't provide QoS in the non-overbooked network. >It's not difficult to install PRECEDENCE queue-control, just as negotiate >about some classes of service, to prevent short network bursts from >disturbing multimedia streams. Actually, it makes sense to do per-packet drop priority as opposed to precedence priority; in this case edge routers can arbitrarily tweak packet priorities w/o worrying about packet reordering in the network. >I'd like to ask one more question. Multicast, >Then someone else send second request. Why (WHY) can't RV server add >second DST address into the packet? Why can't you use the same, unicast, >address space for multicast services. Because IP multicasts are broken as designed? Actually, there are two multicasting approaches which use unicast address space to identify the multicasting channel: the Express multicast by David Cheriton & Co (Stanford U) and my earlier TRAP proposal. Both are significantly more scalable than the existing IP mcast; and the TRAP one has a property of not keeping any state in gateways which do not perform any packet replication. In any case, L3 mcasting seems to be pretty much dead. Replicating canned content is better done with caches, and conferencing requiries real MCUs which do things like speaker selection and noise suppression. Injection of end user-supplied routing information (JOIN/LEAVE requests) into the core backbones is not going to work in a real life, period. --vadim

2 1

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 18 May '99

18 May '99

"John A. Tamplin" <jat(a)LiveOnTheNet.COM> wrote: >This is assumes that the number of hosts attached are constant. If the >number of hosts grow exponentially, then the bandwidth required of the >network will grow faster than exponentially. I didn't notice any exponential growth of hosts in my home (although my bandwidth grew from 14.4 to a T-1 meanwhile). The exponential growth of _connected_ hosts was mostly fueled by connecting existing machines and by new computer users. Unless you have a recipe for getting people to breed much faster the end of that trend is pretty much in sight (witness PC makers killing themselves in scramble to the way-less-than-affluent market). --vadim PS. If you do know that secret recipe please keep it secret :)

1 0

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 18 May '99

18 May '99

Pete Kruckenberg <pete(a)kruckenberg.com> wrote: >I think it is naive to assume that just because there is an >over-supply of bandwidth today that it will be that way >forever. Some assume, some do something to make sure it's going to be like that :) >Who knows when this will happen. With every dial-up customer >moving to DSL, cable and wireless, and stuff like voice and >video moving to IP-based networks, seems like it'll happen >sooner rather than later. I know at least one company which is going to be in field trials this year with the technology which can actually handle traffic in case if every household in US gets a T-1. >At 1000% annual growth rates >(according to Lord Sidgemore) in bandwidth usage, 1000%/yr sounds like BS. 200-400% is more like it. Reality check - see how backbones grow, not what marketing people say. >it'll be only a matter of a few years, even with >yet-to-be-deployed and yet-to-be-developed DWDM >enhancements. Never underestimate bandwidth of 1 sq ft. bundle of fibers. Even if no advances are made in WDM or femtosecond optical valve technology the petabit-per-second networks can still be built for cost comparable to the cost of POTS. --vadim PS Trend-wise speaking, backbones are catching up with host performance. Before long, hosts will become the bottleneck, not the network. After that, network growth will follow the same trend line as hosts: i.e. Moore's law performance increases with pretty much fixed cost.

1 0