February 2003 - Test - lists.nanog.org

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

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