June 1999 - NANOG - lists.nanog.org

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

15 Jun '99

> Or you can try from the other end - doing replication on the fly, and > convert existing UNICAST data streams to the multicast if (and where) > it's nessesary only. Hrmmm... Seems to me as though, in it's most optimal state, that'd be multicast? Great idea! > I am not shure if the first approach is worst or not, nut for a few > years there is attempts to build multicast network over the whole > internet - and it have not eny success except a few of pylot projects. > Compare RealVideo auditory and multicast auditory for now... And why > don't try anpther approach. Several providers have deployed/are deploying NATIVE multicast today on their "production" IP networks today (many have had intra-domain enabled for years), and deploying inter-domain mulicast via existing direct interconnects and the MIXs. Not only is there a b/w savings, there's a huge savings on the source side as well. A primary concern is the ability of existing and new router vendors platforms to do this efficiently. 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. -danny

2 1

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

15 Jun '99

> Aleksei, > I agree that you can solve one-to-many type of applications by smart > caching. Though the problem now is how much you want to spend on > caching, where you cache and would it scale well. I have meant _replication on the fly == multicasting_. You can build NEW MULTICAST network over the internet, and begin multicasting just from the data source. This means _new router features_ (buggy and odd for now), new routing protocols (such as PIM, buggy and odd), etc etc - a few years (and may be the horse will die BEFORE you'll have success). Or you can try from the other end - doing replication on the fly, and convert existing UNICAST data streams to the multicast if (and where) it's nessesary only. Just as WWW caching, you'll have results from the first week, and you can do ot one the customer's eddge, on the data-source eddge. I am not shure if the first approach is worst or not, nut for a few years there is attempts to build multicast network over the whole internet - and it have not eny success except a few of pylot projects. Compare RealVideo auditory and multicast auditory for now... And why don't try anpther approach. Alex. > And I'd like to point that multicast tries to solve not only one-to-many > problem (eg. streaming video) but other scenarios as well. What might be > alternative for many-to-many apps? How to scale such applications? > As regarding QoS, I don't think that we'll see a protocol that will > cover Internet as a whole. In my mind protocol driven QoS is intra-AS or > intra-ISP issue and crossing AS boundaries is regulated by SLA which is > hardly dynamic thing ;). Though some statically defined QoS filters > might be installed. QoS wouldn't create more bandwith but rather make > billing easier. That's my take on this. > > Regards, > Grigorij > > > -----Original Message----- > > From: Alex P. Rudnev [SMTP:alex@Relcom.EU.net] > > Sent: Tuesday, June 15, 1999 5:44 AM > > To: O'Flaherty, Douglas > > Cc: nanog(a)merit.edu; 'steriley(a)microsoft.com' > > Subject: RE: Is anyone actually USING IP QoS? > > > > > > // 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) > > > 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: DS-3 Error Stats
by Mike Trest 15 Jun '99

15 Jun '99

Scott, I have been running ATM over SONET for OC3 and DS3s since 1995 with over a dozen different providers. The errors are either zero or complete outage. I do not recall a circuit with any long-term period of intermittent errors once the installation mis-configuration issues were resolved. ..mike.. At 02:24 AM 6/14/99 +0000, scott w wrote: > > > > > >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 > | > | > | > Charlotte, NC: +1 704 602 3030 Fax: +1 704 541 6911 San Diego, CA: +1 619 689 1429 Fax: +1 619 689 1248 Roanoke, VA: +1 540 265 2555 x169 Business Hours Roanoke, VA: +1 540 725 1445 Home

1 0

Re: Off Topic Request: I need some help!
by Jeff Weisberg 15 Jun '99

15 Jun '99

| | Then there is the IANA test network, 192.0.2/24. (Anyone have an official | reference to this one?) not "official", but: draft-manning-dsua-00 --jeff

1 0

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