IETF Logo Mail Archive

Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Fri, 13 April 2018 15:07 UTC

Return-Path: <ietf@kuehlewind.net>
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 287B7124BE8 for <mmusic@ietfa.amsl.com>; Fri, 13 Apr 2018 08:07:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOLgUcbnw5C5 for <mmusic@ietfa.amsl.com>; Fri, 13 Apr 2018 08:07:13 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08F2126CF6 for <mmusic@ietf.org>; Fri, 13 Apr 2018 08:07:12 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=hgopqNIw7cok7Gy0kBsMWn0MkQ2vOvssmmRZtQ+P1NNVUhVNvrcZ88PJWUHlDgCNZDVsVwa+ynRQfH0h5qUezYt81JiHmLPoo47ust8+hPqhb+AaZS76KHvgMe/OSU6ZbvRuoBfBfATRjwJ2eQIckRWsDE1oASMndbhaMT65hjY=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 32146 invoked from network); 13 Apr 2018 17:06:10 +0200
Received: from i577bce4c.versanet.de (HELO ?192.168.178.24?) (87.123.206.76) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Apr 2018 17:06:10 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <6ce0a44f-cca8-2105-73f5-75689dd8c611@gmail.com>
Date: Fri, 13 Apr 2018 17:06:09 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-mmusic-trickle-ice-sip@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A91DAFC-8022-4B11-92F0-E6B7644A7218@kuehlewind.net>
References: <152276622276.14060.4683526444260158304.idtracker@ietfa.amsl.com> <d87ca5f9-3b36-d71e-667b-1396ea8a7ee9@gmail.com> <7CED4E17-86D2-407D-AF36-89C075121E9D@kuehlewind.net> <6ce0a44f-cca8-2105-73f5-75689dd8c611@gmail.com>
To: Thomas Stach <thomass.stach@gmail.com>
X-Mailer: Apple Mail (2.3445.6.18)
X-PPP-Message-ID: <20180413150610.32137.11649@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/_uoXbu1snItM7-clLUbf3rgU1ow>
Subject: Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 13 Apr 2018 15:07:15 -0000

Hi again!

I actually looked up the recommendation in RFC8085 section 3.1.3 which says:

"A second case of applications cannot maintain an RTT estimate for
       a destination, because the destination does not send return
       traffic.  Such applications SHOULD NOT send more than one UDP
       datagram every 3 seconds and SHOULD use an even less aggressive
       rate when possible."

> Am 08.04.2018 um 20:57 schrieb Thomas Stach <thomass.stach@gmail.com>:
> 
> In general, it is RECOMMENDED that a Trickle ICE Agent sends only one INFO request per RTT.
> A quarantine period of 100ms would be on the safe side, but lower values might be fine as well
> if the typically deployment scenario assumes a shorter RT.“

So a recommendation of 100ms is probably not appropriate here. Inline with RFC8085 it would be 3 seconds. Thus it probably makes sense to strongly recommend to implement a way to estimate RTT. Please also add a reference to RFC8085.

Sorry for my late input. I should have double checked with RFC8085 earlier. I hope this can still be addressed appropriately.

Mirja

v2.23.0 | Report a Bug | By Email