Re: [rtcweb] Plan A, respun

Adam Roach <adam@nostrum.com> Thu, 16 May 2013 18:41 UTC

Return-Path: <adam@nostrum.com>
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 3B68B21F8E46 for <rtcweb@ietfa.amsl.com>; Thu, 16 May 2013 11:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, 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 PRw7g7+GOWVp for <rtcweb@ietfa.amsl.com>; Thu, 16 May 2013 11:41:52 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1CD21F8D92 for <rtcweb@ietf.org>; Thu, 16 May 2013 11:41:52 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4GIfaC8079334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 May 2013 13:41:37 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51952860.5030906@nostrum.com>
Date: Thu, 16 May 2013 13:41:36 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
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>
In-Reply-To: <519524EA.3000509@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
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: Thu, 16 May 2013 18:41:53 -0000

On 5/16/13 13:26, Harald Alvestrand wrote:

> I don't believe your comment (or the RFCs you cite) reflect currently 
> deployed reality. 

I'm not sure how much design we need to do to accommodate out-of-spec 
implementations. I would be interested in knowing how pervasive this 
behavior actually is in deployments, since the proper handling of 
dynamic PTs has been well documented for nearly a decade.

> 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.

And that's okay. As you approach 100 streams, I seriously doubt that 
port utilization is going to be the constraining factor in what your 
network can support.

/a