[rtcweb] Notes from the IETF88 Monday RTCWEB session

Ralph Giles <giles@thaumas.net> Tue, 05 November 2013 02:58 UTC

Return-Path: <giles@thaumas.net>
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 42F8B21E83A0 for <rtcweb@ietfa.amsl.com>; Mon, 4 Nov 2013 18:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GYqaseW9Jbed for <rtcweb@ietfa.amsl.com>; Mon, 4 Nov 2013 18:58:26 -0800 (PST)
Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 94E2F21E83AE for <rtcweb@ietf.org>; Mon, 4 Nov 2013 18:58:21 -0800 (PST)
Received: by mail-bk0-f51.google.com with SMTP id my12so1351183bkb.24 for <rtcweb@ietf.org>; Mon, 04 Nov 2013 18:58:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=/Q75zdyMqiwIPDxmRkiIY/hRLro5/BljUIkjMzoosr4=; b=Bo4praEsJwwzwbnodtJuleT26lftS6/lXjEyY6Sf19gWvuIq1KQvcvleqQo0PlB1Gv HRTENkP7JJxkW5MHVNM0i7iNAF2cPkSY5huJ/Ve2kFR8SYjUkHk/S9y9UvvCrC6QHdLm S1quugeSnjukMpU4bibH+SLSh9bq4oIEAMzYsyHV+qh/hWuoPWPgH434jBgGLTsDTbLf jhx1bPmS7465AZOALkxefi72sBpEdOS0pIc+q0oQBfm4bvGKICUxa9/29z8wIBkde5sO J0wZ6H0hFkEM2RM1Fb6Z2WlqKQrC/BKUd4dGiZ4WR9kE2wAvR4Y9nkpun1GLKLP049FU RGpA==
X-Gm-Message-State: ALoCoQmmDx8m0Nuc6+qGm15zjLFjydxtrRRnEkRrkDhJcxv8xybo/w0xdOMWvq4nFsvK3Nw7L3LQ
X-Received: by with SMTP id a10mr559403bkj.36.1383620300754; Mon, 04 Nov 2013 18:58:20 -0800 (PST)
Received: from tamias.local (static-68-179-67-77.ptr.terago.net. []) by mx.google.com with ESMTPSA id pk7sm17391173bkb.2.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 18:58:19 -0800 (PST)
Message-ID: <52785EC7.1040904@thaumas.net>
Date: Mon, 04 Nov 2013 18:58:15 -0800
From: Ralph Giles <giles@thaumas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Cullen Jennings <fluffy@iii.ca>, Ted Dardie <ted.ietf@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: [rtcweb] Notes from the IETF88 Monday RTCWEB session
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, 05 Nov 2013 02:58:31 -0000

Here are the notes I took during today's RTCWEB session.
Conclusions/decisions are marked with a leading dash.

Original at https://etherpad.mozilla.org/ietf88-rtcweb

=== IETF 88 - Vancouver BC ===
RTCWEB WG meeting notes
2013 November 4 14h50-17h20

IETF Note Well
    JSEP (15m)
    Data channel

== Discussion notes ==

Chair update: Magnus Westerlund

Milestone review: documents, dependencies.
We'd like complete milestones as quickly as possible; out overall goal
is to finish in 2014. This will be a challenge. Help by reviewing
documents and sending comments.

Authors, consider if our normative references make sense. Are they
really needed? Waiting on references slows down publication.

Ted Hardie: hum calibration. "Some counterfactual humming."

= JSEP update: Justin Uberti
Look at examples at least if you can do a minimal review of the draft.
Manditory-to-implement SDP features and things manditory to use now

Q1: Re-offer handling
Proposal: Use a new peerconnection for full renegotiation, heavy-weight
MUST NOT re-offer e.g. codecs rejected by the other side. Don't make
things harder for application developers by leaving this to implementators.

- Conclusion: Complex matrix of options, difficult to judge the room.
More discussion is needed. Think of more specifc proposals.

Notetaker's summary of discussion:
Some concern that there's no way to upgrade options.
SDP could come from a non-webrtc endpoint, so we can't rely on the other
side respecting this.
MUST so applications behave uniformly.
Available resources, like hardware codecs can change.
Bundle less controversial, since it's constant for the implementation.
Has specific language about initial and subsequent offers already.
There's no way to tell the difference between unsupported and
unsupported-right-now with this proposal.

Q2: a=connection. Should we add it?
Is it useful to use connection=new to force DTLS renegotiation.

- Conclusion: No, per existing specs. (no concensus call)

Discussion summary:
Makes sense of TCP, not the best interface for DTLS.
Unless we can come up with a reason to swap roles mid-stream, don't mess
with this. Just set it up and keep it up.
MITM attacks are a use case!

Is there a way to synchronize multiple MediaStreams from the W3C API so
they can share a CNAME.

- No proposal, just discussion.

Discussion summary:
Can we just map MediaStreams to CNAMEs?
It should be the senders choice to use the same CNAME or different for
two MediaStreams. There's no compelling reason to expose that to the
application running on the browser on the other side.
Shared CNAMEs don't _have_ to be synchronized at playback. Could use the
absense of an attribute to indicate unsynced.
Application could add a track to two different MediaStreams to indicate
This is a W3C problem, not an IETF problem.

