Re: [rtcweb] Plan A, respun
Harald Alvestrand <harald@alvestrand.no> Fri, 17 May 2013 06:32 UTC
Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D1D21F92EC for <rtcweb@ietfa.amsl.com>; Thu, 16 May 2013 23:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level:
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8vK7Uc0mBm7 for <rtcweb@ietfa.amsl.com>; Thu, 16 May 2013 23:32:07 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D605A21F9344 for <rtcweb@ietf.org>; Thu, 16 May 2013 23:32:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C66F439E0D7; Fri, 17 May 2013 08:32:02 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obe1yLgp5zp5; Fri, 17 May 2013 08:32:00 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:d594:249c:4a90:3766] (unknown [IPv6:2001:470:de0a:27:d594:249c:4a90:3766]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 08F8B39E01E; Fri, 17 May 2013 08:31:59 +0200 (CEST)
Message-ID: <5195CEDF.9040109@alvestrand.no>
Date: Fri, 17 May 2013 08:31:59 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <CABcZeBO+miF-euyyKFDrpMUdnV-Ej2QaZgKmiMc2Yp08QUyz7A@mail.gmail.com>
In-Reply-To: <CABcZeBO+miF-euyyKFDrpMUdnV-Ej2QaZgKmiMc2Yp08QUyz7A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------050009050304080104060200"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan A, respun
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2013 06:32:12 -0000
On 05/17/2013 01:28 AM, Eric Rescorla wrote: > > > On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand > <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote: > > If the true limit at which one has to change allocation > strategy were to become 96, not 32, it actually > strengthens my "falling off a cliff" argument > > > And, to be clear, it's not a cliff. For any given session > (without a=ssrc:), you have to allocate ceiling(streams/96) > ports. It's not like you go from using one port to using 97 > ports when you add the 97th stream. You go from one port to > two, which will handle 192 streams. > > > Going from one port to two ports is a cliff. > We may have differing opinions on how tall it is. > > > Harald, > > I am not following how this is a discriminating factor between Plan A and > Plan B. > > In both Plan A and Plan B, any media stream which is intended to be > independently processable by a legacy endpoint must appear on its > own m-line. That means it must also have its own independent ports, > even if you are hoping to eventually be able to mux it via BUNDLE. I agree with this characterization - the two proposals have the same number of ports in the initial offer. I quibble about the characterization "any media stream which is intended to be independently processable by a legacy endpoint must appear on its own m-line." As Bernard has said, the field of deployed applications is diverse enough to make this question confusing - both "independently processable" and "legacy endpoint" may need further qualification in order to make that statement unequivocally true. > > In both Plan A and Plan B, it is possible to indicate additional media > streams that are not processable by a legacy endpoint but that > will be processable by a new endpoint: > > - In Plan A, this is done by marking them bundle-only > - In Plan B, this is done by having them be additional SSRCs on one > of the extant m-lines. > > > > Regardless of Plan A versus Plan B, bundle contemplates having > multiple media flows on the same media 5-tuple. Thus, it must > be possible to demux the flows somehow. As I read Plan A, > it proposes using both PT and SSRC to demux whereas plan B > only wants to use SSRC? So, the implication is that a Plan A > endpoint must: > > 1. Demux on both PT and SSRC (this is trivial, I think you will agree) The demuxing is trivial. In fact, I don't think it's even necessary to describe it as "demux on PT"; you can't allow SSRC collision between two tracks with different PT anyway. > 2. When acting as offerer, either always offer SSRC or conditionally > offer SSRC when the # of PTs is excessive. > > I don't understand why you think that plan A means more ports than > plan B. Presumably we can simply specify that bundle requires > SSRC muxing, in which case plan A and plan B behave identically. > > What am I missing? This particular issue is about what happens when you run out of payload types to multiplex on. In Plan A as I currently understand Adam, any application that needs less than 96 M-lines (Adam's number) can use a single port, and use the payload type to indicate the M-line. If there are 97 M-lines, if I've understood Adam correctly, one could use two ports and two bundles, with some subset of the M-lines being allocated to one bundle and another subset of the M-lines allocated to the other bundle. In Plan B, there is no difference in the mechanism used to multiplex 96 SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not matter for the multiplexing how many M-lines they are distributed over.
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Harald Alvestrand
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Jonathan Lennox
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Harald Alvestrand
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Dale R. Worley
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Martin Thomson
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Jonathan Lennox
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Emil Ivov
- [rtcweb] MSID fallback for non-MSID case (Re: Pla… Harald Alvestrand
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Kevin Dempsey
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Christer Holmberg
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Bernard Aboba
- Re: [rtcweb] Plan A, respun Cullen Jennings (fluffy)