- Test - lists.nanog.org

RE: Is anyone actually USING IP QoS?
by Alex P. Rudnev 15 Jun '99

15 Jun '99

// Sorry, if it's not for nanog forum, I can drop it's address from this // discussion. > Alex, steve: > > I know this thread is effectively dead, but I'm just catching up and enjoyed > the discussion very much. It's NANOG so it isn't surprising there was little > discussion of the edge of the networks. > > No one mentioned critical other functions for multicast and QoS: data > distribution and interactive services. The growth in broadband is putting > new services (and telephone is the simpliest) on the edge of the network. > Data distribution is a model starburst is working on. I think the demand for > it will grow exponentially. > > As the broadband world grows there are real oportunities for interactive > content placed near the edge of the network. This can not be centrally > placed because of latency requirements for interactivity. The architecture > requires 1000s of servers with pratically identical data on them. It's much > like a proxy pre-fetching data. The problems is there is lots of it > (100-500G). Multi-cast on public or private net is the logical way to do get > the data there. You areright about multimedia, but I am not sure about multicast. Russions are saying - if you see the banner _elebhant_ on the cell with the monkey in the zoo - don't believe to trhe banner. Just there. Multicasting is the beautiful idea, nice banner. But look on the real world. There is MULTIMEDIA ALREADY - I can get CNN TV, I can get different music, I can look on the shattle lanch in real time - withouth multicasting. There is already EXISTING MULTIMEDIA in the network - RealVideo and StreamVideo/on/demand. Not I have a question. No doubt, if 1000 customers ask RV stream from the CNN, the network fail down (or exactly server refuse to do it). This mean _this data have to be REPLICATED on the FLY_. There is a few different ways to do such replication. One way is MULTICASTING. It was developed for the LAN networks (because there is not other way to replicate data over the ethernet) and it's the only way to get multicast in the LAN if you need strong replication. But in real life, LAN network are not bottlechecks for this multimedia - if all RELCOM's employees ask RV CNN at once, our LAN networks can hold this traffic withouth big problems (128Kbit * 100 = 12,8Mbit - less than 1 100BaseTX ethernet!). The other way is CACHING. Caching on the fly or caching with the short time to live. There is two differences between this ways. Multicasting need another routing scheme, another address scheme, it's really ONE ANOTHER network. Caching need... no changes for the customer, just catch request on the fly (as WWW CACHE ENGINE by CISCO do for the WWW requests) and CACHE data on the fly). Now compare. One scheme need one another set of aggreements, one another set of configurations, etc etc... It's the only way for the DENSE MULTIMEDIA (if you need TV for the 1000 customers at one LAN at once, for example). Another way need one more protocol (such as WWW-CACHE-CONTROL protocol by CISCO, sorry I don't remember RFC number for it) but for some MultiMedia requests (RealVideo and StreamVideo are enougph for now), no aggreements, no additional configurations schemas, no changes for the customers and/or service providers. Guess what's better. And in real live, we have not multicast in the Internet. We have some SHOWS, but use RVplayer or other _request and send_ systems filled up by the information and music. And if someone propose effective cache engine for this streams - he'll be winner, not multicasting. Of course, no one prevent this cache engine from doing multicasting locally. What's about QoS - first, you need something simple oer the whole Internet. Then you can speak about RSVP and so on - if don't WDM kill it for this future time. Alex. ----- > As these new services are offered the need for QoS in the last mile will be > more critical. Some of these apps require minimal latency or strict packet > order. There is a strong future for QoS, but edge networks will require it > much more than the Internet. > > I work for one of the new interactive companies. The lack of good tools and > protocols is keeping me up at night. > > doug > > douglas o'flaherty > dir ops & support > arepa.com > > > > -----Original Message----- > From: Alex P. Rudnev [mailto:alex@Relcom.EU.net] > Sent: Tuesday, May 18, 1999 5:17 AM > To: Steve Riley (MCS) > Cc: nanog(a)merit.edu > Subject: RE: Is anyone actually USING IP QoS? > > > > I must agree and disagree. RSVP is dead protocol - it's enougph to > imagine how different ISP can negotoate about RSVP service, and (in > addition) read RSVP protocol itself... > > 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. > > I'd like to ask one more question. Multicast, > > If we project multimedia services from the scratsch, you have a few > different choices. For example, you have RealVideo server. I ask you > abgour RV stream. Ok, you send packets with DST=MY_ADDRESS. > > 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. > > I mean - first way was (was) to use existing address space for multicast > multimedia, and add some mechanism (such as replicators) to hide the > mechanisms from the end user. No one bother if some RV-CACHE server catch > his request and use his own replicator to organise multidemia stream. > > Second way was choosen - to use another address space for the multimedia > multicasting. Result - you see - Internet have not (HAVE NOT) multimedia > multicast at all. No, some ISP have internal multicast networks, but not > more. If I ask CNN abour RV live stream, and you ask the same, be sure - > the server send just 2 different packets - one for you and one for me... > > And this is very serious obstacle against multimedia services in the > Internet. Not QoS (through QoS prevent using existing public networks > from the commercial telephony), but tjis absence of mukticasting in the > Internet. > > > > On Mon, 17 May 1999, Steve Riley (MCS) wrote: > > > Date: Mon, 17 May 1999 14:04:37 -0700 > > From: Steve Riley (MCS) <steriley(a)microsoft.com> > > To: nanog(a)merit.edu > > Subject: RE: Is anyone actually USING IP QoS? > > > > > > 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 > > > > > > 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) > > 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

