- NANOG - lists.nanog.org

GeekTools SuperWhois update
by Rodney Joffe 16 Jun '99

16 Jun '99

Hello: There is a new version of GeekTools SuperWhois available at www.geektools.com. This is a significant revision which now deals with (as best as we know) the 6 competitive registrars for the .com .net and .org space as well as obfuscated ip addresses. A whois query for anything in .com, .net, or .org will first query the shared whois system to identify which registrar has the registration, and then query that registrar's whois server. The only registrar currently registering domains appears to be Register.com. GeekTools SuperWhois now deals with obfuscated ip addresses (decimal rather than dotted quad) used commonly by spammers. Enter the query in the same way as a normal ip address. The command line SuperWhois proxy (whois.geektools.com) as well as the web based SuperWhois gui have been updated. The updated SuperWhois source will be available shortly, as version 2.1. As always, comments, queries, updates, and suggestions, to complaints(a)geektools.com. -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"

1 0

sparse vs dense and multicast
by smd＠clock.org 15 Jun '99

15 Jun '99

danny(a)qwest.net wrote: | and are you suggesting that dense-mode (blindly distributing), to coin the | term, is more efficient than say, sparse-mode (multicast?) .. not even in your You are misusing two reasonably well-known terms used in the IP multicast world today. You could easily argue that the PIM use of "sparse" and "dense" is gross and in some way wrong, however they are understood to be very different from dense = "blindly distributing" and "sparse" = "undefined but maybe multicast". In particular, in PIM [DEFJLW 94] a sparse group is one in which only a few widely-scattered receivers have joined a given group, while a dense group is one in which most multicast routers are likely to have at least one receiver joined to the group. The sparseness vs denseness of a group helps one decide if flood-and-prune is efficient or whether it is more efficient for an explicit join towards the root of the [local-]spanning tree to succeed before traffic is sent. Doing the latter on a dense group obviously, can result in a join implosion towards the [local] root of the spanning tree, while doing the former on a sparse group results in the arrival of lots of unnecessary traffic prior to the issuance of [lots of] prune messages. "dense-mode" and "sparse-mode" are PIM terms: with PIM any group can be declared sparse or dense. The use of "ip pim sparse-mode" etc. as an interface command in IOS is often confusing. Making the terms worse by further overloading them is unhelpful. | -danny (who won't waste any additional time in this thread) That's probably wise. Sean.

1 0

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 15 Jun '99

15 Jun '99

In reply to message by Danny McPherson <danny(a)qwest.net>: Danny, boy, who the hell are you? You certainly picked the wrong tree to bark at. Go ask someone who knows me (like Vab) to make sure i'm not a newbie and know what i'm talking about. >Ahh, I see. Everything sux, but give me cash (pun intended :-) and I'll give >you cold fusion. It only means that i do not want to discuss patentable things in a public forum. BTW, if you did a little bit of research you'd find that i was directly involved in building backbones in 50-something countries (including the first commercial T-3/OC-3 backbone) and founded few companies in backbone / router equipment space (and, yes, i did invent few things like terabit routers). > many to many, perhaps it does have it's challenges. one to many, it works > today. We have a different understanding of what constitutes "working". See also the comment about flying pigs. > Summary: It sux, I can't can't tell you why, but it just sux! I have no intention to deliver lectures on computer science here. Go buy a textbook and learn a thing or two on computational complexity. Then we can have a meaningful discussion. (As a side note - i find the ignorance of engineering professionals about basic facts of the underlying science quite alarming; i guess the american educational system puts too much emphasis on skills and too little on the broader cirriculum, particularly mathematics. The very fact that engineering people tend to dismiss logical conclusions as opinions, instead of trying to find flaws in the logic, is a clear indicator of the absymal state of overall comprehension of the scientific methodology). > However, if he sends enough mail to NANOG, he'll likely find someone to fund > even shoving a rocket up a dogs ass :-) My last startup raised $23M and is doing fine (www.pluris.com) thanks. --vadim

2 1

RE: Is anyone actually USING IP QoS?
by Vadim Antonov 15 Jun '99

15 Jun '99

