Re: [codec] #16: Multicast?

stephen botzko <> Thu, 06 May 2010 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B05F93A6A6D for <>; Thu, 6 May 2010 12:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.609
X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1QDbcWSHS7zP for <>; Thu, 6 May 2010 12:12:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CE0133A68A0 for <>; Thu, 6 May 2010 12:12:37 -0700 (PDT)
Received: by wwb18 with SMTP id 18so236704wwb.31 for <>; Thu, 06 May 2010 12:12:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6WhCNSre5jjD2w9Wou4ZHAQRZXDjIqqsN+jwE6RlZVQ=; b=W19h3lW+z8w2dUatPFUxE20BEAwF5AJ71rbjz0+mfzYeI8kKOhqhqW7HMdKNHI0oMW 0zt/gsLXvg5tFnXYAD+ITkdoIEAIvQI0VKzUOg9OpsSBQ42AaPeKlI8PiG1EMwb5M9LY c0DNnPQcw1YQBPaq7gup9QbcYReZ1zCnvJaZk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QexFI5fwLPghY15ShbcfvxIiuahggYzUXv0/oMxpD+Cfq8axndsJ7QNATP3Xu48tzl Ymgb7wNbyzSGEc5P6JPvP0BMuuP3x5ixXKsiwj3YbcWk3Eht3U1DlvFOitnqrJlHZJjg 3Aq9gsas7bUT6FJyN2UuxRIYIqYJL1iAxDzfk=
MIME-Version: 1.0
Received: by with SMTP id d62mr3235605wef.211.1273173141211; Thu, 06 May 2010 12:12:21 -0700 (PDT)
Received: by with HTTP; Thu, 6 May 2010 12:12:20 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Thu, 06 May 2010 15:12:20 -0400
Message-ID: <>
From: stephen botzko <>
To: "Raymond (Juin-Hwey) Chen" <>
Content-Type: multipart/alternative; boundary="0016e6d643ffd1cbbe0485f1b831"
Cc: "" <>
Subject: Re: [codec] #16: Multicast?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 May 2010 19:12:40 -0000

I basically agree with your points below.

There are lots of tradeoffs in codec design, including this one.  Personally
I think there is value in a moderate delay 20 ms frame size, possibly
augmented with a low-delay mode.  20 ms works quite well for video
conferencing, since the video frame rate is no faster than 60 fps (about 15
ms per frame).

Stephen Botzko

On Thu, May 6, 2010 at 3:03 PM, Raymond (Juin-Hwey) Chen <
> wrote:

> Hi Stephen,
> Sorry, I was too busy to respond yesterday.
> You wrote:
> > 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?
> [Raymond]: Sure, my previous analysis was an attempt to do just that, but
> perhaps my list was not complete enough.
> > I'd suggest keeping the gateway out of it for the first pass.
> [Raymond]: May I ask why?
> > 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.
> [Raymond]: OK, now I see what you meant when you said "it is totally
> possible that reducing the frame size might actually increase the latency".
> This is probably more likely to happen many years ago but less of a problem
> now, as I was told by networking guys that nowadays networking gears can
> handle 5 ms packets without problems.  In fact, the VoIP gateway I talked
> about, which has a 12 to 17 ms codec-dependent one-way delay for a 5 ms
> frame/packet size, was done 6 or 7 years ago.  Even back then the gateway
> can handle it without problems.
> > 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.
> [Raymond]: Yes, higher packet rates means higher packet header overhead
> bit-rates, more burden on networking gears in I/O bandwidth and throughput,
> etc.  However, that's the price to pay if we need low latency, just like if
> we want to avoid all these, the price to pay is higher latency.  It's all a
> matter of trade-off and the best choice depends on the application at hand.
> In Section 2 of Jean-Marc's Internet Draft
> draft-ietf-codec-requirements-00, 6 specific applications for the IETF codec
> were listed.  Fully 5 of these 6 applications list less than 10 ms of codec
> delay as either a requirement or a desirable feature. (The only exception is
> point-to-point calls.)  The only way to achieve this less than 10 ms codec
> delay is with a codec frame size of less than 10 ms, and to get the kind of
> low latency that these 5 applications desire, each packet had better contain
> only one codec frame as payload (rather than multiple frames).
> So, yeah, there is negative consequences of the resulting higher packet
> rates, but hey, if we want to get low latency as desired or required by
> these 5 applications, that's the price we will need to be prepared to pay.
>  There is no free lunch.  If we want to use a 20 ms frame/packet size to
> avoid those consequences, then we need pay the price of not achieving the
> low latency that these 5 applications desire or require.
> Raymond