Re: [codec] #16: Multicast?

[stephen botzko <[e-mail]>]

In-line

Regards
Stephen Botzko

On Tue, May 4, 2010 at 10:21 PM, Raymond (Juin-Hwey) Chen <
[e-mail]> wrote:

> Hi Stephen,
>
> > If the frame-size multiplier is due to serialization, then I agree with
> > Koen's assessment.  In fact on many connections the multiplier would be
> > less than 1. Dial-up is of course the worst case here, and on those
> > links the multiplier ought to be close to 2.  Variations due to
> > congestion (and on some links, polling) are (IMHO) better modeled as
> > jitter.
> [Raymond]: The frame-size multiplier has many more components than just
> serialization as I have discussed in my previous emails.  How can the total
> multiplier be less than 1 when just buffering the current frame of input
> speech samples will take one frame?  Perhaps you are only talking about the
> serialization delay component?  I agree that delay variations due to
> congestion are better modeled as jitter.  That's always the case, and my
> previous discussions did not include jitter in the codec-dependent delay.
>

Generally the need to buffer the current frame is treated as part of the
algorithmic delay.  At least I believe that is what the ITU-T does.

So maybe we need a list of what all these components are?  I'd suggest
keeping the gateway out of it for the first pass.


>
> > Gateways are another matter, with the delays being highly dependent on
> > the product architecture.  Interupt latencies, context switching, bus
> > architectures, etc. can dominate, so it is totally possible that
> > reducing the frame size might actually increase the latency (since it
> > increases the packets per second load on the gateway).  So I agree with
> > Koen on this as well.
> [Raymond]: I agree with the first half of your paragraph above but not the
> second half, because the second half contradicts with the real-world
> observed behaviors: G.711 with a 5 ms frame/packet size gets 12 to 17 ms of
> codec-dependent delay, while G.711 with a 10 ms frame/packet size gets 50 to
> 60 ms of worst-case codec-dependent delay before delay optimization, and 30
> ms after delay optimization.  In these two actual real-world VoIP gateway
> implementations, the codec-dependent delay grow with the codec frame size
> with about a 3X multiplier.
>
I've worked with Gateways\MCUs where the packet size had to be increased
because packet loading in the product became too high.  Also, if you have
QOS features enabled in many routers, the routers themselves have to start
using a "software path", which creates a similar throughput problem in the
routers.  Too many packets per second can overwhelm these devices, creating
both capacity issues and excessive queuing delays.


>
> > Anecdotal models based on industry experience can be useful guides -
> > though if we are going to use these models to drive requirements, I'd
> > prefer something more analytical.
> [Raymond]: We broke down the one-way delay into codec-independent delay and
> codec-dependent delay, and then further broke down the codec-dependent delay
> into the components of codec buffering delay, processing delay, transmission
> delay (I guess what you called serialization delay), and scheduling and
> buffering delays of the micro-controllers and DSPs due to many tasks to many
> channels competing for the processors, etc. We also analyzed which part
> doesn't change with improving technology (e.g. codec buffering delay) and
> how certain delay components may change with increasing processor speed and
> transmission speed.  Isn't that analytical?  How much more analytical can
> you get than that?  We didn't just throw a few real-world observed
> codec-dependent delay values and ask everyone to believe the 3X multiplier
> without any explanation or analysis. No, we just used these real-world
> values to support our analysis.
>
Serialization is just one component of transmission delay, and is
independent of distance.  As it turns out, it is the network delay component
that depends on packet size.

I don't think the group has an agreed-upon model which names these
components consistently, and describes are appropriately in-scope and which
are out-of-scope.  Perhaps that is one reason why Koen is saying multiplier
the number is 1x.

Also, there are real-world negative consequences to higher packet rates, and
we have not yet considered them.