Jamie Scheinblum <jamie(a)fast.net> wrote: > While this thread is slowly drifting, I disagree with your assertion that so > much of the web traffic is cacheable (nlanr's caching effort, if I remember, > only got around 60% of requests hit in the cache, pooled over a large number > of clients. That probably should be the correct percentage of cacheable > content on the net). Well, there is a big difference between being cacheable and being delivered more than once to the same locale during some period of time (aka cache hit). A lot of things are cacheable but never result in a cache hit simply because these things are low-demand. Actually, 60% hit rate is rather impressive; it is much better than you can get if you restrict time window for content replication to few milliseconds. (In multicasting world the equivalent of cache hit is a packet being duplicated). > If anything, the net is moving to be *more* dynamic. Unlikely. The transport is becoming cheaper. Content production doesn't. This means that the same content is likely to be viewed by a larger audience. >The problem is that web sites are putting unrealistic expires on images and >html files because they're being driven by ad revenues. The big thing byte-wise are images. The ad agencies could do much better (and annoy people much less) if they provided cacheable images (probably embedded into non-cacheable HTML pages few dozens of bytes long, to ensure accountability). If they won't cooperate at some point the disparity between delivery speeds of cached content (which does not stress source servers) and the centrally-served ads will become large enough for people to start using ad filters (several are already available) to get significant percieved performance improvements. It is in the best interest of advertisers to make sure ads are delivered fast. Of course, the caches may help by providing adequate reporting, when requested. > The only way caching is going to truly be viable in the next 5 years is > either by a commercial company stepping in and working with commercial > content providers (which is happening now), or webserver software vendors > work with content companies on truly embracing a hit reporting protocol. So far the driving force behind cache deployment were ISPs. For them caching represents significant savings and lets to improve perceived quality of service by reducing content retrieval latency. With more and more hi-bandwidth content, the edge web servers will run of gas and will become the bottlenecks. (The current bottleneck is still in the packet transport, which is going to be fixed with DWDM and massively parallel routers). In other words, the real effect of cacheing is not in bandwidth savings (this is significant, but not really important) but in spreading popular content, thus removing hot spots and increasing real network performance (which is, btw, measured in user-visible latency, not in bandwidth). The existing cacheing experiments show as much as 3x improvement in median file retrieval times. > So basically, my assertion is that L4 caching on any protocol will not work > if the content provider is given any control of TTL and metrics. Well, messing up caches is against the objective interests of the content providers. They may be ignorant of that (some of them are... i talked once with the chief technical guy of one of the largest internet advertisement company), but they are going to be reminded about the realities when cacheing becomes ubiquotus and the difference between cacheing-friendly and cacheing-averse advertisers becomes apparent to a large audience. And, anyway, advertisers are shifting to click-thru accounting from eyeball accounting. > The only > way web caching *really* works is when people get aggressive and ignore the > expire tags from a network administrator point of view, not a content > company's. That's only because of lack of a useful reporting protocol. That is a technical issue and can be fixed. > Further, the > more you rely on L4 implementations for caching, the more it seems you would > be open to broken implementations... Although that is a broad statement... That is a valid statement. However, there are no fundamental problems. --vadim

1 0

Re: Is anyone actually USING IP QoS?
by smd＠clock.org 15 Jun '99

15 Jun '99

Vijay Gill wrote: | "You are | supposed to fall down into The Avici Hell because of your evil karma, and | experience the acute suffering without any respite. [...] | In the feverish Hell of heat, the offenders will experience | sudden heat waves, which are brought about by the hot wind." Didn't someone famous recently leave UUNET for Avici? I wonder how he's doing. (He's been very quiet. So much for hot wind). Sean.

1 0

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 15 Jun '99

15 Jun '99

Vijay Gill <wrath(a)cs.umbc.edu> wrote: >> Scalability on the Internet pretty much means that algorithms should run >> in O(log(N)**M) where N is the total number of end-points and M is >> constant. (Note that non-CIDR unicast routing doesn't fit this >> criterion, but CIDR does). > Reference to this? I guess it's my private rule-of-thumb. (Antique Kleinrock and Klein, maybe?) Anyway, O(N) seems to be infeasible (as at least some network components will have to scale at super-Moore's law exponential rates), and O(log(N)) - too strict (all dynamic routing algorithms are super-linear, but still work). The design based on O(P(log(N))) algorithms was demonstrated to work in practice (DV of SPF with route aggregation). O(P(N)) (non-hierarchial routing) was demonstrated to fail during the CIDR deployment saga. >The pressure is being applied now. Vendors however had a lock on this >market, witness how long it took for cisco to give oc-12 atm interfaces. >They didn't move till uunet put the GRF into the core. The pressure is called competition :) Unfortunately, large switching equipment vendors still didn't get a clue on how to build real fast routers. (Nortel may be an exception, with their stake in Avici; however i have serious misgivings about ability of Avici design to deliver on promises. Hypertorus is not what one wants to use for general permutations. And i find their claim to be inventors of massively parallel routing simply hilarious. Obviously, their marketing department employs Al Gore as a PR consultant. Never mind that the only reference to the name "Avici" i was able to find is the particularly hot kind of hell in Buddhist mythology :) --vadim

2 1

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 15 Jun '99

15 Jun '99

Brett_Watson(a)enron.net wrote: >>Please. Caching is _at least_ as efficient as multicasting (multicasting >>_is_ caching, with zero retention time) - w/o associated security and >>scalability problems. >>research or data to support these assertions? Just bare logics (a lost art in the modern datacom world, i guess). Make this gedunkenexperiment: take each mcast packet replicating point and replace it with a cache with very small retention time. The thing will replicate data in exactly the same way; and the packets will flow along the same paths. Therefore it is _at least_ as efficient. (Note that i do not consider possibility of building mcast trees dependent on traffic or bandwidth reservation - the algorithmic complexity involved makes that an intractable problem (it is believed to be NP-complete in general case); even the best heuristic algorithms for such planning place it beyond realm of computable for the networks fraction of size of present Internet). >and how does caching magically negate security and scalability concerns? Caching is not employing any routing information exchange. Therefore it is a) oblivious to the state of other caches or to the changes in network topology and b) is invulnerable to the bogus routing information and flap-like DoS attacks. >what tools are you using to do content replication/management that scale to >thousands of hosts/caches? 99% of Web content is write-once. It does not need any fancy management. The remaining 1% can be delivered end-to-end. (BTW, i do consider intelligent cache-synchronization development efforts seriously misguided; there's a much simpler and much more scalable solution to the cache performance problem. If someone wants to invest, i'd like to talk about it :) >even if i assume caching is as efficient, or >more so, than multicast, i'm still just trading one set of >security/scalability concerns for others. caching is no more a silver >bullet than multicast. It is not that caching is a silver bullet, it is rather that multicating is unuseable at a large scale. >i won't deny the potential scalability problems but i think your >generalizing/oversimplifying to say caching just works and has no security >or scalability concerns. Well, philosophical note: science is _all_ about generalizing. For an inventor of perpetuum mobile the flat refusal of a modern physicist to look into details to assert that it will not work sure looks as an oversimplifying. After all, the details of actual construction sure are a lot more complex than the second law of thermodynamics. In this case, i just do not care to go into details of implementations. The L2/L3 mcasting is not scalable and _cannot be made_ scalable for reasons having nothing to do with deficiencies of protocols. Caching algorithms do not have similar limitations, solely because they do not rely on distributed computations. So they have a chance of working. Of course, nothing "just works". --vadim PS To those who point that provider ABC already sells mcast service: there's an old saying at NASA that with enough thrust even pigs can fly. However, no reactively propulsed hog is likely to make it to an orbit all on its own.

1 0

Re: Is anyone actually USING IP QoS?
by Barry Dykes 15 Jun '99

15 Jun '99

> > But multicst suppose to do perlication at the L2 level, where you have no > information about the context, about _time to expire_ (how multicast > helps you to decrease traffic in case of AUDIO-ON-DEMAND_ if I ask some > nw song, and you ask the same song 10 seconds later - but remember, such > requests are no popular then _Live audio_ requests except some events). > If case of _caching on the fly_ you have all L4 (not L3 but L4) > information, it's flexible level and vendor can easily add _time to > expire_ into his live stream. Layer 2, Layer 3 - there is a difference but I'll not go into that now. In the case of the "ON-DEMAND" scenario, you are basically talking about unicast no matter how you slice it. It by "ON-DEMAND" you are speaking of a window of subscription, then you could still use multicast. However, when you are speaking of just caching without multicast, your asking for NxT (where N is the number of caches and T is the time that it takes to send one packet to *each* cache) of delay between the first recipient and the last. Of course if NxT is greater than the actual packet gap that is being utilized, then you are pretty much screwed with just one stream. Add a couple of simultaneous streams and it gets pretty funny. However, lets assume that you are really doing this same dispersion of information via multicast, the need for dealing with NxT is removed as well as the inter packet gap problem being reduced. Of course this doesn't fit your unicast "ON-DEMAND" model - but that's why it's called multicast. > Just again, multicasting is the END of L4 caÓhing, not the beginning. And > when I analyse existing network, I saw the useless of multicasting > _except_ some special cases (such as some live streams in case of > important events). I wouldn't say "end vs beginning" as much as I would say - "different applications." The only thing that caching really does is aggregate the source of collection. It has moved from many hosts gathering the unicast information to many servers gathering it. It really has changed the crux of the problem since the more servers you end up having the more it looks like hosts again. And remember this is still with regard to a single *stream* of info that without multicast is being sent N times. > > And I think the idea _to start from multicsting_ was wrong from th first > moment of time. Unless of course your intention is to reduce bandwidth consumption as much as possible and also maintain some reasonable degree of latency. If none of this is your issue, then caching (unicast) is just fine. > You should END by multicasting - when you ahev a network > of media sources, a network of media customers, the set of policies > installed over the world - you can use multicasting locally to improve > the local throughput. But try to build multicast network this days - the > thouthand of hackers will be happy -:), and a lot of ISP refuse to > cooperate... Yea, fortunately hackers leave unicast and caches alone... > > PS. I never saw the multimedia really need multicasting on the L2 level > -:). But I see a lot of multimedia where L4 caching can improve quality > dramatically. Every day. However, I have never seen a cache make more efficient use of a LAN either. And yes if you have bandwidth problems then caching can make things look much better. However, if your bandwidth problems are because you are unicasting all that multicast capable traffic (say maybe sending the same update to a thousand different servers) then you could save money on bandwidth, have shorter update times, and not worry so much about QoS - That was the source of this thread wasn't it :-) > > > > > > >I think blaming vendors for inability to build products which run faster > > >than the proven lower boundaries for the required kind of algorithms is, > > >er, strange. > > > > i won't deny the potential scalability problems but i think your > > generalizing/oversimplifying to say caching just works and has no security > > or scalability concerns. > It's amazing, but please name ANY securyty concern appeared due to WWW > caching -:). It's not ideal solution (you can't cache SSL sessions, for > example, through you can cache signed or crypted sessions - image PRP > crypted multimedia session, for example), but I can't remember any > security problem with it. WWW traffic sucks for multicast and I think it's a poor example. However, since multicast is really only concerned with layer three, then the security of it needs to be done with the application. Hey, kind of like security for caching :-) Oh, and could you send back some *live* video from the moon - via multicast. I wouldn't want you to have to update all those individual caches via unicast over that 1200 baud connection from the space ship :-) Barry

