Return-Path: <emcho@sip-communicator.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
 with ESMTP id 9209B11E819D for <mmusic@ietfa.amsl.com>;
 Fri, 18 Oct 2013 07:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Level: 
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=-0.541,
 BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHOMJQ-vgFwP for
 <mmusic@ietfa.amsl.com>; Fri, 18 Oct 2013 07:44:55 -0700 (PDT)
Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com
 [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 509C111E82C4 for
 <mmusic@ietf.org>; Fri, 18 Oct 2013 07:44:52 -0700 (PDT)
Received: by mail-pd0-f179.google.com with SMTP id y10so1691908pdj.10 for
 <mmusic@ietf.org>; Fri, 18 Oct 2013 07:44:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;
 s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc:content-type:content-transfer-encoding;
 bh=Xgb+eTDiAFCeJelZe3QUtBkKn8stbnb0Ic9F7hoCFMk=;
 b=bTNxjCWESn+VpFZSfjk0YHBduvYJkGFVSRH/XY05wbZK6fu/c0DBAxU0aNJWZp+4c+
 p1ATklmuMIJBQjy9ezweanumbPB4htAuKcVJwPyD8qt34bmk7rzvqoRRKuzhpuaycisp
 jTR2mgsn/ij4Ro3MvAcAJ/om6OjsVcBPGWeXOUhYYcyglWZBQPbsz0RvwFYt6nS5eGA7
 RwrVUu7K9Zi8NNTQjKbvz2qiC4Y7GGDIFMTgwAQZ/x+YwhEP4GOl9xXBlQHNw8TQJJuD
 DOfatXIJEjpBiWs4IIwcvKaA0XnjBvDQJFrJu8v/UrdI5e501gYkjZJwfatZiZqgc4Mt 6kFQ==
X-Gm-Message-State: ALoCoQlxdQN/9wFA08OAUtsVJ8Akqh/UJgHUj0R4ye4s5sgamWPEgyWPAJX5waEY381hhgVZhhIJ
X-Received: by 10.68.253.1 with SMTP id zw1mr3496475pbc.30.1382107491925;
 Fri, 18 Oct 2013 07:44:51 -0700 (PDT)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com
 [2607:f8b0:400e:c03::230]) by mx.google.com with ESMTPSA id
 fk4sm4844708pab.23.2013.10.18.07.44.51 for <mmusic@ietf.org> (version=TLSv1
 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 07:44:51 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id bj1so4604317pad.7 for
 <mmusic@ietf.org>; Fri, 18 Oct 2013 07:44:51 -0700 (PDT)
X-Received: by 10.67.11.103 with SMTP id eh7mr3838142pad.153.1382107491412;
 Fri, 18 Oct 2013 07:44:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Fri, 18 Oct 2013 07:44:31 -0700 (PDT)
In-Reply-To: <526147C3.9040204@ericsson.com>
References: <526147C3.9040204@ericsson.com>
From: Emil Ivov <emcho@jitsi.org>
Date: Fri, 18 Oct 2013 09:44:31 -0500
Message-ID: <CAPvvaa+8osKGTNCS6RJywS9Bmf+RdbnChN=XqA9d+gLnBBAGow@mail.gmail.com>
To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= <ari.keranen@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>,
 <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>,
 <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2013 14:44:59 -0000

It might be worth reminding exactly what these 50ms would be
protecting us against, and why is it that we don't need to be
protected against it in the case of RTP where 20ms is accepted as a
fine default value.

Emil

--sent from my mobile

On Fri, Oct 18, 2013 at 9:37 AM, Ari Ker=E4nen <ari.keranen@ericsson.com> w=
rote:
> Hi all,
>
> Trying to close the open issue on the pacing of ICE connectivity checks, =
we
> still need to come up with the "new conservative default value" for the
> minimum pacing time with non-RTP traffic.
>
> When this was discussed at the Orlando meeting, I proposed 100 ms (see [1=
]
> and [2]) but during the meeting there was a question that why could not w=
e
> make this even smaller (e.g., 20 ms).
>
> If we think about the worst case scenario with maximum length username
> fragment (256 bytes), that results in maximum size ICE connectivity check
> packets of about 330 bytes. Add a few extensions, rounding it up to 350
> bytes, we're still at 35 ms "safe" pacing interval if we follow the
> rationale proposed by Cullen in [1] (i.e., similar bandwidth requirement =
as
> with G.711).
>
> So, to be "conservative enough", how about 50 ms RECOMMENDED pacing value=
 if
> there's no better knowledge of the network? And if there is, scale
> accordingly, but not below 20ms.
>
>
> Cheers,
> Ari
>
> [1] http://www.ietf.org/mail-archive/web/mmusic/current/msg10448.html
> [2]
> http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic#_Interactive=
_Connectivity_Establishment
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic



--=20
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31
