[e2e] Re: crippled Internet

[Henning Schulzrinne]

Also, it is not good enough that it works ok most of the time. It has to
work close to 100% of the time for close to 100% of the people (in a
reasonably well-described area, i.e., excluding users in Zambia or
customers of a particular carrier is ok, but saying "sorry, customers
whose IP address happens to be prime can't use is" is probably not a
usable service.) The numeric interpretation of close-to-100% is a matter
of debate, but I suspect that it's more than 99.9% (failure for 8
hours/year or 250,000 people in the U.S.).

We have gathered some related data (using real VoIP packet spacing) and
are in the process of gathering more. Volunteers at additional test
sites (preferably not on I2) are most appreciated.


Jon Crowcroft wrote:
> 
> actualyl ,i dont claim it works well scalably yet, but that it will
> tend to get better and better - its stil limportant to consider fancy
> queueing for weak points in the net and its still important to
> consider mechanisms to remove phase correlation so that we dont get
> these occasionaly HUGE delays which we all have seen (but can't find
> the really good experimental evidence for yet unelss i missed a
> message)
> 
> In message <E14slqq-000BiY-00 at rip.psg.com>, Randy Bush typed:
> 
>  >>> experience with actually using audio tools is that generally the net
>  >>> is not the main problem so long as neither end is dial up and both
>  >>> ends haev good analog audio setups -  can cite lots of papers pointing
>  >>> at the problems mostly being with mikes and speakers - typical tier 1
>  >>> and 2 paths are fine when there isnt inter-provider congestion.
>  >>
>  >>this makes sense.  thank you!
>  >>
>  >>scott called me voice to apply a clue-by-four.
>  >>  o voip packets are time-stamped, so the receiver can filter some jitter.
>  >>    (i like that relative stamping is sufficient.  the absoloute needed to
>  >>    measure one-way delay/jitter is a pain in the operational butt.  you
>  >>    try getting a gps antenna on the roof of a bunker-style pop)
>  >>  o there can be echo through analog gear at an end, or because mic and
>  >>    earpiece are air-coupled.  so echo cancellation is relevant.
>  >>  o codecs can introduce *significant* delay.  but, as i said, a network
>  >>    operator i can't do much about delay.
>  >>
>  >>[ and craig and a few others also passed on useful clue ]
>  >>
>  >>a whole lot of folk have written to tell me that voip actually works and
>  >>that i don't need to get too upset that i can't really deploy qos because
>  >>it is not clear it is a critical need.
>  >>
>  >>so my interest remains in the distribution of jitter in time and in jitter
>  >>clumping.  there are issues i have yet to understand here:
>  >>  o have folk characterized what is good/acceptable/bad?
>  >>  o do we have good ippm-style techniques to measure on those dimensions?
>  >>
>  >>the point was raised that folk do see occasional very large queuingX-Mozilla-Status: 0009seen single-hop delays (i.e. routing has nothing to do with it)
>  >>going into the multi-second range.  because of the bandwidth delay product
>  >>on trans-oceanic links, routers have *really* big buffers, so they can
>  >>have gawdawful queues.  but folk are still chasing *why* they have these
>  >>sudden exciting spurts of scary long queues.
>  >>
>  >>randy
> 
>  cheers
> 
>    jon