Re: [MMUSIC] Simulcast worries: Fallback in the a=rid language

Harald Alvestrand <harald@alvestrand.no> Thu, 22 October 2015 05:37 UTC

Return-Path: <harald@alvestrand.no>
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 A31E81B2E2F for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 22:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 MOMNmwa_biIZ for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 22:37:55 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7361B2DFA for <mmusic@ietf.org>; Wed, 21 Oct 2015 22:37:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6E8CE7C037D; Thu, 22 Oct 2015 07:37:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnM_Xidlix7Z; Thu, 22 Oct 2015 07:37:34 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1:6990:e3f4:94de:b939] (unknown [IPv6:2001:470:de0a:1:6990:e3f4:94de:b939]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7DA6F7C0350; Thu, 22 Oct 2015 07:37:34 +0200 (CEST)
To: Martin Thomson <martin.thomson@gmail.com>, Peter Thatcher <pthatcher@google.com>
References: <562799B8.9080609@alvestrand.no> <CABkgnnXsd0kr0T43Eu2CeC9Rg9Z9w-QBKw2L7aMub_oVyJWL3g@mail.gmail.com> <CAJrXDUHzMPibW0pzGqabeuGo0aNsMwPg+RGREj4T+PbZLnhCRQ@mail.gmail.com> <CABkgnnXPmubr_yCAuVzdYEXutDUrNrPYdTkRfzN7jBH9Fy1YJA@mail.gmail.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <5628761C.4030409@alvestrand.no>
Date: Thu, 22 Oct 2015 07:37:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CABkgnnXPmubr_yCAuVzdYEXutDUrNrPYdTkRfzN7jBH9Fy1YJA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/U_LtiUOsh9ClI2Wnt1-bAuX3y5Y>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Simulcast worries: Fallback in the a=rid language
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: Thu, 22 Oct 2015 05:37:57 -0000

On 10/22/2015 12:23 AM, Martin Thomson wrote:
> On 21 October 2015 at 15:05, Peter Thatcher <pthatcher@google.com> wrote:
>> But if you have max-goats and max-dogs and max-cats and the answerer
>> supports max-dogs but not max-goats or max-cats,  how can it structure it to
>> offer all the combinations of what might work and what might not?
> Yes, combinatorial explosion ensues.
>
> My view is that we aren't likely to add enough of these extensions
> that we will ever reach that explosion point.
>
> And if enough time lapses between introduction of different things,
> you can start to make assumptions about things, and do things like
> bundle max-dogs and max-cats together.  Sure, the guy who understands
> (not supports) only max-dogs falls back to the baseline, but as long
> as you have a baseline you don't suffer too badly.
>
> In practice, I think that this will only create a modest amount of
> pressure not to extend.  I can't actually think of a downside to that.
>
> BTW, this is a repeat of a similar discussion we had in HTTP.  There,
> we settled on having parameters be ignored if not supported.  I don't
> think that's feasible in this context because things like limits are
> important.
The logic is in fact different for the two directions.

If I tell someone I'm going to stick to a limit they don't know about
(send), no harm will come from ignoring the parameter - I can stick to
the limit anyway.

If I tell someone I can't take more than X from them (recv), it's
dangerous if they ignore it, because they can overrun my limitations
through ignorance.

That tells me that:

a) we need to think more about this
b) sendrecv is a bad idea





-- 
Surveillance is pervasive. Go Dark.