IETF Logo Mail Archive

Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

Martin Thomson <martin.thomson@gmail.com> Fri, 22 May 2015 21:35 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEE11A88F1; Fri, 22 May 2015 14:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 oKz4Yrv3KhDc; Fri, 22 May 2015 14:35:39 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EAA1A8874; Fri, 22 May 2015 14:35:39 -0700 (PDT)
Received: by ieczm2 with SMTP id zm2so40366571iec.1; Fri, 22 May 2015 14:35:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uRVX9oJQTEuTSL3PfD3KOEQSGJp43SHuX93As7ZuKUE=; b=RCJvlePX4nj3A7EmyGXv3DRzJhjnmXp6g1/Q72W4dDJM53WvAHUf9j/wv6m/3wiqev dg3ilbvXWZAIwdOuyeYWFuzkmI+pqWPNUgSIOIJ8rC/9yBsc01+W8kPP9YYnkG0IFuWC qWW5S4IELBseBI1Z/XCAsjOPEDuJ7ffWJexsOzxUcBst1+prZlzr5Sb0Qc20RekHx58h yyG0oGC3AIcCf9f9Slof+gxViZQ0dEskfaiUIu/uwJTcVN0tmDDHcFe6I2m1jwBHvqd6 pToVO0rQGEqSed0PFXsEbdfR1sHRw3hm5W9s+6oY6sLq/OXSWGaqMdt9u/8xIcbtpI6v 5Xwg==
MIME-Version: 1.0
X-Received: by 10.42.50.81 with SMTP id z17mr11513795icf.57.1432330539089; Fri, 22 May 2015 14:35:39 -0700 (PDT)
Received: by 10.64.76.106 with HTTP; Fri, 22 May 2015 14:35:38 -0700 (PDT)
In-Reply-To: <CAPvvaaLdTM0pv34Rtw-tJKGAnWEzY+LmnBoHbseX42zOr8ud3w@mail.gmail.com>
References: <CAOW+2dsv8CVpaKoBsUvc5MGh2s3xD2J5NiXPAnFUMOhYqSmjzQ@mail.gmail.com> <CABkgnnWgpSYDjRQpk16Z0mCLietUcK1dSiNL-Y+jmFCpqan4Gg@mail.gmail.com> <CAOW+2dtDBxBBC7ToBGvP8cqYjGKUAYuR-5uL=NSjzE5iVwLRrA@mail.gmail.com> <CABkgnnUmcWUJDuems=P=vmifRGmhNvxv6=ps5O9-vmaQPYr=Ew@mail.gmail.com> <913383AAA69FF945B8F946018B75898A4785AE60@xmb-rcd-x10.cisco.com> <CAOW+2dt8GgcuREevwwo-PU=xzmm0MNgbyR7776bL9q9R1pa6yA@mail.gmail.com> <CABkgnnUzdBO5+YoFgWrkfD+O6++C3jNDHmD7TVeUdRAy=EuTKg@mail.gmail.com> <CAPvvaaLdTM0pv34Rtw-tJKGAnWEzY+LmnBoHbseX42zOr8ud3w@mail.gmail.com>
Date: Fri, 22 May 2015 14:35:38 -0700
Message-ID: <CABkgnnVvuptc0ZbbQbkVCMYhPNkYVyo_Uv_EmqqJmOUPN4_MvQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/GshjnhtwrlVXNP5TgMLjCyl-T68>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2015 21:35:44 -0000

On 22 May 2015 at 14:31, Emil Ivov <emcho@jitsi.org> wrote:
> Taking a step back, could you maybe remind us exactly why we are defining
> this new sort of a 30 second transaction instead of just using traditional
> STUN transactions every time our periodic timer fires?

Transactions take too long, they send too many checks, and those
checks appear too close together, meaning that they are prone to loss
due to routing transients.

I think that's it.  There's probably more.

> I wasn't able to find this here and there's no rationale in the draft. Was
> it maybe decided at a meeting at some point?

It was, or maybe on list.  It's been like this since almost the second
or third revision.

It's not that common to provide extensive rationale in specifications like this.

v2.23.0 | Report a Bug | By Email