Re: [codec] #16: Multicast?

Mikael Abrahamsson <swmike@swm.pp.se> Sun, 25 April 2010 02:45 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E5B3A6B3E for <codec@core3.amsl.com>; Sat, 24 Apr 2010 19:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.54
X-Spam-Level:
X-Spam-Status: No, score=-4.54 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNZd8y+0sF22 for <codec@core3.amsl.com>; Sat, 24 Apr 2010 19:45:40 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id B34273A6B3C for <codec@ietf.org>; Sat, 24 Apr 2010 19:45:36 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4C3509F; Sun, 25 Apr 2010 04:45:20 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 493839E; Sun, 25 Apr 2010 04:45:20 +0200 (CEST)
Date: Sun, 25 Apr 2010 04:45:20 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "Raymond (Juin-Hwey) Chen" <rchen@broadcom.com>
In-Reply-To: <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A289@IRVEXCHCCR01.corp.ad.broadcom.com>
Message-ID: <alpine.DEB.1.10.1004250431070.6768@uplift.swm.pp.se>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <D6C2F445-BE4A-4571-A56D-8712C16887F1@americafree.tv> <C0347188-A2A1-4681-9F1E-0D2ECC4BDB3B@csperkins.org> <u2x6e9223711004210733g823b4777y404b02330c49dec1@mail.gmail.com> <000001cae173$dba012f0$92e038d0$@de> <r2q6e9223711004211010gfdee1a70q972e8239fef10435@mail.gmail.com> <001101cae177$e8aa6780$b9ff3680$@de> <t2t6e9223711004211119i6b107798pa01fc4b1d33debf1@mail.gmail.com> <002d01cae188$a330b2c0$e9921840$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017@IRVEXCHCCR01.corp.ad.broadcom.com> <4BD11C50.2020206@usherbrooke.ca> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A270@IRVEXCHCCR01.corp.ad.broadcom.com> <20100424135607.84293hkaa13j1zvr@mail.skype.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A289@IRVEXCHCCR01.corp.ad.broadcom.com>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] #16: Multicast?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Apr 2010 02:45:41 -0000

On Sat, 24 Apr 2010, Raymond (Juin-Hwey) Chen wrote:

> Of course not.  That's why I added the sentence: "Even if you use a 
> longer jitter buffer, the one-way delay is still unlikely to go above 
> 100 ms, ..." in that email you quoted. I knew that below a certain

The light-speed-in-fiber delay RTT is 1ms per 100km. Europe - US West 
coast is ~150ms RTT. I'm in Thailand at the momen. I have 350ms RTT to 
Sweden currently (because the path goes sweden->us->singapore>thailand), 
just to give some datapoints. Add then ADSL2+ 25ms RTT just over the 
access layer, and I'd say that 200ms network RTT (100ms one-way) might be 
a low percentage of the calls, but it's still definitely going to happen. 
Considering the prices of internationall calls out of a place like this, a 
lot of people are going to want to use it to get around it.

I talked to my mother over skype yesterday, because international calls 
are like 0.5USD/minute. To get around the huge jitter and packet loss I 
have on the access, it cranked up the jitter buffers to 2-3seconds. I 
still prefer this to paying 0.5USD/minute.

So these are the diverse network conditions that the solution (where the 
codec is a part) needs to handle, it needs to be able to do interactive 
voice etc over a local network in cd (at least) quality, plus it needs to 
give intelligeble speech communication (walkie talkie quality if needed) 
over very adverse network conditions.

GPRS-EDGE here works fairly well, better than the Wifi I'm on, it might 
very well be that using GPRS-EDGE with 4pps (250ms per packet so as to get 
vey low packet header overhead)) and a very low-bw codec would be better 
than the Wifi.

I absolutely agree that we need quite a few different modes, and these 
need to be decoupled from each other because different conditions need 
different responses from the solution. Low pps for some, low quality but 
high pps for others, and of course all the other combinations of the 
factors involved.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se