[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 with SMTP id rg6mr8098737bkb.101.1370354536691; Tue, 04 Jun 2013 07:02:16 -0700 (PDT)
Received: from camionet.local ([]) by mx.google.com with ESMTPSA id da16sm23059034bkb.2.2013. 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.


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