[RTW] Comments on draft-alvestrand-dispatch-rtcweb-datagram

[Justin Uberti]

On Sat, Jan 1, 2011 at 10:04 PM, Harald Alvestrand <harald at alvestrand.no>wrote:

> On 12/30/10 16:52, Markus.Isomaki at nokia.com wrote:
>
>> Hi,
>>
>> A couple of questions and comments on
>> draft-alvestrand-dispatch-rtcweb-datagram-00:
>>
>> * Section 4 defines four channel types: UDP, TCP, TLS and DTLS. Is it
>> expected that all clients MUST support all of these? I suppose the reason
>> why both UDP and TCP are included is that depending on the types of
>> middleboxes the peers are behind, they may get just one or the other
>> working. I.e. first try out UDP, if it does not work, attempt TCP. Is that
>> correct?
>>
> I started out by defining the types I thought might be needed - so this is
> not the "must implement" list. The "Must implement" list is still a matter
> for discussion - not having UDP in there is certainly a non-starter, so UDP
> has to be "must implement". For others, I'd like to see arguments.
>
>  * Section 4.5 states that TURN and relaying are needed. How about things
>> like HTTP/TLS tunneling? In many cases that is the only way to get the
>> transport channel working. TURN may be helpful in some, hopefully
>> increasing, amount of cases, but that alone will still leave a lot of
>> corporate users unserved.
>>
> At Google, we've implemented a form of HTTP/TLS tunnelling using a TURN
> variant (see libjingle source for details), so I didn't differentiate
> between those options - I see HTTP/TLS as a form of relaying; I don't
> believe simultaneous-open TCP is going to work reliably enough for our
> purposes.
>
>  * Section 3 mentions that things like pseudoTCP can be run over the
>> datagram transport. In case only UDP works end-to-end that seems useful.
>> However, if we can get a "native" TCP connection up, it seems natural to use
>> that as is rather than via some kind of generic datagram abstraction layer.
>> I think we probably should define both datagram and bytestream services
>> separately. Bytestream would be either TCP or pseudoTCP/UDP. If we only do
>> datagram service, leave the whole pseudoTCP reference out.
>>
> I agree with your way of putting it. The reference is intended as
> informative; bytestream COULD be layered over the datagram service, but
> doesn't need to be.
>

The issue with a "native" TCP connection is that we need to perform ICE-y
checks on it to enforce the same-origin policy. When using PseudoTCP, the
ICE checks are done automatically as part of the datagram protocol. However,
as Harald points out, if we are using the "native" TCP for a connection to a
relay or conference server, we can simply run our datagram protocol over top
of the native TCP connection.

Basically what I am saying is that while we may use "native" TCP connections
internally for handling scenarios where UDP is blocked, I'm not sure we can
expose them from the API.

>
> Background: I had a discussion with a coworker who wanted to have a single
> API to both streaming and datagram service; I believe it makes more sense to
> define an API to a datagram service and an API to a streaming service
> separately - the big argument for PseudoTCP is the client-to-client
> connection case, where one often finds that UDP works and TCP doesn't.
>

I had been thinking the datagram and streaming services should use a single
API - much of the API ends up being the same, and that's how BSD sockets
work. There are a few differences for streaming services, but they are
mostly (entirely?) additive (flow control being the main one).

>
> The argument for defining TCP over datagram, rather than TCP over UDP, is
> that we might easily find ourselves needing functions like ICE establishment
> or TURN relaying for client-to-client TCP sessions; doing it this way saves
> us one duplicate reference set. (The concept of pseudoTCP running over
> datagrams tunneled over HTTP/TLS somewhat boggles the mind, though....)
>
>  * Section 6 defines a URI with a number of IP address:transport:port
>> candidates. I'm not too clear on how that URI would be used. It looks to me
>> as something that is received as a result of gathering the candidates (with
>> STUN, TURN etc.) as the first step of ICE. If Jingle or SDP offer/answer or
>> some proprietary protocol were used to pass the candidate information to the
>> other peer, that information would be encoded according to that particular
>> protocol. So is this specific URI just meant for local representation at the
>> API and not something that is passed over the network as such? What's the
>> need or benefit of making it a URI?
>>
> This is an example of speculative standardization, or "trial balloon" - W3C
> folks have had a habit of using URIs for any form of structured parameter in
> APIs; if that is what the W3C effort concludes that they want, this is
> intended to show that it can be given to them.
> That said - the fact that this is intended to represent, exactly, the
> semantics of a=candidate lines from SDP needs to be made clear (as I said in
> another thread). Let's not have more different semantics than we need to.
>
>> Thanks,
>>        Markus
>>
> Thanks for the review1
>
>
>
>>
>>
>>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110105/2942c5b5/attachment.html>