Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Peter Thatcher <pthatcher@google.com> Mon, 16 November 2015 22:07 UTC

Return-Path: <pthatcher@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 2AE361A000D for <mmusic@ietfa.amsl.com>; Mon, 16 Nov 2015 14:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.963
X-Spam-Level:
X-Spam-Status: No, score=-1.963 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.585, 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 rvzkNV_bRln5 for <mmusic@ietfa.amsl.com>; Mon, 16 Nov 2015 14:07:52 -0800 (PST)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 D69E91B323E for <mmusic@ietf.org>; Mon, 16 Nov 2015 14:07:47 -0800 (PST)
Received: by oige206 with SMTP id e206so91567947oig.2 for <mmusic@ietf.org>; Mon, 16 Nov 2015 14:07:47 -0800 (PST)
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=Nfn++2LJv2yx4E6tC/C/acKr6jNxjd7dBH6roAdfeIs=; b=J23AphZMNzk7DmZguF+BA74Df71db9IHR4iC16rbL3Ljtd4ej1GGsDFb1IQ98rMk6z Ch2LyNSAoacfttU/80WTY+9EdmUwzwE/J0jC1F2I8ZWGZGunQJU+6i7poo09TP8CNv/G IlQN8HlzSaUa6El5JYbUjr+06L/SDmIuGcIKaGhgqKkDfd6nCxBc5mYFA52NfPm0REEh qcxplWKbFBPYjBMUaSMVBL9tbHI5UYza1TOr7pV0MWAM9/bW2tnVbVJR5W+ww223Gn4u VkdYswjtqiaDUEd77sbRrCV77bXcH2OP8HeV2lK2cmwKRGh8MLIfilH6bpVTJ3ktFmti zHgg==
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=Nfn++2LJv2yx4E6tC/C/acKr6jNxjd7dBH6roAdfeIs=; b=A7+D2Hj2iemkqG8mLYNar1Rt6q0B/uUQltCuloFT+EdvrKiHwvtgisdJ3eCFy7nbY9 9jt1um+9CWmhCp0EuuNePj0/VWm+8wCA077ZYXUbOjHaVqBqWSqiBX0XmimJafR2+Fi3 YTpCPQt+LLWGPPUKNwemfDqMCwlfoTmSdRGAgWMS6rb0bPt0McDsYgE45omUQ4X+owqb 3WvLIzjSWeU5a2npHzbzwD9q7EtLHsdLjAAwtHzczzaBZrjH/cfTpr9fK1GiC6bmhTU5 UX5U9xUQqGFcTxVkGUPFLXU9ujqq32UFDtyHSsB4VqkS4sr1xfhTs/BiI/y9XE01NOKN zl+A==
X-Gm-Message-State: ALoCoQk+rjCO72eTmvdqBMEkFsZoqQMPQhCqHo7OV10lgoKxH8vt1u6ufcz7Nyp981iMXNR6ZoSI
X-Received: by 10.202.231.204 with SMTP id e195mr7249775oih.136.1447711667103; Mon, 16 Nov 2015 14:07:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.69.4 with HTTP; Mon, 16 Nov 2015 14:07:07 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se>
References: <CAJrXDUHutBgaPOV73-CyD_Knz+G5RFE0VX4s3+GqGV8K=B1LNA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <CAJrXDUE0zutaCci2pojS6+=015DKqd7ocR5a9AWLoTC6jV+x6w@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <CAJrXDUFZUkogpX9Jnz-y1BxSbE0SnQE3CAg-EXy12-k9tFzjuA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se>
From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 16 Nov 2015 14:07:07 -0800
Message-ID: <CAJrXDUHaizhhikRVERNR4aDbe_KdE_RESWZY-1d57x1gtuFs_g@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a114039d0a7e6760524afa339"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Z1QM9oApGIrApTIzSjAi1sgFZMM>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
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: <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: Mon, 16 Nov 2015 22:07:55 -0000

