- Test - lists.nanog.org

TELEHOUSE America & Internet Software Consortium Develop DNS F-root Server in New York & Los Angeles
by Paul Vixie 11 Feb '03

11 Feb '03

Deal Enables ISC to Mirror DNS Root Server in Additional U.S. Locations http://biz.yahoo.com/bw/030210/102340_1.html

4 3

RE: VoIP QOS best practices
by Ray Burkholder 11 Feb '03

11 Feb '03

Ok, I've taken all the courses and done some stuff myself. Here is roughly what to expect. It IS important to do QoS at the CPE. This ensures that during times of congestion, voice traffic gets out to the real world in a timely fashion. In networks supported by Nanog people, usually they have bandwdith to spare, and so QoS isn't necessarily important. The issue is when traffic crosses ISP boundaries, because many times these links are clogged. It used to be you had to stay away from MAEWEST and such because of big packet drops and delays (big no-no's for voice). Things are getting better in this regard because of a larger number of cross connects between carriers. General rule of thumb used by the big Voip guys is to send most of your voip traffic through what could loosely be termed as Tier 1 providers (please don't flame me on this remark). They you can be pretty sure that there is much excess bandwidth, fast switches, and fast transit time with little drop out (all important criteria for good voice quality). The issues are always when crossing carriers, and at the network edge. These are the troublesome spots. Some solutions include peering with multiple Tier 1 providers, and doing traffic engineering to ensure your traffic goes through the best provider to the end destination, etc, ... When you get into IP Telphony in a LAN environment I can get into a whole other discussion of myth dispelling. For example, just because your LAN switch has underutilized GigE and FE ports, did you know that you can still suffer horrible voice quality? QoS fixes this in a LAN enviroment which could be viewed as bursty system where as internet switches tend to be more smooth flow in nature (if I'm wrong on this one, I'd like to hear about it). Ray Burkholder > -----Original Message----- > From: Charles Youse [mailto:cyouse@register.com] > Sent: February 10, 2003 14:03 > To: Bill Woodcock; nanog(a)nanog.org > Subject: RE: VoIP QOS best practices > > > > That doesn't seem to make a lot of sense - is it that QoS > doesn't work as advertised? > > As someone who is looking to deploy VoIP in the near future > this is of particular interest. > > C. > > > -----Original Message----- > From: Bill Woodcock [mailto:woody@pch.net] > Sent: Monday, February 10, 2003 12:48 PM > To: nanog(a)nanog.org > Subject: Re: VoIP QOS best practices > > > > > > Looking for some links to case studies or other > documentation which > > > describe implementing VoIP between sites which do not > have point to > > > point links. From what I understand, you can't > enforce end-to-end QoS > > > on a public network, nor over tunnels. I'm wondering > if my basic > > > understanding of this is flawed and in the case that > it's not, how is > > > this dealt with if the ISPs of said sites don't have > any QoS policies? > > QoS is completely unnecessary for VoIP. Doesn't appear to > make a bit of > difference. Any relationship between the two is just FUD from people > who've never used VoIP. > > -Bill > > >

2 1

Regional Exchange Peering Forum
by Pete Kruckenberg 11 Feb '03

11 Feb '03

As a follow-up to the IX Operator Panel today, a Web site and mailing list have been set up to focus and expand the interests of regional exchange points. The REP Forum is intended for anyone who is interested in discussion and development of regional exchanges. This includes operators, participants and anyone interested in exploring or creating a regional exchange point. The REP Forum hopes to collect and share the knowledge and experience that has been developed by people who have built regional exchanges. The mailing list will be used to discuss and expand that knowledge-base and share ideas between REP projects. The REP Forum will provide information to create a regional exchange, or to make your current REP project more valuable (and hopefully more successful). This will initially focus on North American regional exchanges, though if there is interest from other areas of the world we will find a way accomodate those. The REP Forum web site is at http://www.rep.net . The mailing list is available by sending "subscribe" to forum-request(a)lists.rep.net. If you know of regional exchang operators that might not subscribe to the NANOG mailing list, please forward this message to them, or send me their contact information. Thanks. Pete.

1 0

Streaming problem?
by Paul Thornton 11 Feb '03

11 Feb '03

Is there something hoopy up with the streaming? Attempts to connect are eventually failing, complaing that: rtsp://198.108.1.36/broadcast/NANOG/encoder/nanog27.rm is not found. Any fixes at the far end welcome... -- Paul

2 1

Spam Cost Resources [ trustworthy ]
by Martin Hannigan 11 Feb '03