Q4: BUNDLE control
Try to bundle everything, add a BundleOnlyPolicy contraint to

all, none, or per-media type all audio bundled, all video bundled.
Use per-media the default. Don't try to control things per-track.

- Conclusion: General aggreement from commentors.

Disagreement. Wrong forum? (withdrawn later)
Bundle is strictly better, so this is good, and gives us the minimum set
of controls. We can always add more later.
Could be same-priority instead of same-media?
This is reasonable if it just controls what legacy applications see.

Q5: m= section recycling

- Conclusion: Discussion directed to the list for reasons of time.

= Chairs note: Security discussion moved to the end, with the
understanding we may not have time for it.]

= Data Channels: Randell Jesup

Remaining issues:

DTLS Overhead: resolve by specifying IP Layer MTU?

- Conclusion: (roughly) ask TSV working group to advance the ndata draft
 and try to get that solution implemented and spec'd in time for RFC.

What' is it specified to? PMTU up from some lower bound is easier to
max of all ciphersuite overheads, which changes with time, so we can't
specify in advance.
Doesn't max give you a number which could be too large?
SCTP needs to know, but since it can change we shouldn't specify anything.
Large message block other channels: tsv draft proposes to alleviate this
In the meantime, support PPID-based fragmentation + length limit for
unreliable, as discussed in drafts, implemented in Firefox
How do we retire the PPID issue once SCTP interleaving works?
SCTP implementaitons know what the other side supports, so it's
negotiated, but you still have to implement forever?
Could remove the fallback even before we finalize the draft, since
implementations are ahead of the spec.
Also easy to update a spec by just removing a section.
Why not just do that now, and not doc the fallback or doc it as
Old, new, or both forever; which do we want?
The ndata implementation is in an svn branch, needs testing before
merge, so very close. Draft is still and individual submission. Expect
it could be advanced if this WG asks TSV for it.

Message size limitations:
Propose a minimum supported maximum size of 100 MB
Websocket has no spec limit, implementations pick one in practice. Maybe
we should do that too?

- Conclusion: write up the ack signaling as a new proposal.

What happens if you go over an implementation limit?
In WebSockets, there's no way to stream things. This isn't any different
Is there a way to query the limit? Get an error when it's exceeded? Not
having that is bad.
Imitating the mistakes of others is the best we could do. Let's make our
own mistakes.
We can't figure out what people want to use this for. It would be nice
if there were a well known set of properties applications could assume
so they would know e.g. when they need to do chunking. We've had enough
discussion to decide whether we should have a deterministic limit.
Could pass a limit in the handshake ack to the js api could handle it.

Nagle: no longer an issue. (?)

Initial number of streams:
Propose not to set the maximum number of streams to 64k streams. There's
no complexity advantage.

- Conclusion: Set it to maximum and be done with it.

I approve of setting  this to the maximum,
vs. I still have an issue with this.

SDP shouldn't have to worry about these details. Like IP applications
applications shouldn't have to preallocate ports.
SCTP implementations all pre-allocate this state, so you need 128K per
connection, and never use them.
Rewriting them for lazy allocation or sparse array is "just" work. While
protocol renegotiation will last forever.
Servers are memory-limited devices, just like low-end mobile devices.
Avoid encoding numbers on wire to save implementation complexity. Better
to make implementations smarter.

Out of Band Negotiation:
Handling collisions between in-band and out-of-band negotiations.

Browser can detect and warn on these sorts of things. In the text just
say it's wrong, and error.

- IANA registration protocol question. Discuss on the list.

= RTP issues: Colin Perkins


- Signalling the most number of ssrc values -- Not an issue
This is the same as the number of m-lines. So we don't need to say anything.
Confusion between max sources, max streams.
Limits are based on resolution etc., not just the number of streams.

Signalling RTP topologies --
- Should multiple cnames per session be mandated? Yes
- Do we need to say anything about SDP signalling for gatewaying? No
- Simulcast -- Maybe, but not in this forum. See AVTEXT.
- Forwarding -- If you wish to forward media, treat the RTP as if you'd

Forwarding without transcoding sounds really complicated and we
shouldn't worry about it.
With transcoding already works in Chrome, it's just plumbing. We can do
an RTP translator later if we decide it's important.
Nutty to do a middlebox in the browser.
Transcoding does add delay.
We're talking about two different ways of implementing something that's
already possible in the W3C api. The browser has a choice on how to do
this, there are easy cases where it could switch behaviours as an
implementation quality issue.

- Differentiated services -- Make a draft outlining the issues; make no
concrete recommendations.
Work going on in other working groups on these issues.

- Correlating Media Streams -- No, this isn't in jsep. It doesn't makes
sense to put unified-plan in the RTP usage draft.

Security: Eric Rescorla
Hope to update the draft in Decemeber.
On the screensharing issue, both Firefox and Chrome were planning to
punt in the same way.

End of session.