[RTW] dearly love packet inspection

[Ted Hardie]

On Thu, Jan 6, 2011 at 11:18 AM, Henry Sinnreich
<henry.sinnreich at gmail.com> wrote:
>> Okay "direct flows of non-RTP application data" goes beyond scope creep;
>> to satisfy this completely, we are talking an end-point-to-end-point tunnel,
>> which will run afoul of a lot of folks who dearly love packet inspection.
>
> Why should the IETF and W3C abide by the folks who love deep packet
> inspection? I would like to see some IESG guidance here, since it is
> contrary to Internet and to the Web. Break of privacy, etc.
>
> To accelerate clarity here, what does Harald and people on the list think?
>
> Thanks, Henry

Hi Henry,

I'm not a huge fan of packet inspection.  But "any application data" is clearly
well beyond the audio/video use case that motivated this work in the first
place.  I expect that it would make firewall traversal significantly
harder unless
it lost privacy; that trade-off would make the voice/video privacy *worse*.

It also will make the communication among browsers in a multi-party
mode move from known issues (media mixing and floor control) to something
closer to that of an overlay network.  That's not impossible (setting
up an overlay
when you have a rendezvous server, basically moves it from mediating
the signaling
path to being an enrollment server), but is also not simple.  Is it
really needed
for job one here?

regards,

Ted



