- Test - lists.nanog.org

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

16 Jun '99

On 06/15/99 01:23:16 PM Vadim Antonov wrote: >Brett_Watson(a)enron.net wrote: > >>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. i'll give you that. however, caches tend to run under unix-like os's which are multi-user and multi-service machines. they can be susceptible to DoS attacks, and can be running services listening on a port which can potentially be "hacked". my only point is that you are trading a set of security issues in multicast for *different* security issues with a cache. > >>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. it's very different in our network. we have lots of static content (on-demand real-video, mpeg, etc) which is injected to a set of distributed servers around the network from content originators. the content originators may be traditional content providers such as those found on the internet but they may be a 3-letter television networks (broadcast television), post-production video houses, etc. we have to do content management, aging, etc for large volumes of data. we also have to keep systems synchronized with content (contrary to your next statement which i don't agree with). > >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". right, they don't have "similar limitation" they have *different* limitations which wasn't what you seemed to be saying. -brett

1 0

RE: multicast seen as equivalent of caching packets
by Jamie Scheinblum 16 Jun '99

16 Jun '99

The problem I think is getting cooperation. If you do replication on top of the existing non-multicast internet you would have to build a network on top of existing routing. Which it seems to me would mean either a new hierarchy of data transport needs to be built (new peering, etc), or the source sender ends up sending content to n first level nodes on a small height tree, which offers no great advantage. I always thought the advantage of multicast was that it minimized the number of receivers the source sent content to. Packet caching in multicast seems to be at the advantage that if any multicast router had caching enabled, everyone in the tree would benefit, if I followed Sean's summary correctly. -jamie > -----Original Message----- > From: Alex P. Rudnev [SMTP:alex@Relcom.EU.net] > Sent: Wednesday, June 16, 1999 6:29 AM > To: smd(a)clock.org > Cc: avg(a)kotovnik.com; jamie(a)fast.net; nanog(a)merit.edu > Subject: Re: multicast seen as equivalent of caching packets > > > Sorry; it was my assertion in this tread -:). Through it change nothing... > > Why don't start fron the replication/reflection, then go to the > short-time-caching, may be to the long-time-caching, and then only to the > multicasting. Those who is playing around multicasting now looks amazing > - they build a complex, twisted routing schema with the PIM, etc etc to > deliver usially ONE data stream to the ONE customer -:). May be, to the > two customers. And then ask _why don't another want to play with them_. > > This was the issue - on the first stage, simple packet replication is > just the same as multicasting, but is much simpler to inplement globally. > And this is in fact caching with the zero time-to-expire. > > Alex. > > > If you think about it briefly, Vadim's assertion that "packet caching" > > and "multicast distribution" are indistinguishable if the packets are > > retained in the cache for essentially 0 time. > > > > > I think Vadim's point is that accepting the validity of the > > multicasting = caching assertion allows one to consider doing > > a better job of reducing the consumption of network resources > > by replayable content than the use of native multicast does. > Just right. > > > (This is perhaps why Peter Lothberg and company have been working > > fairly hard at enabling the inflation of the use of Internet multicast, > > since the deployment costs of native IP multicast are so small that > > the ultimate non-scalability of IP multicasting (or multicasting > > in general if you accept Vadim's argument) does not prevent people > > from turning on PIM/SM+mBGP+MSDP. First you roll (excuse the pun) out > Compare the multicsting listeners and RealVideo or RealAudio or MP3 > listeners; first are 1% of the last. What multicast deploying are you > talking about, it's a myth yet. > > > 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

McLeod fiber cut in Chicago
by Charley Kline 16 Jun '99

16 Jun '99

Our OC-3 to the AADS NAP went out at 13:10 UTC today. McLeod Communications reports there is a fiber cut in Chicago that is "affecting a lot of customers." They didn't have an ETR for me. /cvk

1 0

T1 ISDN
by Neil J. McRae 16 Jun '99

16 Jun '99

Does anyone know what carriers [I guess MFS and TCG] can give me a T1 PRI into 111 8th and Telehouse Broadway? and recommend any account managers with telephone numbers :-) ? Regards, Neil.

1 0

Major PacBell SFO Facities / FR outage??
by John M. Brown 16 Jun '99

16 Jun '99

So, here I sit on the phone with a manager/sup at PacBell's NDPSC. We have been having a Frame circuit bounce up and down like a crazy since Friday. He is telling me that they are having a major outage in the SFO area and that various circuits are up and down. No ETR. Anyone else having problems.. At first they tried to tell me it was CPE. But since some of the PVC's where down and some where up, I don't see how it could be CPE! :) I explained that and then got the major outage statement. No master ticket number...... He just said it was a fiber cut. jmbrown(a)ihighway.net

1 0

multicast seen as equivalent of caching packets
by smd＠clock.org 16 Jun '99

16 Jun '99