11 Feb '03

Does anyone have a resource that they believe in when it refers to how much spam really costs Network operatos? http://www.nytimes.com/2003/02/09/magazine/09SPAM.html I'm trying to do some validation. Thanks. -M

2 1

OC-48 prices
by Brian Cashman 11 Feb '03

11 Feb '03

I'm trying to get a idea of what the current going rate is for intercity (not metro) OC-48. Can anyone give me some pricing information (even ballpark figures)? Pricing per mile would be helpful. Thanks, Brian Cashman Merit

1 0

Re: VoIP QOS best practices
by Stephen Sprunk 10 Feb '03

10 Feb '03

Reordering per se doesn't affect VoIP at all since RTP has an inherent resync mechanism. Reordering is also unlikely, since each packet is sent 20ms or more apart; I'm not aware of any network devices that reorder on that scale. S ----- Original Message ----- From: "Leo Bicknell" <bicknell(a)ufp.org> Sent: Monday, 10 February, 2003 12:43 Subject: Re: VoIP QOS best practices > - --OXfL5xGRrasGEqWY > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > In a message written on Mon, Feb 10, 2003 at 01:19:08PM -0500, chaim fried = > wrote: > > happens). There is no reason to implement QOS on the Core. Having said > > that, there still seems to be too many issues on the tier 1 networks > > with pacekt reordering as they affect h.261/h.263 traffic.=20 > > I've got a question about this issue. Many networks reorder packets > for a number of reasons. At least once before I've attempted to > measure the effects of this reordering on a number of forms of > traffic, but I have never understood the particular effects on VOIP > traffic. > > Indeed, the two times I was asked to investigate this for video > people it turns out the video receivers /had no ability to handle > out of order frames/. That's right, get one packet out of order > and the video stream goes away until it resynchronizes. Now, I > realize reordering should not happen to a large percentage of the > packets out there, but it also seems to me any IP application has > to handle reordering or it's not really doing IP. > > So what's the real problem here? Are the VOIP boxes unable to > handle out of order packets? Do the out of order packets simply > arrive far enough delayed to blow the delay budget? What percentage of > reordered packets starts to cause issues? > > - --=20 > Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org > > - --OXfL5xGRrasGEqWY > Content-Type: application/pgp-signature > Content-Disposition: inline > > - -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.4 (FreeBSD) > Comment: For info see http://www.gnupg.org > > iD8DBQE+R/LkNh6mMG5yMTYRAsn4AJ9Y1vO1RILDjvGdTJUPmiiknUlpHgCfedQm > rOH5KvKO+PVnSVoLPZkG4zI= > =LCXI > - -----END PGP SIGNATURE----- > > - --OXfL5xGRrasGEqWY-- > > ------------------------------ >

3 2

RE: VoIP QOS best practices
by Charles Youse 10 Feb '03

10 Feb '03

My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. C. -----Original Message----- From: Bill Woodcock [mailto:woody@pch.net] Sent: Monday, February 10, 2003 1:05 PM To: Charles Youse Cc: nanog(a)nanog.org Subject: RE: VoIP QOS best practices > That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away? > As someone who is looking to deploy VoIP in the near future this is of particular interest. Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work. -Bill

7 7

Streaming dead
by Eric Germann 10 Feb '03

10 Feb '03

rtsp://198.108.1.36/broadcast/NANOG/encoder/nanog27.rm file not found. 22:39GMT QoS has been real spotty, from many differing networks today. multi 10's of seconds gaps in audio or video. ========================================================================== Eric Germann CCTec ekgermann(a)cctec.com Van Wert OH 45801 http://www.cctec.com Ph: 419 968 2640 Fax: 603 825 5893 "The fact that there are actually ways of knowing and characterizing the extent of one’s ignorance, while still remaining ignorant, may ultimately be more interesting and useful to people than Yarkovsky" -- Jon Giorgini of NASA’s Jet Propulsion Laboratory

2 1

Re: VoIP QOS best practices
by Stephen Sprunk 10 Feb '03

10 Feb '03

Thus spake <Valdis.Kletnieks(a)vt.edu> > On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse <cyouse(a)register.com> said: > > That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? > > Qos is designed for dealing with "who gets preference when there's > a bandwidth shortage". Most places are having a bandwidth glut at > the moment, so the VoIP traffic gets through just fine and QoS isn't > able to provide much measurable improvement. That's certainly true of ISPs, but most VoIP is over bandwidth-starved private networks. S

1 0