On Fri, Nov 13, 2015 at 11:58 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> ...
>
> ​>I thinking mandating the candidates be duplicated in the answer has
> three issues:
> >
> >1.  It conflicts with trickle ICE.
> >2.  It's slightly more complex to implement (we have to go add extra
> logic to go duplicate these things)
> >3.  It's a complete waste of time/space/effort.  The recipient of these
> duplicate candidates is never going to anything with them.
>
> Those are all fair points. I wish we'd had more implementation input when
> we write our specs.
>

That's what I'm providing now :).  We can still change the spec, can't we?
​


>
> >>Also keep in mind that, when a subsequent offer is sent, the bundle-only
> attribute is no longer used.
> >
> ​>Can you point out where in the draft it says that?  I tried finding it
> and I had a difficult time seeing where bundle-only wasn't allowed in a
> reoffer.​
> ​
> Section 8.5.1 says:
>
>         "When an offerer generates a subsequent offer, it MUST assign the
>         previously selected offerer BUNDLE address [Section 8.3.2], to each
>         bundled "m=" line (including any bundle-only "m=" line), except
> if:"
>
> And, as the usage of the attribute is only defined when the port value is
> zero, it would not work when the BUNDLE address (read: non-zero port) must
> be associated with the m- line.
>
> Section 6 says:
>
>    "The usage of the 'bundle-only' attribute is only defined for a
>    bundled "m=" line with a zero port value, within an offer.  Other
>    usage is unspecified."
>

​Thanks.  That text would be more clear as "with an initial offer" instead
of "whithin an offer", since that's what it really means in conjuction with
8.5.1.

However, that's precisely the text that I think we could change.  I think
we could change the bundle-only attribute to be allowed in answers and in
subsequent offers.  Then clients could use the attribute as a way of
avoiding duplication of candidates and the complications with trickle ICE.​



>
> >>Would you then also in the subsequent offer only assign possible
> candidates to only one m- line within the bundle group?
> >
> ​>That sounds logical to me.  They aren't included in the first offer.
> Why add them to subsequent offers?  It's inconsistent, and a waste.
>
> Then someone could ask: what about other (non-candidate) attributes that
> must have identical values for each bundled m- line? Should those also be
> assigned to only one of the m- lines?
>
>
​If it's something unique to the bundle group, and not the m-line, that
seems reasonable to me.  ​
​
​But candidates are more painful than those would be because of the
interactions with trickle ICE.  If it weren't for trickle ICE this wouldn't
be as big of a deal.​




> >>>>>> 2.  If the answerer does not include any candidates in the answer
> and instead trickles them later, should it trickle them
> >>>>>> N times (once for each m-line in the BUNDLE group) or >1 time?  1
> time seems much more reasonable than N times, but
> >>>>>> if we duplicate candidates in the answer, but not duplicate them
> while trickling, that's a bit inconsistent.  Yet >another reason to not
> duplicate in the answer :).
> >>>>>
> >>>>> Assuming you use SDP to signal the trickled candidates, it’s true
> that you would duplicate them,
> >>>>>
> >>>>​What's the rationale for that?  These duplicates provide no value,
> and in the case of many m-lines (such as a conferencing
> >>>>system with many participants), we could be talking about 30x the
> number of candidates being signaled.
> >>
> >> I hear what you are saying.
> >>
> >>But, if we would do a change, we also need to look at the full picture,
> and consider subsequent offers etc.
> >
> ​> I think a simple rule would be "if you know it's going to be bundled
> onto another m-line, don't include candidates".  That would go for
> bundle-only m-lines in an offer, bundled m-lines in an answer, and >
> bundled m-lines in a re-offer.​
> ​
> Bundled m- lines in a re-offer can still be rejected by the answerer.
>

​That sounds the same as an initial offer.  How does it imply that a
re-offer must duplicate candidates across m-lines, even when an initial
offer doesn't need to?​
​



>
> Regards,
>
> Christer
>
>
>