[rtcweb] Repair Flows and No Plan (Was: No Plan)
Emil Ivov <emcho@jitsi.org> Tue, 04 June 2013 16:12 UTC
Return-Path: <emil@sip-communicator.org>
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 CDF8121E80E7 for <rtcweb@ietfa.amsl.com>; Tue, 4 Jun 2013 09:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6]
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 gAzj4E9oSNJC for <rtcweb@ietfa.amsl.com>; Tue, 4 Jun 2013 09:12:30 -0700 (PDT)
Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 37CEE21F9B06 for <rtcweb@ietf.org>; Tue, 4 Jun 2013 07:02:17 -0700 (PDT)
Received: by mail-bk0-f52.google.com with SMTP id e11so173309bkh.25 for <rtcweb@ietf.org>; Tue, 04 Jun 2013 07:02:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=WPxse0wNNGtIo1RljEur+vtd/r5vacDrb3cNNXIkkAM=; b=bREhDMTmn2NIwHKP49rSnr2E/nW0V0lF2S3pIvwGEgKofWGBIA6KrJMGbiOHTI/ZPf 3BvgHBjZCWIJh4Htlq46tpvJQmuzxcj7yv3Vx1FLyUis8qYGz8/Ee3xszv8bWs1P1Mea AkSfEkvbqeUx6g4Oav/A4gQGiaVNeVoKC4z2WjuLbYaaHRU5ypfDwtEDMEERyIcYFLuL Xf8q01ocJzI6NMIPFb1p1WterkAu7QNBXeIoXVghEdsmhJdmRiMx/AXxKAfqTz+Cs5qW 5fYF/0G1hwHmD4QE21kOj3JDiUuGgBfg6DqwZoxn2bvSlNIW0O/nI4+qEbeadJFAwpqT MZqA==
X-Received: by 10.205.25.6 with SMTP id rg6mr8098737bkb.101.1370354536691; Tue, 04 Jun 2013 07:02:16 -0700 (PDT)
Received: from camionet.local ([88.128.80.7]) by mx.google.com with ESMTPSA id da16sm23059034bkb.2.2013.06.04.07.02.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 07:02:15 -0700 (PDT)
Message-ID: <51ADD69E.2000708@jitsi.org>
Date: Tue, 04 Jun 2013 14:59:26 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
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: Bernard Aboba <bernard_aboba@hotmail.com>
References: <51A65017.4090502@jitsi.org>, <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, , <51A9A7E2.7000907@jitsi.org>, <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se>, <51ACFF31.9090607@alum.mit.edu>, <7426877E-42ED-400A-A264-39C692E71308@vidyo.com> <BLU169-W1201BB755F15FB7A1EF5E4A939D0@phx.gbl>
In-Reply-To: <BLU169-W1201BB755F15FB7A1EF5E4A939D0@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmPFs6Lh4BaQC7WvGXkemnTFd64/VDknBr195FP4FdbBYOZMKiPN4w6r2X3zfJbUaW4t7z/
Cc: Jonathan Lennox <jonathan@vidyo.com>, rtcweb@ietf.org
Subject: [rtcweb] Repair Flows and No Plan (Was: No Plan)
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: Tue, 04 Jun 2013 16:12:44 -0000
Hey Bernard, I obviously agree with what you are saying. Just one clarification regarding your layering and FEC comments: I don't think we are likely to come up with one generic mechanism that would work and should be used with all possible kinds of repair flows and scenarios. As you have pointed on occasion: these mechanisms vary largely. Some, like SVC, handle it within codec. Others, such as 1-D Interleaved Parity [RFC6015] need a payload type of their own. Others yet require that NACKs be sent over signalling and of course there are those whose relation can be specified in Plan B style SDP [RFC5956]. No Plan is not explicitly incompatible with any of them. I don't see a reason why someone shouldn't be able to specify a simulcast relation between SSRCs in SDP. This is is totally fine. What No Plan argues against is that this could be considered as enough of a reason to mandate that SSRCs should always be present in SDP. This argument has already been made and I think many here wouldn't agree with it because of the diversity in repair mechanisms that I mentioned above. In that sense the RTP header extension in the draft is just one example where such information could be delivered without any signalling. I personally believe such a mechanism could be quite useful in a number of cases. It can also be designed in such a way that browsers would use it transparently from applications, without bothering them with the exchange of O/A blobs. Still this is only a possibility and not really a No Plan requirement. Now, there is indeed something that we need to specify here and that is: how exactly does an application know whether it would need to worry about repair semantics and if so, would they work transparently or require the exchange of O/A blobs. Not only can this change from one browser to the next but it can even vary across peer connections. Handling this could require some adaptations in the WebRTC API. I might be wrong but I don't think any of the WebRTC supporting browsers currently send repair flows which is why all this is still hypothetical and now is probably the right time to think about it. Cheers, Emil On 04.06.13, 01:50, Bernard Aboba wrote: > > Jonathan said: > > "I think No Plan and Plan B are largely isomorphic in a WebRTC context. > The primary difference is that rather than using a=ssrc and > a=receive-ssrc (and whatever other Plan B attributes would be needed) to > control sources within an m-line, instead direct Javascript APIs are > used for the same semantics. It's up to the application to communicate > the relevant information end-to-end, in parallel to however it > communicates the SDP blob." > > [BA] The use of O/A to turn sources on/off is definitely one thing that > "No Plan" avoids, and that's something in its favor. However, I don't > think that's the only difference. > > As I see it, No Plan, when added to Plan B, results in simplifications > along several dimensions. I don't think that No Plan prohibits use of > a=ssrc lines either in the API or over the wire, but it does makes it > clear that they cannot be required for de-multiplexing (which No Plan > handles via PTs) or rendering of incoming streams (which can be handled > via APIs without MSID declarations). Basically, No Plan says "Don't try > to Bundle more things than you can de-multiplex using PTs". It's a bit > like telling a snake "don't eat an elephant whole, chop it up into bit > sized pieces". Yes, you could try it the other way,, but is the added > complexity (and indigestion) really worth it? > > Personally I wouldn't say it is a "No Plan" no-no if createOffer were to > produce SDP with a=ssrc lines, or if setRemoteDescription were to > process a=ssrc lines included by the remote peer. What I think No Plan > would have a problem with is if undeclared sources couldn't be rendered, > or if O/A were required to turn already declared sources on/off, which > can happen so rapidly that O/A couldn't possibly handle it. Also, > requiring O/A for dropping streams breaks congestion control because in > a highly congested situation, the signaling packets would probably get > dropped along with the media, so that the signaling to drop streams > couldn't get through. A sender MUST be able to drop streams in that > circumstance. > > In answer to questions about "whether you can declare separate streams > for screen sharing versus other video" I would think that No Plan could > allow a=ssrc lines for that, but if you just wanted to send them and > have the application figure out which was which (e.g. via app-specific > signaling) you could do that too. > > One area where I think all the Plans are weak is handling > simulcast/layered streams. I don't think max*sssrc makes sense because > it groups together sources, and streams (including simulcast, layered > streams and FEC). A receiver really needs to be able to declare the > maximum number of sources it can receive and the maximum number of > streams it can send, as well as declaring the simulcast and layering > schemes it can handle. This is NOT the same as actually stating what it > will be sending or receiving at any given moment. In general, it will > be up to the sender to make the decision based on the feedback it is > getting. > > Another comment on "No Plan" relates to the need for an RTP extension to > declare things like simulcast and layered stream dependencies. These > dependencies can be expressed in SDP as alluded to in Plan B, and they > also can be described within some codecs (e.g. H.264/SVC allows this). > IMHO, SDP O/A does have a role here, in describing the receiver > capabilities (what simulcast/layered streams it can support) as well as > the sender capabilities (what the sender is capable of sending). Since > neither an RTP extension nor individual payloads can provide > reliability, having this done in O/A via reliable signaling has an > advantage. But as long as the streams sent by the codec is > self-describing, I don't think an RTP extension is needed. > > However, the case of FEC is a bit trickier for No Plan. If you don't > declare the FEC SSRCs and dependencies in SDP, then you do need to > encode this in RTP, and the codec-specific route may not be sufficient > (opinions?). Also, doing this purely in RTP could create some problems > if the descriptions were lost because the receiver could end up trying > to render a FEC stream, with bizarre results. So this is one area where > it seems to me that "No Plan" may need some additional thought. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- https://jitsi.org
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Richard Barnes
- Re: [rtcweb] No Plan Cullen Jennings
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Martin Thomson
- [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Mary Barnes
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan - PT based MUX Cullen Jennings
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- Re: [rtcweb] No Plan Mark Rejhon
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- [rtcweb] RTT (was Re: No Plan) Matthew Kaufman
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Matthew Kaufman
- Re: [rtcweb] RTT (was Re: No Plan) Paul Kyzivat
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was Re: No Plan) Gunnar Hellstrom
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Barry Dingle
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- [rtcweb] Translating Plan A into No Plan (Was: No… Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Eric Rescorla
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] Translating Plan A into No Plan (Was… Martin Thomson
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] RTT (was :No Plan ) Paul Kyzivat
- Re: [rtcweb] No Plan - but what's the proposal Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Jonathan Lennox
- Re: [rtcweb] No Plan Jim Barnett
- Re: [rtcweb] Translating Plan A into No Plan (Was… Roni Even
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- [rtcweb] Repair Flows and No Plan (Was: No Plan) Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was :No Plan ) BeckW
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] Repair Flows and No Plan (Was: No Pl… Sergio Garcia Murillo
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Silvia Pfeiffer
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- [rtcweb] Plan xyz discussions; MMUSIC <> RTCweb R… Flemming Andreasen
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Peter Thatcher