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@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@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@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--
------------------------------
Reordering per se doesn't affect VoIP at all since RTP has an inherent resync mechanism.
Most VoIP implementations don´t care about storing out-of-order packets because they think that 20ms or 30ms late packets should be thrown away in any case.
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.
Most "core" routers, at least from vendors C and J have enough packet memory to keep packets for hundreds of milliseconds. Apply sufficent per packet load balancing (which would be stupid but doable) to this, and you´ll arrive at the end result. Our observations tell us that reordering does not happen too much but there are periods from a few minutes to an hour where reordering from specific AS´s skyrocket to return to normal, in many cases even without observable path change. (MPLS in action?) Pete
On Tue, 11 Feb 2003, Petri Helenius wrote:
Reordering per se doesn't affect VoIP at all since RTP has an inherent resync mechanism.
Most VoIP implementations don´t care about storing out-of-order packets because they think that 20ms or 30ms late packets should be thrown away in any case.
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.
Most "core" routers, at least from vendors C and J have enough packet memory to keep packets for hundreds of milliseconds. Apply sufficent
Really.. including many Gigabit, OC-12,48 interfaces
per packet load balancing (which would be stupid but doable) to this, and you´ll arrive at the end result.
And its unlikely you will be doing this therefore..
Our observations tell us that reordering does not happen too much but there are periods from a few minutes to an hour where reordering from specific AS´s skyrocket to return to normal, in many cases even without observable path change. (MPLS in action?)
Pete
participants (3)
-
Petri Helenius -
Stephen J. Wilcox -
Stephen Sprunk