Off Topic Request: I need some help!
by Dan Bustillos - Datalink Computer Services 15 Jun '99

15 Jun '99

Hey all, I was hoping someone could give me the RFC for non routable addresses (10.0.0.0). I did a couple of searchs for it, but I did not find what I was looking for. So if anyone knows ( and I know you do) could you please help me out. Thank you, Dan Bustillos Datalink Computer Services (530) 897-6400 (888) 328-4638 ******************* "Error, No Keyboard - Press F1 to continue" Only on a PC would you see this error. Never on my mac.

6 5

Re: DS-3 Error Stats
by Sean Donelan 14 Jun '99

14 Jun '99

A fellow NANOG reader (though not poster) sent me this, and since it seems relevent, I'm forwarding it on to the list. >Both the ITU-T and Committee T1 publish performance standards >that include parameter definitions for dedicated digital services >(e.g., ITU-T G.826, ANSI T1.510) and other service types >(e.g., ATM, Frame Relay, IP (e.g., ITU-T I.380, T1.511, T1.513, >T1.520). Information on ANSI (T1A1) standards can be found at >http://www.t1.org/html/std2.htm (keeping in mind that certain >standards may be newly revised/approved and will be appearing >shortly -- 1-2 months) on the T1 website. For example, T1.510 >was recently revised by T1A1 Working Group T1A1.3 (http://www.t1.org/ >t1a1/t1a1.htm) at its May 1999 meeting and is in T1 letter ballot at >this time. You can access relevant contributions via >http://www.t1.org/index/0628.htm and the draft proposed standard >via http://www.t1.org/index/10001.htm: > >lb775.pdf 184684 05-26-99 T1 Letter Ballot 775 - Draft Proposed > Revision of ANSI T1.510-1994 - Network > Performance for Dedicated Digital Services > for Rates Up to and Including > DS3-Specifications. > Issued 05/26/99. Closes 07/07/99. Exactly which standard your telco referenced in its tariff will vary. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: DS-3 Error Stats
by Sean Donelan 14 Jun '99

14 Jun '99

jhawk(a)bbnplanet.COM (John Hawkinson) writes: >Most carries have "performance objectives" which they adhere to, >and they specify some number of errored seconds per day per circuit, >and those numbers may vary based on route-milage. > >Unfortunately I think most of those numbers are covered under NDAs, >but I can safely say that 1 errored second/day would be well >under the criteria and 1,000 would be well over, and anything in >between depends on your carrier and route miles, etc., etc. In most cases, DS3's are sold by carriers as a tariffed service. The carrier may not like disclosing the numbers, but buried in the public tariff's "incorporated by reference" list of documents are the performance objective for that carrier's DS3 service. Most carriers' tariffs refer back to either Bellcore(telcordia), ANSI/T1 or ITU specifications (generally in that order). However, I'm not sure knowing them will do you much good. I tracked down the numbers for DS1 once upon a time. Like any good-one-sided telco tariff, the circuit could be very bad and still meet the "acceptable" performance objectives for the service. If I recall correctly, a DS1 could have several thousand error seconds a day, and be considered "acceptable" according to the tariff. I've never looked up the DS3 numbers, so I don't know the official tariff numbers. As always, the tariff overrides anything the sales person told you, or anything written in your contract. However after saying that, digital lines usually only have 'noise' for a reason. The question is how bad does it have to be before you can get the telco to track it down. Here are my rules of thumb for most digital circuits: Error seconds/15 minutes Classification 0 Perfect 1-5 Look at the circuit during the next maintenance window if it doesn't clear up 6-29 Open a ticket 30+ Immediate action required (its likely the circuit is bouncing or 'down' at this point) Other people prefer to use a long-term bit error-rate, or packet/cell errors. But then you have to explain to the telco what a packet or bit is. For those ISPs which own their facility provider, they may be able to get the facility folks to monitor the circuits. But for the rest of us, you have to monitor your own circuits. The facility provider is never going to tell you about a potential problem. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: DS-3 Error Stats
by scott w 14 Jun '99

