(I think) Fred wrote: > Well, the extra delay is solvable in the transport. The question isn't really > what the impact on the > network is; it's what the requirements of the > application are. For voice, if a voice sample is > delayed 50 ms the jitter buffer in the codec resolves that - microseconds are > irrelevant.
If you meant 50 microseconds, ignore the rest of this post. 50 milliseconds is a *long* time in VoIP. The total mouth-to-ear delay budget is only 150 ms. Adaptive jitter buffer algorithms choose a buffer size that is bigger than the observed delay variation. So the additional delay will be even higher than 50 ms. Big frames are a problem on slower upstream links, even if you strictly prioritize VoIP and don't use jumbo frames. Some DSL providers resort to using two ATM VCs, just to prevent TCP packets from delaying VoIP. Wolfgang Beck -- Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einführung Heinrich-Hertz-Straße 3-7, 64295 Darmstadt +49 61516282832 (Tel.) http://www.telekom.com Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus Höttges (Vorsitzender) Geschäftsführung: Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 Erleben, was verbindet. _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