>
>
> On 1/6/11 12:43 PM, "Ted Hardie" <ted.ietf at gmail.com> wrote:
>
>> Hi Harald,
>>
>> Thanks for putting this together; some discussion in-line.
>>
>> On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand <harald at alvestrand.no>
>> wrote:
>>> This is the first of 3 messages going to the DISPATCH list (in the hope of
>>> keeping discussions somewhat organized).
>>>
>>> This is the draft of a charter for an IETF working group to consider the
>>> subject area of "Real time communication in the Web browser platform". This
>>> is one of a paired set of activities, the other one being a W3C activity
>>> (either within an existing WG or in a new WG) that defines APIs to this
>>> functionality.
>>>
>>> The two other messages will contain the W3C proposed charter and a kickoff
>>> for what's usually the most distracting topic in any such discussion: The
>>> name of the group.
>>> Without further ado:
>>>
>>> -------------------------------------
>>>
>>> Version: 2
>>>
>>> Possible Names:
>>> <This space deliberately left blank for later discussion>
>>>
>>> Body:
>>>
>>> Many implementations have been made that use a Web browser to support
>>> interactive communications directly between users including voice, video,
>>> collaboration and gaming, but until now, such applications have required the
>>> installation of nonstandard plugins and browser extensions. There is a
>>> desire to standardize such functionality, so that this type of application
>>> can be run in any compatible browser.
>>>
>>
>> In at least some of the contexts identified above, there is a
>> long-lived identifier
>> associated with the individuals who will have interactive
>> communications; that is,
>> there is a context-specific presence architecture in addition to the
>> implementation-specific
>> real-time communications.  Though the text below occasionally says "users",
>> there does not seem to be any work being defined that would touch on this.
>> I see that in the last sentence you explicitly rule it out of scope.
>> Without this,
>> this seems to be limited to an architecture where a mediating server provides
>> the initial signaling path.  If that is the scope, I think that should be made
>> explicit as a design statement, not inferred from the lack of presence.
>>
>>> Traditionally, the W3C has defined API and markup languages such as HTML
>>> that work in conjunction with with the IETF over the wire protocols such as
>>> HTTP to allow web browsers to display media that does not have real time
>>> interactive constraints with another human.
>>>
>>> The W3C and IETF plan to collaborate together in their traditional way to
>>> meet the evolving needs of browsers. Specifically the IETF will provide a
>>> set of on the wire protocols, including RTP, to meet the needs on
>>> interactive communications, and the W3C will define the API and markup to
>>> allow web application developers to control the on the wire protocols. This
>>> will allow application developers  to write applications that run in a
>>> browser and facilitate interactive communications between users for voice
>>> and video communications, collaboration, and gaming.
>>>
>>> This working group will select and define a minimal set of protocols that
>>> will enable browsers to:
>>>
>>> * have interactive real time voice and video between users using RTP
>>> * interoperate with compatible voice and video systems that are not web
>>> based
>>
>>> * support direct flows of non RTP application data between browsers for
>>> collaboration and gaming applications
>>>
>>
>> Okay "direct flows of non-RTP application data" goes beyond scope creep;
>> to satisfy this completely, we are talking an end-point-to-end-point tunnel,
>> which will run afoul of a lot of folks who dearly love packet inspection.  I
>> would say that it would be best to first tackle the voice/video bits and then
>> tackle this problem.  Re-charter the WG to cover this, in other words, after
>> the first bit is done.
>>
>> I also note that you're using "between browsers", rather than "among
>> browsers".
>> Is it intended that this facility should allow for multi-party communication?
>> Leaving aside the non-RTP issues, that would add floor control, media mixing,
>> etc. to the task list.  Again, I think it should either be explicitly
>> in-scope or out-of-scope.
>>
>>> Fortunately very little development of new protocol at IETF is required for
>>> this, only selection of existing protocols and selection of minimum
>>> capabilities to ensure interoperability. The following protocols are
>>> candidates for including in the profile set:
>>>
>>> 1) RTP/ RTCP
>>>
>>> 2) a baseline audio codec for high quality interactive audio. Opus
>>> will be considered as one of the candidates
>>>
>>> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
>>> will be considered
>>>
>>> 4) a baseline video codec. H.264 and VP8 will be considered
>>>
>>> 5) Diffserv based QoS
>>>
>>> 6) NAT traversal using ICE
>>>
>>
>> The ICE spec is clear that the NAT traversal it provides does not
>> help establish the signaling between agents.  For this browser-to-browser
>> mechanism, if we are limiting this to situations where a mediating web server
>> provides the initial signaling path, that's okay.  If there is a
>> different model, though,
>> we may need additional tools here.
>>
>>> 7) RFC 4833 based DTMF transport
>>>
>>> 8) RFC 4574 based Label support for identifying streams purpose
>>>
>>> 9) Secure RTP and keying
>>>
>>> 10) support for IPv4, IPv6 and dual stack browsers
>>>
>>> The working group will cooperate closely with the W3C activity that
>>> specifies a semantic level API that allows the control and manipulation of
>>> all the functionality above. In addition, the API needs to communicate state
>>> information and events about what is happening in the browser that to
>>> applications running in the browser.
>>
>> I think the sentence above has some extra words; is the browser talking
>> to application running in the browser?  Can it be re-phrased?
>>
>> These events and state need to include
>>> information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state
>>> of DTLS/SRTP,  and signalling state.
>>>
>>> The following topics will be out of scope for the initial phase of the WG
>>> but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocation,
>>> IM & Presence, NSIS, Resource Priority,
>>>
>>> Milestones:
>>>
>>> February 2011 Candidate "sample" documents circulated to DISPATCH
>>>
>>> March 2011 BOF at IETF Prague
>>>
>>> April 2011 WG charter approved by IESG. Chosen document sets adopted as WG
>>> documents
>>>
>>> May 2011 Functionality to include and main alternative protocols identified
>>>
>>> July 2011 IETF meeting
>>>
>>> Aug 2011 Draft with text reflecting agreement of what the protocol set
>>> should be
>>>
>>> Nov 2010 Documentation specifying mapping of protocol functionality to
>>> W3C-specified API produced
>>>
>>> Dec 2011 Protocol set specification to IESG
>>>
>>> April 2012 API mapping document to IESG
>>>
>>
>> Pretty aggressive, given the number of moving parts.  It's also not
>> clear why the November 2011 doc (I assume 2010 is a typo) is
>> done in the IETF, rather than the W3C.  Or is it joint work?
>>
>> regards,
>>
>> Ted Hardie
>>
>>
>>> _______________________________________________
>>> RTC-Web mailing list
>>> RTC-Web at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch at ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>