Jamie Scheinblum writes: | 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). If anything, the net is moving to be *more* dynamic. I'm not sure why caching tends to mean exclusively "web caching". If you think about it briefly, Vadim's assertion that "packet caching" and "multicast distribution" are indistinguishable if the packets are retained in the cache for essentially 0 time. That is, if you missed your request to the cache for that packet, it's gone. This similarity has been explored in terms of developing more scalable reliable multicast than ACK or NACK implosions to the source can provide. Notably, most work in this field involves the packet cache retention time increasing substantially, with a "please send me packet XYZ" being sent back towards the root of the [local-]source-based spanning tree. "Packet caches" closer to the receiver reduce the distance across a network a NACK message towards a source must travel at the cost of state retention and processing of NACKs themselves done within the "packet caches". One set of schemes seems to involve longer retention times in the "packet cache" the closer the "packet cache" is towards the sender (which may simply be the root of a local spanning tree). Some work in self-organizing cache hierarchies sometimes looks spookily like recent work that has gone into native multicast deployment and thoughts about putting a chainsaw through RTP. The tradeoff towards more memory used in the "packet caches" makes me a little nervous given that "packet caches" in the native multicast model are routers. Interestingly, Vadim's model for a whomping big router seems to be really well suited to holding lots and lots of packets around in a cache. However, when you consider a router which doesn't have the ability to resend multicast packets sent through it, and instead merely punts the responsibility for retransmission sourcewards, this is fundamentally the same as a cache miss being handled transparently. I think that the multicasting = caching assertion holds water reasonably well. All that's really needed is to understand that the original group join by the listener sets up state whereby the local cache is asked to retreive a set of packets, that the local cache asks the next cache in the hierarchy and so on to the root of the hierarchy, which asks the source for each of these packets. The asking for each packet, however, is done _implicitly_ until the receiver leaves the group. It would be hard for a receiver with no direct visibility of the network beyond the local cache to distinguish between a series of packets coming exclusively from storage on the local multicast router and the same series of packets which came across the network from storage on a remote multicast transmitter. I think Vadim's point is that accepting the validity of the multicasting = caching assertion allows one to consider doing a better job of reducing the consumption of network resources by replayable content than the use of native multicast does. [Note that any content that can benefit from retransmission of lost packets is inherently replayable.] This does not, however, mean that deploying a system which does a better job is simple or even likely to be considered given the underutilization of Internet multicasting in the first place. (This is perhaps why Peter Lothberg and company have been working fairly hard at enabling the inflation of the use of Internet multicast, since the deployment costs of native IP multicast are so small that the ultimate non-scalability of IP multicasting (or multicasting in general if you accept Vadim's argument) does not prevent people from turning on PIM/SM+mBGP+MSDP. First you roll (excuse the pun) out the existing stuff and get it used, then you work on making it remain usable in the face of fundamental scaling problems. Welcome to the normal evolutionary path in the Internet...). Sean.

2 1

RE: Is anyone actually USING IP QoS?
by Jamie Scheinblum 16 Jun '99

16 Jun '99

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). If anything, the net is moving to be *more* dynamic. The problem is that web sites are putting unrealistic expires on images and html files because they're being driven by ad revenues. I doubt that any of the US based commercial websites are interested in losing the entries in their hit logs. Caching is the type of thing is totally broken by session-ids, (sites like amazon.com and cdnow). 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 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. 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. From what I remember, that was the only way the some Australian isps were able to make very aggressive caching work for them. 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... -jamie(a)networked.org > -----Original Message----- > From: Vadim Antonov [SMTP:avg@kotovnik.com] > Sent: Tuesday, June 15, 1999 4:23 PM > To: Brett_Watson(a)enron.net; nanog(a)merit.edu > Subject: Re: Is anyone actually USING IP QoS? > > 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.

3 2

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

16 Jun '99

> Just bare logics (a lost art in the modern datacom world, i guess). logics/insanity, l2/l3, no real difference, right... > 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 So you're saying that an application-specific cache would be more efficient than non-application-specific multicast? OK, let's consider this. How would distribution/replication be done? What was the destination address of the original packet .. let's say, 225.X.X.X? Wow! >> (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). But we're not discussing that. we're discussing multicast v/s unicast (or was it QoS?), but you're somehow tying the two together when they're completely different things. 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 bare logics world. > 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. a) Yes, it indeed does have different challenges than multicast. It still relies on the underlying layers which b) are not oblivious to such DoS attacks .. in todays Internet (maybe not yours, but todays) where 2 million line prefix filters are about as real as millions of multicast groups. > 99% of Web content is write-once. It does not need any fancy management. > The remaining 1% can be delivered end-to-end. I don't recall scoping this to only "Web", but it does seem to best augment your argument, better stick to it :-) I'm of the opinion that an application-agnostic approach is a better idea. > (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 :) Ahh, I see. Everything sux, but give me cash (pun intended :-) and I'll give you cold fusion. > It is not that caching is a silver bullet, it is rather that multicating > is unuseable at a large scale. many to many, perhaps it does have it's challenges. one to many, it works today. > 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. Second law of thermodynamics: OK, coke loses it's fizz, but putting a cap on the bottle wasn't that hard. > 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. Summary: It sux, I can't can't tell you why, but it just sux! > 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". > 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. However, if he sends enough mail to NANOG, he'll likely find someone to fund even shoving a rocket up a dogs ass :-) -danny (who won't waste any additional time in this thread)

2 1

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