14 Jun '99

Maybe I should add that I'm looking at ATM WAN switches and several-thousand-mile hauls. Are ATM WAN switches more sensitive? Can telcos clean up the noise on such a long haul as opposed to several-hundred-mile hauls. My counters on the routers for the 'short' haul lines are indeed zero. scott On Sun, 13 Jun 1999, scott w wrote: | | | | Can any of you guys offer up any stats on the type and numbers of errors | you see on cross country and international DS-3s and/or E3s? I trying to | figure out "acceptable" limits before putting on my camo gear and going | after telcos... ;) (my favorite non-spectator sport) | | scott | | |

3 2

DS-3 Error Stats
by scott w 14 Jun '99

14 Jun '99

Can any of you guys offer up any stats on the type and numbers of errors you see on cross country and international DS-3s and/or E3s? I trying to figure out "acceptable" limits before putting on my camo gear and going after telcos... ;) (my favorite non-spectator sport) scott

1 0

TOS issues with non RFC compliant TCP stacks
by Alan Hannan 13 Jun '99

13 Jun '99

Howdy. We have learned of a problem with non RFC compliant users of the Internet. We believe this problem will be of interest to NANOG and tcp-impl WG participants. We would like to involve a larger body so that: - more people are aware of this issue - ISPs can more quickly handle potential problems when they arise - we can learn about additional IP stacks that have this problem - alternate opinions can be presented that may argue this behaviour is appropriate, and RFC compliant It has come to our attention that a notable fraction of the internet client community uses a TCP stack which is not RFC compliant, as far as we can determine. Certain versions of MacTCP send a RST when they receive SYN ACK packets of TOS!=0. I assume there are other TCP implementations which also have this behaviour. This concerns us, as we would like to see IP transport utilize TOS markings for the growth of the Internet. In discussions with several vendors, colleagues, and review of RFCs, the following phrase seems most applicable, from Postel in RFC 793: ------------------------ = ------------------------ 2.10. Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. ------------------------ = ------------------------ Open Transport (an alternate, Apple supported stack) follows this principle and works well. Additionally, a patch is available on the net for MacTCP (see below). So, the empirical part: We implemented TOS bit-setting for the purpose of tracking traffic flows and traffic levels. For an entirely arbitrary reason, we chose TOS=5 for the default of traffic. We found that MacTCP ceased functioning. The MacTCP stack would initiate an RST when receiving SYN ACK packets with a TOS=5, as the SYN packets had a TOS=0. Therefore, all TCP sessions would fail. We can quite simply work around our customer's problem by setting TOS=0 on all traffic to/from the customer interface. However, any traffic towards nonFGC customer's [ie, from our interconnection partners] will not be modified. Therefore, they are also vulnerable to this problem. Because of a hardware implementation limitation on most of routers, INbound TOS setting is efficient, while OUTbound TOS setting is inefficient. So it is difficult for us to modify the TOS settings leaving our network. It would be moderately trivial for most interconnection partners to modify the TOS settings on input. This is a path we plan to pursue. As it turns out, this is an archaically (sp) known problem, with a pre-existing patch. Information about this patch for MacTCP exists at: http://www.mactcp.org.nz/mactcp.html At this time we do not modify TCP TOS bits. Once we have more information we intend to move forward with the TOS modifications, after notifying our InterConnection partners and customers of potential impact. Thank you for your consideration. -alan

3 2

Murphy comes to St. Louis
by Sean Donelan 12 Jun '99

12 Jun '99

Murphy has been working overtime in St. Louis. A combination of several sever thunderstorms and grid problems with AmerenUE, the local electric power company, flash floods due to rain, and even a major water main break in the business district; and ISP's are testing all parts of their backup plans. At least four different St. Louis ISPs had problems at some time in the last 24 hours for a variety of different reasons. UPS failure, generator failure, flooding, and electrician error while doing preventive maintenance. http://www.stlnet.com/postnet/pnhelp.nsf/ByDocID/F7F43108C9DD71408625678D00… Postnet is located at 900 Walnut in St. Louis which is the main CLEC/carrier hotel facility in downtown St. Louis. Other outages also occurred at a university in mid-St. Louis county, and at ISPs in west county. Some ISPs survived one wave of thunderstorms, only to succumb to a later wave. And my personal experience, a direct lightning strike on a tree next to my bedroom window. Anyone want to buy some used surge protectors? Only used once :-) -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

