[rtcweb] Notes from the IETF88 Monday RTCWEB session

[Ralph Giles <[e-mail]>]

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
Agenda
    Chairs
    JSEP (15m)
    Data channel
    Security
    RTP

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

Q1: Re-offer handling
Proposal: Use a new peerconnection for full renegotiation, heavy-weight
changes.
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!

Q3: CNAMEs
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
sync.
This is a W3C problem, not an IETF problem.

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

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

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

Discussion:
What' is it specified to? PMTU up from some lower bound is easier to
implement.
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
non-normative.
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.

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

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

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

Discussion:
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

Discussion:

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

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.