nanog mailing list archives
RE: VoIP QOS best practices
From: "chaim fried" <cfried () wireone com>
Date: Mon, 10 Feb 2003 14:14:00 -0700
Good point. Later version from the larger video-conferencing Gateway manufacturers, seem to do a better job (better- not perfect) handling reordering. So clearly there seems to have been issues with the applications buffering itself. Out of order packets are considered lost, so whatever you would put your tolerance threshold for loss will determine your tolerance for ou of sequence? I would measure in terms of .0x% for my customers, who expect "toll-quality" video. Based on the traces we've examined, most of the time it's not that the latency is too much to be rectified with proper buffering. However, again we don't want anybody reordering our packets.
-----Original Message----- From: Leo Bicknell [mailto:bicknell () ufp org] Sent: Monday, February 10, 2003 11:44 AM To: nanog () nanog org Subject: Re: VoIP QOS best practices 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 saidthat, there still seems to be too many issues on the tier 1networkswith pacekt reordering as they affect h.261/h.263 traffic.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? -- Leo Bicknell - bicknell () ufp org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request () tmbg org, www.tmbg.org
Current thread:
- Re: VoIP QOS best practices, (continued)
- Re: VoIP QOS best practices Jason Lixfeld (Feb 10)
- Re: VoIP QOS best practices Bill Woodcock (Feb 10)
- Re: VoIP QOS best practices Jason Lixfeld (Feb 10)
- Re: VoIP QOS best practices Stephen J. Wilcox (Feb 10)
- Re: VoIP QOS best practices Bill Woodcock (Feb 10)
- Re: VoIP QOS best practices Stephen J. Wilcox (Feb 10)
- Re: VoIP QOS best practices Bill Woodcock (Feb 10)
- RE: VoIP QOS best practices chaim fried (Feb 10)
- Re: VoIP QOS best practices Leo Bicknell (Feb 10)
- Re: VoIP QOS best practices Stephen J. Wilcox (Feb 10)
- RE: VoIP QOS best practices chaim fried (Feb 10)
- RE: VoIP QOS best practices Bill Woodcock (Feb 10)
- Re: VoIP QOS best practices Valdis . Kletnieks (Feb 10)
- RE: VoIP QOS best practices Bill Woodcock (Feb 10)
- RE: VoIP QOS best practices Alec H. Peterson (Feb 10)
- Re: VoIP QOS best practices Jared Mauch (Feb 10)
- Re: VoIP QOS best practices Bill Woodcock (Feb 10)
- Re[2]: VoIP QOS best practices John L Crain (Feb 10)
- Re: VoIP QOS best practices Petri Helenius (Feb 10)