Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

Justin Uberti <juberti@google.com> Wed, 30 July 2014 22:05 UTC

Return-Path: <juberti@google.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830A81A0657 for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 15:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
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 gc89itIgKZvX for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 15:05:42 -0700 (PDT)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419CA1A01CA for <mmusic@ietf.org>; Wed, 30 Jul 2014 15:05:42 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id lf12so2917128vcb.15 for <mmusic@ietf.org>; Wed, 30 Jul 2014 15:05:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UVrvXjhylxF5E4LYe4X3BGZrWismSoSsDjVpVFBUVhk=; b=B3HHb2/pDo2H7AqoZ5OB57pzSCOpcvEM2DCUoU0MZinfmu6Ez6cSd5apj5lexSY2wX RgTsfhwY7T585/E7WUkY2fV/yf3Dxe37A9LmMImcfLAzQ7d+8IfuDGJ8+QuojDL01CAJ 57/7BXNGw8vIKpGewB+8s9zrJ4nkdxZJwt8vB/1WWd5H8beESqZvzcZBPyzv+UIvJ41Q kM8glpW2lFenxfVvjB3OD40O+3bKISxh64MeTk/QFmZIxFpfp6pJrhM2Xqd8Zlt5Eqbr sXePCu/vyjV3XL6zSJaUbEPKSXLGNrndWGAL5G/mfI7VPiEbdRoSkKum/gYri/H5r0FI rsHw==
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; bh=UVrvXjhylxF5E4LYe4X3BGZrWismSoSsDjVpVFBUVhk=; b=AqdjZ95TvzctzOqUvpPC1txGMQ5zEybqLBYumAoqsZM0ZKqHWkbTFfBqA8L0DwSWOS GEd6P7EqPNBbS+mLfsB8gDOJLByPBWYwZapjVw2oLhoV8PLZDmUuNl193y2mruiB2DS1 Y2LM4xwsYeaQvSSby5CSAnO1ih+ju29prd80rOJoQvMPb2f9cDNsQEaWTKKWkopbdmuq VgqrjOpj//HLMsSP8uhxvVFkpnUvGhDW8GVB1OWpB3fCNdCbsRZaZgxdUwd0oUe0nWcb Uf8xfg7lYSIWm54y51rZdyvwz+9+KZ1bhwF1m9Mq1a653pf57NT4Mzfgidzry0ZbFQW6 g8DA==
X-Gm-Message-State: ALoCoQm17gz3WkevbpBVzJ7x+wKbEuDfynSLpiaxMASiC+RosiCksJa+5p/DogQQrnQHWjrevyo8
X-Received: by 10.53.5.163 with SMTP id cn3mr11117613vdd.3.1406757941452; Wed, 30 Jul 2014 15:05:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 15:05:21 -0700 (PDT)
In-Reply-To: <CABkgnnUjc45wHKK0NEGY5vUrMh7MibeNneEpTq+jW_ix6-33ig@mail.gmail.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <CAOJ7v-1jLK7dWDkWHKwHJ6qXicZWDNrAqOtw9R=6zAcWzkh5+g@mail.gmail.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <CAOJ7v-0HEjQQ+j0cAVc5r3Y4LxaoGF7EN2twGG6vTuMmEeragQ@mail.gmail.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <CAOJ7v-1HzGoUNXjvXph0-8WfpM6-vFJ+yDWhVw1_1grfrVD1Vw@mail.gmail.com> <B2794643-ADB5-4B66-98DC-841990C85437@vidyo.com> <CAPvvaa+oEe=FveAt2GtcG3ut8sVCbQYsr9sVxuHigD+3+oMa0w@mail.gmail.com> <CABkgnnUjc45wHKK0NEGY5vUrMh7MibeNneEpTq+jW_ix6-33ig@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 30 Jul 2014 15:05:21 -0700
Message-ID: <CAOJ7v-3ppSTqUhe-SR-GetDHaZccbiqr0gEN=iDgVnv4pnB76A@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=001a1133ce6e62bc5104ff705bd8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Ap_-BiSMmia4cJBhCC9vHbgXE8E
Cc: Jonathan Lennox <jonathan@vidyo.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 30 Jul 2014 22:05:44 -0000

On Wed, Jul 30, 2014 at 3:01 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 30 July 2014 14:48, Emil Ivov <emcho@jitsi.org> wrote:
> > When it's RTP you don't care where you get it from as long as you do. If
> > it's a DTLS client halo then what do you do exactly?
> >
> > Can the controlling agent simply respond on a different valid pair than
> the
> > one on which it received it? (This is what Chrome currently does but its
> > frowned upon by the DTLS/SRTP draft which binds the context to a specific
> > address:port). Does the controlled agent need to resend it on the new
> pair
> > after it gets the USE-CANDIDATE?
>
> RFC 5764 says this:
>    A single DTLS-SRTP session only protects data carried over
>    a single UDP source and destination port pair.
>
> But I'll postulate that this is only because the alternative (a
> shifting substrate) was not yet conceived.  There is nothing in (D)TLS
> that requires anything of the underlying transport protocol,
> intentionally.  (c.f., tcpinc wg)
>
> Firefox code seems to be OK (at least superficially) with the idea
> that packets can arrive from anywhere.  However, I can see why some
> implementations might get sad if things shift around.
>
>
Agreed. I think unless there is some dependency on the lower layer protocol
specifics (which should be uncommon, if at all), the expectation should be
that ICE is a generic, dynamic packet transport (AKA shifting substrate).