New Paper
by Cho R. Lame 12 Jun '99

12 Jun '99

Friend Frank Rizzo send me attach paper. CHO _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com IP/DWDM Analysis as some vehicle fo' netwo'k 'espansion Internet Protocol (IP) [1] ova' Dense Wavelengd Division Multiplexin' (DWDM) [2] be emergin' as de future fo' longhaul netwo'k infrastructure in bod de public telephony and private Internet Service Provida' (ISP) netwo'ks. In dis document, we gots'ta examine da damn underlyin' technology wid dis issue as sheeit as comparin' and contrastin' it against oda' current practices. We gots'ta den present some conclusion regardin' dis technology and its impact on de future uh telecommunicashuns netwo'ks. Acronym Guide, dig dis: ADM - Add/Drop Multiplexer ANSI - American Nashunal Standards Institute APS - Automatic Protecshun Switchin' ATM - Asinchronous Transfa' Mode DCS - Digital Cross-connect System IP - Internet Protocol ITU - Internashunal Telecommunicashuns Union LTE - Line Terminatin' Equipment MM - Multimode PDH - Plesiochronous Digital 'Sup, dudeerarchy PTE - Pad Terminatin' Equipment SDH - Synchronous Digital 'Sup, dudeerarchy SM - Sin'le Mode SONET - Synchronous Optical Netwo'k STE - Stashun Terminatin' Equipment STS - Synchronous Transpo't Signal STM - Synchronous Transpo't Mode TDM - Time Division Multiplexin' WDM - Wavelengd Division Multiplexin' Motivashuns and 'Sup, dudesto'ical Background, dig dis: To dig it de motivashuns towards dis new technology, one gots'ta to dig it some uh de histo'y uh telecommunicashuns. Telecommunicashuns started wid de provisionin' uh individual physical circuits fo' each end-usa' stashun. Dese circuits stretched fum de central office t'de telephone in de crib. Increasin' capacity wuz simply some matta' of hirin' labour t'lay mo'e pairs uh coppuh'. Inter-witch capacity wuz also handled wid big-ass bundles uh coppuh' pairs as sheeit as frequency division multiplexin' in lata' years. FDM basically transmitts multiple signals ova' de same medium at difference frequencies t'de opposite stashun. An easy analogy which illustrates de concept be dat of de public transista' stashuns. Each transmits at some different frequency widout interferin' wid de oda' signals. De impo'tant wahtahmellun t'note about dese technologies employed in de public switched telephone netwo'k (PSTN) wuz dat dey wuz essentially analog. De wavefo'ms generate by speech pattern wuz merely duplicated fum stashun t'stashun. No erro' co'rectin' wuz puh'fo'med. Even FDM be some analog technology. Slap mah fro! It simply transmits de wavefo'ms at different frequencies. It wuz not until de invenshun uh de integrated circuit dat de telecom industry started its massive high speed deployment. One uh de most impo'tant advantages uh de digital system wuz dat equipment wuz now able t'group signals into binary representashuns. Switches now could employ analog t'digital converters and could now could opuh'te wid clunker chips t'discriminate and group signals. Dis led t'de development uh de digital signallin' hierarchy uh communicashuns protocols. Now, instead uh transmittin' analog wavefo'ms, de switch transmitted digital pulses on its high speed trunks. Dese pulses wuz gadered fum samplin' de end-user's analog wavefo'm at discrete time intervaces (8000 times some second) and den relatin' de sample intensite to a unique binary digit (bit) pattern [3]. Wid de advent uh faster signallin' interfaces, de switches wuz now able t'multiplex many individual voice circuits togeda' into some digital bitstream fo' transmission t'an adjacent switches. De economies uh scale realised from de mutiplexin' uh digital signals led AT&T t'invest large sums of bre'd in some Time Division Multiplexin' (TDM) toll infrastructure. What it is, Mama! Dis allowed dem t'eliminate da damn need fo' individual coppuh' pairs strung between switches. As some example, one DS1 (digital signallin' level 1) allowed fo' de TDM transmission uh 24 voice channels ova' a sin'le coppuh' pair. Ah be baaad... A DS3 allowed fo' de TDM transmission uh 672 voice channels ova' a sin'le pair uh coaxial cable. What it is, Mama! De next large evolushun wuz fum de coppuh'-based infrastructure to some fibre optic infrastructure. What it is, Mama! De advantages uh fibre ova' coppuh' wuz much de same as TDM ova' earlia' sin'le pair transmissions, dig dis: fibre allowed fo' mo'e simultaneous voice channels (up t'10 terahertz) [4]. Addishunally, fibre duz not suffa' from cross-rap o' interference a'cuz transmission ova' it duz not generate some magnetic field. AT&T fust started deployin' de nashunwide fibre infrastructure in de early 1980's befo'e deir divestiture [4]. As competishun grew fum nascent long distance carriers suin' demselves into 'esistence (MCI and US Sprint), it wuz now necessary fo' jimmey communicashuns protocols t'be developed. Now, netwo'ks which suppo'ted different vendo's needed t'communicate between each oder. Ah be baaad... Dis led t'de fo'mulashun and development uh de SONET/SDH standards. Dese standards also helped solidify some scalable protocol architecture fo' high speed optical transmission. 'S coo', bro. Dis allowed netwo'ks de advantage of defined optical upgrade alleys as sheeit as introducin' new opuh'shuns and maintenance features likes APS and rich diagnostic frame info'mashun[6],[7]. Besides sublte alley over'haid and tributary differences, de main difference between SONET and SDH be dat SDH is specified in some internashunal standard [7] while SONET be specified in some ANSI standard [6] specific only t'de United States. Current Technology, dig dis: Now we are seein' some push back towards de old FDM/WDM days in addishun and sometimes as some replacement t'de SONET/SDH infrastructure. What it is, Mama! WDM simply applies de same principles on fibre as FDM dun did on coppuh'. It transmits multiple signals simultaneously at N different wavelengds which allows some sin'le optical fibre's capacity t'be increase N times. Basically, some multiplexa' on each end uh de dark fibre pair snatch'd input signals fum its tributaries and assigns each tributary t'an unique wavelengd. De oda' end uh de dark fibre pair filters de incomin' signal back out into individual wavelengds and routes dem towards deir appropriate alleys. De current push towards dis technology comes fum many angles. De main angle in de suppo't fo' DWDM (dense WDM) be purely economic. If some fibre provida' has invested hundreds uh millions of dollars in telecommunicashuns infrastructure and suddently kin add 24 times capacity on each fibre pair wid de addishun uh two relatively in'spensive multiplexers, de advantages are obvious. Now, de provider can add mo'e current capacity t'offset da damn cost uh de netwo'k buildout. Also, de provida' duz not gots'ta invest in any intervenin' 'espensive SONET equipment fo' de deployment uh dese services[2]. In addishun t'obvious multiplicative economic advantages de last decade, dere gots'ta been some 'splosion in telecommunicashun netwo'k usage fo' data services and not da damn tradishunal voice services. De Internet falls unda' dis data services catego'y. Slap mah fro! Now, company internetwo'ks are growin' to de size uh public telephony longhaul netwo'ks. One interestin' fact of IP service be dat dere be no clear demarcashun o' set multiplexin' scheme fo' de end users. All uh de data traffic be lumped togeda' in a haphazard fashion and transmitted widout any preconceived noshuns of o'der. Ah be baaad... Derefo'e, de IP netwo'ks which are buildin' demselves ova' de global telecommunicashuns netwo'k infrastructure do not need de funcshunality uh 'spensive sonet ADMs and STEs. SONET provides 'sellent funcshunality if ya' wanna assemble and disassemble multiplexed tributaries fum some larga' stream frequently. Slap mah fro! In fact, some SONET netwo'k spannin' de united states could conceivably gots' 100 individual nodes on a sin'le fibre alley who kin boogie out service fo' localities and transmit service fum localities [6]. IP netwo'ks are some different paradigm. 'S coo', bro. Commonly, some link be built ova' de telecommunicashuns infrastructure directly fum coast t'coast (bypassin' stops in de intervenin' netwo'k elements). Derefo'e, IP netwo'ks do not need all uh de 'esensive SONET equipment in between de IP protocol routers. Anoda' drivin' facto' towards DWDM be de lack uh vendo' interfaces suppo'tin' signallin' rates in 'sess uh STM-16/OC48. Currently NORTEL be de only telecom vendo' who suppo'ts some STM-64 interface. What it is, Mama! Fo' netwo'k providers, it be cheapuh' t'provide 24 STM-16 wavelengds dan it be to devote some fibre pair t'an STM-64 signal. Also, in de wo'ld uh IP netwo'ks, no vendo' gots'ta some switch o' some interface which suppo'ts STM-64. Many IP providers who deploy deir own infrastructure are choosin' IP runnin' directly ova' DWDM t'save on netwo'k costs as sheeit as providin' some pad fo' future 'espansion. 'S coo', bro. Current Deployments, dig dis: Currently, many telecom infrastructures are deployin' DWDM fo' bod tradishunal longhaul telephony and fo' dedicated IP services. Some examples include US Sprint, Qwest, and Hermes Europe Railtel. All of dese providers are usin' CIENA equipment as de DWDM. Many uh de telecom firms are also lookin' at leveragin' de benefits uh IP netwo'ks ova' tradishunal circuit based telephony. Slap mah fro! Basically, dey wanna run voice calls directly ova' IP cuz' of substantial cost savin's. Companies dat do dis kin totally igno'e da damn SONET/SDH deployment and instead concentrate on deployin' Voice ova' IP ova' DWDM infrastructure at a significant cost savin's when compared t'last-generashun SONET/SDH netwo'ks. De largest cost savin's gots'ta be in de bypass uh 'spensive SONET multiplexin' gear. Ah be baaad... Dere be also de obvious cost savin's of duplicatin' some fibre pair 24 times ova' when de entire infrastructure investment gots'ta already been scribblin'ed as some capital 'espenditure. What it is, Mama! De capacity sold on de 23 'dim fibre' lambdas be now nearly pure profit fo' de telecom netwo'k. Many providers fum tradishunal telecoms t'startup VoIP outfits to Internet transit netwo'ks are deployin' IP/DWDM. While da damn VoIP and IP providers concentrate deir co'e business on IP/DWDM, de telecoms are concentratin' on DWDM and providin' some few lambdas on deir netwo'k dedicated t'IP traffic. Examples uh current VoIP providers deployin' IP/DWDM are Qwest and Level 3 Communicashuns. Examples uh tradishunal telecoms who are deployin' de techology are GTS carria' services, Sprint, and AT&T. Examples uh IP providers who are deployin' dis technology are Frontia' Globalcenter, Ebone A/S, and Sprintlink. Dese companies fo'm some substantial co'e uh de telecom market and gots' seen de economic benefits IP/DWDM affo'ds bod de consuma' and deir own toll netwo'ks. Tradishunal telecoms likes AT&T are takin' some cautious approach to movin' deir toll traffic across some IP backbone. What it is, Mama! Dey are wary dat deir large revenue stream might be distrupted by unfo'seen failures in de nascent IP protocol deployments. While dey gots' fifty years 'sperience wid fault tolerance fo' deir voice switches, de mere five years 'espuh'ience wid IP switches makes dem tread wid trepidashun. Nearly every facilities based telecom be upgradin' eida' entire netwo'ks o' congested alleys wid DWDM. As IP be better understood and reliable switches are built, we gots'ta see some move fum connecshun o'iented services predominant in de voice netwo'ks t' connecshunless netwo'k services which provides some "best-effo't" transmission attempt o' puh'haps even differentiate levels of service (and pricin') fo' plantation consumers. Currnet Physical Interfaces t'de DWDM netwo'k, dig dis: Current IP suppliers are usin' SONET/SDH interfaces t'comunicate wid oda' nodes ova' DWDM netwo'ks. De reason fo' dis be dat da damn only interfaces which suppo't STM-16 sin'allin'. De disadvantage t'deployin' dis interface be dat ya' carry all uh de 'estra SONET secshun, line and pad over'haid which amounts t'17% uh de sin'alled bandwidd[5]. At OC48, dis be about 400 megabits/s in SONET over'haid which be unutilised fo' IP services[6]. Dese SONET/SDH interfaces connect into some CIENA optical multiplexa' which den converts each input into its own unique wavelengd fo' transmission. 'S coo', bro. Fo' sho't distances (less dan 40 miles) long reach lasers are sufficient fo' communicatin' between two CIENA muxes widout de use uh intervenin' repeaters (again savin' on equipment costs). Telecommunicashuns gear likes de No'tel S/DMS transpo't node also connects t'de CIENA equipment via fibre optic interface. What it is, Mama! Dis unit also speaks SONET/SDH protocol t'de adjacent SONET multiplexin' equipment. However, de general telephony applicashun be relatively betta' suited to de SONET protocol cuz' it gots'ta some tendency t'boogie out da damn little-assed tributaries (DS1s o' DS3s) as it interfaces into de PDH fo' voice communicashun [6]. Protocol technologies related t'IP ova' DWDM: Dere are some few key protocols which are battlin' fo' communicashun control uh de bits on de netwo'k. ATM and da damn point t'point protocol (PPP) are fightin' fo' supuh'io'ity at OSI laya' 2. SONET/SDH, Wireless transmission, Satellite transmission and IP ova' raw fibre are competin' fo' control uh de physical layer. Ah be baaad... At da damn datalink laya' (laya' 2) ya' find PPP and ATM. ATM wuz widely deployed by telecom and IP netwo'k vendo's durin' de early po'shun of de 90s cuz' it allowed fo' some fina' level uh traffic engineerin' and bandwidd guarentees dan had previously been achievable in de telecom services field. PPP wuz in use in de early po'shun uh de 90s mainly fo' lowa' speed access lines (DS1, DS3, and analog phone lines). Midway drough de 90s, sucka's started movin' away fum ATM cuz' of its high protocol over'haid. ATM be some stream uh fixed-lengd cells. It consists of a fixed foe byte 'haida' in some 53 byte cell. Dis instantly creates some 10% over'haid. Also, ATM handles dropped cells poo'ly cuz' it be not connecshun o'iented. If one cell be dropped, de whole session needs to be retransmitted. Dis leads t'practical over'haid uh 25% in opuh'shunal netwo'ks. De combinashun uh 17% at da damn SDH laya' and 25% at da damn datalink laya' wuz simply too much over'haid fo' providers dat wuz primarily interested in supplyin' large bandwidd aggregate connecshuns. Dese providers opted fo' de PPP ova' SDH interfaces. PPP be much better suited t'variable lengd IP packets cuz' its frame size be adaptably variable. What it is, Mama! Dus, it cut waaay down on protocol over'haid t'a manageable level and allowed IP service providers t'squeeze mo'e usable bandwidd (baaaadput) out uh deir telecommunicashuns connecshuns. At da damn physical layer, we gots' terrestrial fibre alleys runnin' SDH, Satellite alleys, wireless alleys runnin' SDH and trials uh ip ova' raw DWDM fibre. What it is, Mama! Fo' longhaul applicashuns, SDH ova' fibre (and in some cases ova' WDM) be de currenty deployment base. What it is, Mama! SDH specifies signallin' speeds down to STM-64 and also provides key services t'telecom providers likes enhanced opuh'shuns and management features and automatic protecshun switchin' in case uh link failures. De richness in debuggin' features comes at some cost uh 17% uh de signalled bandwidd in allocashun t'such features as dree laya' bit erro' parity checkin', unallocated 'espansion slots, and oda' management funcshuns[5]. IP ova' raw fibre gots'ta directly compete wid SDH fo' netwo'k dominance uh de highest speed links on de globe. What it is, Mama! Fo' IP services, runnin' IP directly ova' de fibre widout intervenin' over'haid uh de SONET laya' would definitely improve da damn overall feasible baaaadput uh a link. As telecom providers 'espuh'iment wid runnin' voice netwo'ks over IP, de advantages which de SONET/SDH infrastructure provide in some circuit based environment diminish. Wireless (and its subset satellite) technologys mainly occupy de domain uh communicashun where runnin' fibre optics be not currently feasible fo' economic o' engineerin' reasons. Wireless be used t'strech across de nashun in remote areas as sheeit as t'provide roamin' netwo'ks fo' cellular phone users. Satellite communicashun be used t'access remote areas when no oda' fo'm uh communicashun be possible. What it is, Mama! Bod satellite and wireless transmission media suffa' from atmospheric phenomena interference. What it is, Mama! Satellite communicashun also suffers fum de propogashun delay induced by de speed uh light propogashun time fum base stashun t'satellite t'base stashun. Dis kin renda' some fo'ms of interactive communicashun nearly unusable. What it is, Mama! Dere are two types uh majo' toll telecommunicashuns systems. One be de terrestrial large bandwidd links. IP/DWDM and IP/SONET/DWDM gots'ta be competin' fo' some share uh dis infrastructure. What it is, Mama! SDH gots'ta de advantage uh bein' some internashunal standard wid specified signallin' levels and optical interfaces while da damn nascent IP/DWDM field duz not [7]. However, de IP ova' raw fibre field duz gots' de advantage of bein' streamlined fo' IP communicashuns. Should IP communicashuns be de next revolushun t'de telephony netwo'k as companies likes Qwest and Level3 are wagerin', de SONET/SDH infrastructure gots'ta lose ground to IP/DWDM interfaces. De realm which wireless and satellite communicashuns gots'ta occupy is one fo' mobile o' remote lines where physical land lines aint feasible. What it is, Mama! Wireless and satellite link summed bandwidd levels gots'ta be significantly little-assa' dan deir terrestrial fiba' counterparts. Future Outlook fo' IP/DWDM: Currently, de only deployed vendo' fo' DWDM products be CIENA. However, dere deployment base be global in scope and deir product is accepted as reliable and funcshunal. CIENA currently gots'ta some 24xSTM-16 DWDM system. 'S coo', bro. By years end dey are 'espected t'gots' 80xSTM-16 and 40xSTM-64 products. As vendo's start introducin' mo'e STM-64 products fo' IP and SONET/SDH netwo'ks we gots'ta see competative prices on de STM-64 rollout in toll and ip transit systems. Runnin' IP/DWDM o' at least DWDM netwo'ks gots'ta be da damn trend uh de future. What it is, Mama! Some telecoms are tryin' t'load all uh deir voice traffic over IP while oders wanna stay wid some tradishun circuit switched allocashun model. Fo' dose who wanna deploy IP services, IP/DWDM be some tremendous costs savin's. Not only be dere some feasible mutaplicative revenue gain from sellin' lambdas ova' de fibre, dere be also no need fo' SONET gear ova' de longhaul secshuns uh de netwo'k. It be debatable wheder IP/DWDM kin solve all uh de telecom netwo'k 'espansion problems. SONET/SDH has some sheeit o'dered and documented interface into de PDHs uh de wo'ld. While IP/DWDM offers substantial economic advantages ova' de longhaul, de handoff t'de PDH gots'ta likesly still run drough SONET/SDH ADMs. De future fo' IP/DWDM be told best by simple market competishun. IP/DWDM allows telecoms t'offa' mo'e service at lower prices. If telecoms do not deploy IP/DWDM in some free market, dey gots'ta not be able t'compete wid telecoms wid multiplicative capacity and a lowa' cost base. What it is, Mama! Bod de telecom netwo'ks and da damn plantation consumer benefit by de sudden glut in bandwidd on toll netwo'ks. Apart from de fo'mashun uh a cartel, de consuma' should see relative price drops wid reflect da damn accountin' gains uh de large netwo'k providers. References [1] Postel, J., "Internet Protocol" RFC 791, USC/Info'mashun Sciences Institute, Septemba' 1981. [2] Fundamentals uh DWDM Whitesheet, CIENA, 1998 [3] Bellamy, Raz'tus C., "Digital Telephony", Wiley Publishers, January 1991. [4] Ramaswami, Rajiv et al., "Optical Netwo'ks, A Practical Perspective", Academic Press, February 1998. [5] Chow, Min'-Chwan, "Understandin' SONET/SDH: Standards and Applicashuns", AT&T Bell Labo'ato'ies, 1995. [6] SONET Rates and Fo'mats ANSI T1.105 [7] Characteristics uh Synchronous Digital 'Sup, dudeerarchy Multiplexin' Equipment Funcshunal Blocks, ITU-T G.783

1 0

NOC notification policies
by Troy Davis 12 Jun '99

12 Jun '99

This is half rant and half hope that it'll make someone, somewhere check their emergency policies who otherwise wouldn't. We're seeing a ~15 mbps flood, most of which is sourced from ernie.eecs.uic.edu. Traceroutes to that machine show it to be ~800 ms slower than the hop before it, so the flood isn't spoofed. I did a whois on uic.edu and called the contact. I was greeted by voicemail, where I promptly left a message. uic.edu has a /16 and is not SWIPped out of anyone else's ARIN space; the same person (voicemail during off hours) is the contact. A different voicemail number is the contact for AS 6200, the University of Illinois at Chicago's AS. Their web site didn't cover networking. If you can't have either your IP block or domain whois point folks to a 24/7 contact, get your uplink to be the point of contact. We'll see in a second why that wouldn't have helped here, but in cases where the uplink has > 10% of a clue, it would. So I moved up the food chain. uic.edu receives transit from Nap.net (single-homed, according to route-server.cerf.net and nitrous.digex.net) After checking ARIN whois for AS 6200 and Jared Mauch's (excellent, BTW) NOC contact list, I came up with 1-800-801-3920 (the other number, (414) 747-8747, refers to this number for network emergencies). I call it. "Teresa" answers, representing GTE and Nap.net. I tell Teresa my problem and she politely requests I call back during business hours when their staff is available. I tell her how big this flood is and request she page their engineer or her boss. She refuses. As she puts it, we're not Nap.net customers. I inform her of what the flood is doing to my network and she says that they only serve customers, as if I was looking for technical support. She's unwilling (unable, as she puts it) to investigate, we trade arguments, it goes nowhere, we hang up. Her wording sounded very much like an official Nap.net policy - no pages except for customers. There is at least 1 "backbone" (cough) peering at multiple major NAPs who is completely unreachable during the off hours. I doubt my experience today is as rare as we'd all like it to be. I'm thoroughly disgusted. Please test your 24/7 monitoring from the perspective of a third party who needs immediate attention. Follow what I did - see if whoises on your domain name, IP block, and/or ASN reveal the NOC number (or one which can refer you there). Call it at 2 AM once or twice in the next couple weeks and see what happens. Good night. -- Troy Davis

1 0