At 01:35 PM 4/25/02, dj wrote: >on "slower speed" WAN links, does one have to fragment all large data >packets if the serialization delay introduced by the WAN link exceeds >the VoIP codec packet update interval? > >As an example, a 1500 byte data packet has roughly about a 23 msec >serialization delay thru a 512 kbits/sec WAN link. If my Voice codec is >sending VoIP packets at 10 or at 20msec intervals, am I forced to >fragment all large data packets over the WAN link?
You should check with Cisco, but I think in this case you are safe not fragmenting. I hate to introduce another variable, but you should consider that the recipient has a dejitter buffer. The dejitter buffer is probably big enough to handle the 23 millisecond delay caused by a 1500-byte frame, and that would be approximately your worst case. You must make sure that your queuing is set up to always send a voice packet when one is available. Your worst case, then, is just a single 1500-byte serialization delay. Sure, if your CODEC sends every 10 milliseconds instead of every 30 milliseconds, more voice packets may get queued, but this isn't a big deal if voice packets are always prioritized. Basically you are combining constant-bit rate voice traffic with variable-bit rate data traffic. The voice traffic arrives in a predictable, synchronous fashion. The data traffic arrives asynchronously, in a unpredictable fashion. Consider the case where your CODEC sends a voice packet at a constant rate of every 23 milliseconds. There could be some unpredictable jitter because of the asynchronous nature of data traffic, but because of your queuing, even the worst case is not a major problem: 1) The interface sends a voice packet. Another one won't arrive for 23 milliseconds. 2) 22 milliseconds go by. A data packet arrives! 3) The queuing algorithm allows the data packet to get transmitted, because no voice packet has arrived. It will take 23 milliseconds to send the data packet. 4) The voice packet arrives. It must wait. But that's the worst that can happen. The voice packet is delayed by 22 milliseconds. The recipient must be able to handle this. The receivers have dejitter buffers that are at least this big. Now let's say that voice packets arrive every 30 milliseconds. 29 milliseconds go by and a data packet sneaks in. It's still just 23 milliseconds of delay. So you're cool. Now let's say that voice packets arrive every 10 milliseconds. The worst case would be that 9 milliseconds go by and a data packet sneaks in. It's still just 23 milliseconds of delay. But in that time three voice packets would have gotten queued up. But they will go out right away after the data packet is done because of your queuing algorithm that always prioritizes voice, so you're probably still OK. Now, let's say you don't really have a 512-Kbps link, but a 256-Kbps link, in which case the time to output a 1500 byte packet is 46 milliseconds. Now you have more of a problem due to the longer time being more noticeable to the human ear (depending on the size of the recipient's dejitter buffer) and the fact that more voice packets can get queued up during that time. Queuing delay isn't nearly as much of an issue as serialization delay, but at some point it can become relevant. ARGH. It's making my brain hurt. I think you better ask Cisco. They have brilliant engineers who work this kind of stuff out better than I can. But I hope my brainstorming helped some. ;-) And once again, in the particular case that you bring up, I think you are OK not to fragment as long as the data packets aren't bigger than 1500 bytes. Priscilla >What if my Voice codec is sending VoIP packets at 30msec intervals; am I >fundamentally OK over a 512 kbits/sec WAN link assuming queuing is set >correctly for properly marked qos VoIP packets?? > >Thanks for the quick feedback >dj ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42594&t=42594 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
