Re: [MMUSIC] Updating the pacing of ICE connectivity checks

Martin Thomson <martin.thomson@gmail.com> Fri, 15 February 2013 19:41 UTC

Return-Path: <martin.thomson@gmail.com>
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 0B12D21F86A6 for <mmusic@ietfa.amsl.com>; Fri, 15 Feb 2013 11:41:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.774
X-Spam-Level:
X-Spam-Status: No, score=-4.774 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2+rpBj7CL6g for <mmusic@ietfa.amsl.com>; Fri, 15 Feb 2013 11:41:35 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5561121F86A5 for <mmusic@ietf.org>; Fri, 15 Feb 2013 11:41:35 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id ez12so1579340wid.11 for <mmusic@ietf.org>; Fri, 15 Feb 2013 11:41:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qv0tu6AAVmHB/X4xgxms9EFUXtpcqSVOyt5MOxzg2UQ=; b=sHgn8uebG5+Ct1OR8ou6yc2o0IdDIGnb9FDCweOdOZVghZ+gPxHgCpm6FQ4OXr1NYR nWrdzOzVjYTYq05hB0ODtrY3PaqLD6j0qubShwI+Sq8nVqTd+fHZ6xuUfH/vMTVjRbai 9NaiF1nWLGuoJKB/Di0TpvTSZ2HcVyvdkvv4y/12t9MMfpuHQIIsfVWE7jmJK4obLEP1 6OY/M7tbo7d9mewXVHxzm7Hj1gmKGvh8NhQ+rG3wnmXoomG6cRq3fOTIXU4+b31vPHym YaWJbawvBLwbRrBNcLqPJctu4rX89fR8P43gk7vqLNv1YhWbMjf4AtdbstOLHxb7SV2G T2yA==
MIME-Version: 1.0
X-Received: by 10.180.80.35 with SMTP id o3mr8331191wix.9.1360957294354; Fri, 15 Feb 2013 11:41:34 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Fri, 15 Feb 2013 11:41:34 -0800 (PST)
In-Reply-To: <0a3c01ce0bae$540df920$fc29eb60$@cisco.com>
References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> <511E6696.6090609@ericsson.com> <511E6D72.7070206@jitsi.org> <0a3c01ce0bae$540df920$fc29eb60$@cisco.com>
Date: Fri, 15 Feb 2013 11:41:34 -0800
Message-ID: <CABkgnnVykg9UHqo1kyfx-PUEEqLXEo5_oXHrdWBb21u42kBEhA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Dan Wing <dwing@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, Ari Keränen <ari.keranen@ericsson.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Updating the 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, 15 Feb 2013 19:41:36 -0000

On 15 February 2013 10:57, Dan Wing <dwing@cisco.com> wrote:
> A quick a analysis of what browsers have been doing in this area:  The
> TCP retransmit timer on most OSs is 3 seconds.  But Firefox and Chrome
> have backup connection timers that are more aggressive (250ms and 300ms,
> if I recall correctly).  IE does not have a backup connection timer.  So
> they are not as aggressive as 20ms (which would be too aggressive on a lot
> of networks) but they also do not strictly follow the IETF TCP transport
> guidelines to retry a TCP connection after a long 3 seconds.

That's good info.  I could only find that for Firefox easily.  Given
that they also ignore the limit Dale pointed out and create 6
connections to any given server, this leads to an aggregate rate of
SYN packets of one every 50ms, though it's probably more bursty than
the even pacing required by RFC 5245.