1 0

Re: Is anyone actually USING IP QoS?
by Danny McPherson 15 Jun '99

15 Jun '99

> Do i miss something perhaps :-) > Please. Caching is _at least_ as efficient as multicasting (multicasting > _is_ caching, with zero retention time) - w/o associated security and > scalability problems. Great, please do clue me in. I wasn't aware that you'd corrected all the issues with caching, and somehow defied physics wrt the process of "duplicate bits" on a wire not actually utilizing b/w. > Presenting L2/L3 multicasting as the best or the only > or even a meaningful way to reduce transmission duplication is quite wrong. I don't recall anyone doing that. They're both good ideas, they both need work. > A primary concern is the absense (and most likely, impossibility) of any L2/L3 > multicast routing scheme capable of supporting any significant number of > mcast trees. Oh, and caching has no problems? I believe they're addressing two _slightly_ different problems. > Scalability on the Internet pretty much means that algorithms should run in > O(log(N)**M) where N is the total number of end-points and M is constant. > (Note that non-CIDR unicast routing doesn't fit this criterion, but CIDR does). Perhaps O(log(N)**M) does apply to unicast, but the multicast model should differ. I'd agree that in an ideal state, sure, looks good, but... > The benefits of mining cheap cheese on the Moon are quite obvious. If you're > willing to overlook the small fact that the Moon isn't made from cheese. I'm with Brett, never been to the moon.. > _No_ technological advances can help the fact that L2/L3 multicasts cannot > be routed in a scalable fashion. Think what happens when there is 1mil > multicast trees in the network. and 10 billion caching servers won't give you even one extra bit to the end-user. -danny

