- Test - lists.nanog.org

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

10 Feb '03

But in order for RTP to resync the out-of-order packets it must introduce some delay, no? And that delay causes issues. C. -----Original Message----- From: Stephen Sprunk [mailto:stephen@sprunk.org] Sent: Monday, February 10, 2003 5:21 PM To: Leo Bicknell Cc: North American Noise and Off-topic Gripes Subject: Re: VoIP QOS best practices 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-- > > ------------------------------ >

1 0

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

10 Feb '03

Thus spake "Bill Woodcock" <woody(a)pch.net> > 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. To paraphrase Randy, I encourage all of my competitors to think like this. Iff you operate a network with enough excess capacity to keep jitter and packet loss within acceptable limits, you do not need QOS. Most real networks are far from that ideal, however. S

1 0

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

10 Feb '03

You are mistaking utilization for congestion. At the packet level, a link is congested if it is not immediately available for transmit due to one or more previous packets still being queued/transmitted. This transient congestion causes jitter, VoIP's worst enemy. Certainly, as utilization rises so will congestion; however, it is quite common to have transient congestion while overall utilization is minimal. S ----- Original Message ----- From: "Shawn Solomon" <ssolomon(a)ind.net> Sent: Monday, 10 February, 2003 12:54 Subject: RE: VoIP QOS best practices > If you are in an environment where the uplink is already saturated, or > nearly so, QOS is necessary. But QOS only discards packets in times of > contention. So, if you don't have contention, you don't need it. IF > you have 300 people and 4meg of data all fighting for that t1, it makes > a world of difference. > > > - -----Original Message----- > From: Bill Woodcock [mailto:woody@pch.net]=20 > Sent: Monday, February 10, 2003 1:28 PM > To: Charles Youse > Cc: nanog(a)nanog.org > Subject: RE: VoIP QOS best practices > > > > But I could conceivably have 10+ voice channels over a T-1, I > still > > don't quite understand how, without prioritizing voice traffic, > the > > quality won't degrade... > > Well, of course it all depends how much other traffic you're trying to > get > through simultaneously. Your T1 will carry ~170 simultaneous voice > streams with no conflict, but you have to realize that they'll stomp on > your simultaneous TCP data traffic. But you don't need to protect the > _voice_... > > Look, just do it, and you'll see that there aren't any problems in this > area. > > -Bill > > ------------------------------ >

1 0

probable DDOS to 195.238.3.33
by Bulger, Tim 10 Feb '03

10 Feb '03

We're seeing packets with spoofed source addresses destined to 195.238.3.33 getting dropped on firewalls at several locations going outbound. Googling has turned up nothing relating to that destination IP address. Is anyone else seeing this? Anyone know what it is? Thanks, Tim

4 3

VoIP QOS best practices
by Jason Lixfeld 10 Feb '03

10 Feb '03

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? -jL

6 16

primustel peering issue???
by Scott Granados 10 Feb '03

10 Feb '03

Hi I wrote to the noc but this seemed serious enough to mention on the list. . Seems that Primustel was trying to send me a transit feed ie full routes over our peer at Paix. I'm assuming that this also happened to other peers of theirs at Paix so you may wish to check your associated sessions. I believe its calmed down and I get the normal number of prefixes but it was strange for a few minutes. Scott

1 0

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

10 Feb '03

Speaking of codecs, what are the primary variables one uses when choosing a codec? I imagine this is some function of how much bandwidth you want to use versus how much CPU to encode the voice stream. C. -----Original Message----- From: Alec H. Peterson [mailto:ahp@hilander.com] Sent: Monday, February 10, 2003 1:40 PM To: Bill Woodcock; Charles Youse Cc: nanog(a)nanog.org Subject: RE: VoIP QOS best practices --On Monday, February 10, 2003 10:19 -0800 Bill Woodcock <woody(a)pch.net> wrote: > > It works fine on 64k connections, okay on many 9600bps connections. T1 is > way more than is necessary. I'd say that largely depends on which codec you are using and how many simultaneous calls you will have going. Alec -- Alec H. Peterson -- ahp(a)hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com

3 2

RE: probable DDOS to 195.238.3.33
by Bulger, Tim 10 Feb '03

10 Feb '03

Thanks to those who replied with how to find the owner of that IP address. ;) I was more curious about the cause of the traffic. Thanks, Tim -----Original Message----- From: Bulger, Tim Sent: Monday, February 10, 2003 12:06 PM To: nanog(a)merit.edu Subject: probable DDOS to 195.238.3.33 We're seeing packets with spoofed source addresses destined to 195.238.3.33 getting dropped on firewalls at several locations going outbound. Googling has turned up nothing relating to that destination IP address. Is anyone else seeing this? Anyone know what it is? Thanks, Tim

1 0

Webcast
by Martin Hannigan 10 Feb '03

10 Feb '03

The camera facing the slides appears to be out of focuse. If someone could adjust... Thanks. -M

3 2

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

10 Feb '03

G.711 gives you the 64kbps quality you get on a channel in a PRI line. No compression is performed. G.729 is a well accepted codec that performs compression, and with ip packet overhead, uses about 16 to 24 kbps (can't remember which). It gives voice quality very close to G.711. G.723 has a noticeable voice quality change, and is in the 6 to 8 kbps range. The optimal is G.729 for quality vs bandwidth issues. There are some other considerations involved but these are the main ones. Ray Burkholder > -----Original Message----- > From: Charles Youse [mailto:cyouse@register.com] > Sent: February 10, 2003 14:42 > To: Alec H. Peterson > Cc: nanog(a)nanog.org > Subject: RE: VoIP QOS best practices > > > > Speaking of codecs, what are the primary variables one uses > when choosing a codec? I imagine this is some function of > how much bandwidth you want to use versus how much CPU to > encode the voice stream. > > C. > > -----Original Message----- > From: Alec H. Peterson [mailto:ahp@hilander.com] > Sent: Monday, February 10, 2003 1:40 PM > To: Bill Woodcock; Charles Youse > Cc: nanog(a)nanog.org > Subject: RE: VoIP QOS best practices > > > --On Monday, February 10, 2003 10:19 -0800 Bill Woodcock > <woody(a)pch.net> > wrote: > > > > > It works fine on 64k connections, okay on many 9600bps > connections. T1 is > > way more than is necessary. > > I'd say that largely depends on which codec you are using and > how many > simultaneous calls you will have going. > > Alec > > -- > Alec H. Peterson -- ahp(a)hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com >

2 1