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.