1 0

Re: Is anyone actually USING IP QoS?
by Brett_Watson＠enron.net 15 Jun '99

15 Jun '99

On 06/15/99 10:13:44 AM Vadim Antonov wrote: > >Please. Caching is _at least_ as efficient as multicasting (multicasting >_is_ caching, with zero retention time) - w/o associated security and >scalability problems. Presenting L2/L3 multicasting as the best or the only >or even a meaningful way to reduce transmission duplication is quite wrong. research or data to support these assertions? and how does caching magically negate security and scalability concerns? what tools are you using to do content replication/management that scale to thousands of hosts/caches? even if i assume caching is as efficient, or more so, than multicast, i'm still just trading one set of security/scalability concerns for others. caching is no more a silver bullet than multicast. >>The benefits are obivous though and router vendors are definitely progressing, >>but as with any technology, debugging and getting the protocols to a usable >>state, one to which SLA/SLGs can be assoicated, takes time. > >The benefits of mining cheap cheese on the Moon are quite obvious. If you're >willing to overlook the small fact that the Moon isn't made from cheese. well, i can't deny this assertion, although i've never been to the moon. >_No_ technological advances can help the fact that L2/L3 multicasts cannot >be routed in a scalable fashion. Think what happens when there is 1mil >multicast trees in the network. > >I think blaming vendors for inability to build products which run faster >than the proven lower boundaries for the required kind of algorithms is, >er, strange. i won't deny the potential scalability problems but i think your generalizing/oversimplifying to say caching just works and has no security or scalability concerns. -brett

2 1