At the IP layer, many modern codecs overcome the QoS of The Internet by having multiple streams allowing devices to send and receive multi-layered video streams composed of a small base layer and optional additional layers that enhance resolution, frame rate and quality.

I have seen a transit provider who is/was preferring small packets (traditional VoIP) but once the packets reached a larger size such as containing the HD and extra frame rate components these were going down a larger (layer 2, different framing etc) bandwidth channel with some extra internal hops. However it increased latency from the base layer such that there was too much to actually be useful to build on the baselayer stream presentation. The only (ok.. easiest) fix in this case, was to move to a different peer who actually wasn't treating VoIP with any difference.



Now for a telco to know/detect and oblige priority for particular streams would be tricky.


On 07/06/12 13:35, Matthew Ford wrote:
>
>    http://www.iab.org/cc-workshop/
>
> Mat



On 07/06/12 19:49, Neil J. McRae wrote:
in some cases yes - ATM based DSL lines are particularly bad at coping
with VoIP under congestion - I presented some stats from my days at COLT
on this at UKNOF4 I think.

However even with QoS and other priority chaos there is still no
guarantee even on IP friendly access links.

On 7 Jun 2012, at 13:12, Justin Finkelstein wrote:

> Good point - I hadn't thought of that. If we consider streaming video
> (within the context of communications) we're then talking about 2-way
> live video feeds. I imagine at this point, the bandwidth requirements
> would jump rather considerably and the ability to shape/prioritise
> this traffic would become more complex as (IIRC) we're not just
> talking about small UDP packets any more.




--
The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

Reply via email to