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

[Harald Alvestrand]

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.

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.

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

>
>
>