- Test - lists.nanog.org

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

19 May '99

Clark Gaylord <cgaylord(a)cns.vt.edu> wrote: > I doubt that evan Vadim is ignorant enough to be saying ATM never > worked ... not the usual statement one would make of the default > campus core technology. The last time i checked the default campus core technology was Ethernet. Anyway, there's a saying at NASA (thanks, Milo :) that given enough thrust even pigs can fly. What i said is not that ATM cannot be made to work in some limited environments, but rather that it is going to the junkyard of overhyped technologies which tured out to be more expensive and less reliable than simpler and dumber rivals. --vadim

2 1

Re: Is anyone actually USING IP QoS?
by Alex P. Rudnev 19 May '99

19 May '99

Sorry, but Windows-XXXX can realise not more than client's part of RSVP. RSVP's troubles are not the protocol itself (through it's TERRIBLE); it's not the problem for the router to realise some kind oc custom queuering with some garanteed bandwidth and latency for the selected stream; the problem is _how to make decision about such reservation_. And other problem - I can easily use RSVP over the client's link, but i's easy and more understandable to use some precedence with the static stream list, to allow customer run VOIP or/and RV applications over the well loaded link (note - RSVP is to complex for this case, 99% of such tasks can be solved by the precedense or static access lists); I don't need RSVP on the internal links because they can't be saturated (they are cheap); I can't use RSVP on the inter-ISP links because there is nothing about policy in RSVP standard and CISCO. This means - Win-2000 can send RSVP requests, no doubt; but who is ready to proceed such requests? > > (RSVP). > > RSVP isn't dead. It'll be released in the next Windows 200x, which > isn't to say that the implementation is good or bad, just that RAPI > will finally be available to your average codesmith. The problem > that this brings up is overuse of a good thing. For example, your > Oracle application can signal a particular reservation but what > happens when you have lots (10K) of users making that same reservation > at once? It's a difficult problem because they're not all using that The question is - how I prefere one user against another. While some external (tac_plus daemon or radius daemon) process can't be used for developing such requests, they are useless; and RSVP does not help to solve this problem at all. May be, in future. It's dead because no one use it now. May be, it'll be not dead in future. _USE_ - I mean provider, not client's program. Again - poit us ANYONE who does use QoS management other then CAR or filtering or custom queuering. I could not found anyone; may be, someone is lucky? > > Anyway, no one answer to the initial question. I guess no one here use > > complex QoS features, except primitive (CAR, RED, WFQ) ones. > > Actually, that's not particularly true. But I can't really speak on > that subject other than to say that the people I work for are > starting to see the light about ATM's weaknesses when "native" ATM > applications are built. Unfortunately, I've yet to see an implementation > of ISSLL adaptations. > > > -scooter > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

Re: Is anyone actually USING IP QoS?
by Alex P. Rudnev 19 May '99

19 May '99

I meant circuits, not Internet. On Wed, 19 May 1999, Jon Zeeff wrote: > Date: Wed, 19 May 1999 09:23:00 -0400 (EDT) > From: Jon Zeeff <jon(a)zeeff.com> > To: "Alex P. Rudnev" <alex(a)Relcom.EU.net> > Cc: steriley(a)microsoft.com, nanog(a)merit.edu > Subject: Re: Is anyone actually USING IP QoS? > > > > When I order bandwidth, I got BANDWIDTH. Just what I asked. > > You are lucky. Every end user I know who has ordered "Internet" bandwidth, > has, on occasion, gotten packet loss and poor latency to some end points. > Ie, non bandwidth. > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

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