Re: [rtcweb] DRAFT Agenda for RTCWEB

Harald Alvestrand <harald@alvestrand.no> Sat, 02 March 2013 10:27 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 D67AB21F90EB for <rtcweb@ietfa.amsl.com>; Sat, 2 Mar 2013 02:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.474
X-Spam-Level:
X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRzdFVYhJ-5k for <rtcweb@ietfa.amsl.com>; Sat, 2 Mar 2013 02:27:05 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3078021F90C1 for <rtcweb@ietf.org>; Sat, 2 Mar 2013 02:27:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0607E39E0FE for <rtcweb@ietf.org>; Sat, 2 Mar 2013 11:27:03 +0100 (CET)
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 UdjvkykQcGzm for <rtcweb@ietf.org>; Sat, 2 Mar 2013 11:27:01 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:b136:6ef7:2913:b4cd] (unknown [IPv6:2001:470:de0a:27:b136:6ef7:2913:b4cd]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2590D39E0A7 for <rtcweb@ietf.org>; Sat, 2 Mar 2013 11:27:01 +0100 (CET)
Message-ID: <5131D3F4.4040501@alvestrand.no>
Date: Sat, 02 Mar 2013 11:27:00 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA+9kkMALouyyzN4dcGdF92TO2HGcBHbHR6fvHg7QC-x5ndCGjw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <201303011558.r21FwfGb2830347@shell01.TheWorld.com> <112a01ce16ae$a1720d90$e45628b0$@cisco.com>
In-Reply-To: <112a01ce16ae$a1720d90$e45628b0$@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB
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: Sat, 02 Mar 2013 10:27:06 -0000

On 03/01/2013 07:57 PM, Dan Wing wrote:
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>> Of Dale R. Worley
>> Sent: Friday, March 01, 2013 7:59 AM
>> To: Ejzak, Richard P (Richard)
>> Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB
>>
>>> From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
>>>
>>> Since multiplexing of the data channel with RTP media has been shown
>>> as a desirable feature of BUNDLE (and most of its variants), I would
>>> suggest that this be treated as a significant advantage for BUNDLE
>>> (and similarly capable variants) over any proposal without it.
>>> Cullen's "Plan A" is preferred over Plan B precisely because it has an
>>> incremental muxing advantage.
>> As far as I can tell from my analysis
>> (http://tools.ietf.org/html/draft-worley-sdp-bundle-04#section-8),
>> SCTP-over-DTLS can be demuxed from RTP and STUN quite easily.  (This
>> comes from RFC 5764 section 5.1.2.)  And SCTP can be demuxed from the
>> rest as long as you control the range of SCTP ports used.  (And since
>> the ports aren't actually to route the packets to the receiver (the
>> underlying UDP does that), you have freedom in choosing SCTP ports.)
>>
>> So I don't see anything blocking Plan A as compared to Plan B.  Of
>> course, we have to *do* a bundle technique, but we've got a large
>> library of possibilities now and can look at the fundamental design
>> questions in context.
> The analysis should also examine impact of port-based QoS on
> multiplexing data over the same port as audio.  Even audio and
> video often prefer different drop precedence.  I know the general
> consensus is to just supply more bandwidth, yet we consume all
> available bandwidth much like disk space, memory, and CPU/GPU
> cycles.
>
A reason for the particular way BUNDLE is designed is so that it permits 
you to bundle all the audio separately from all the video if that's your 
desire.
It just doesn't force you to do so.

Once we have BUNDLE in place and the m-line thing settled, we can return 
to the issue of what the default operational mode should be.