Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06

[Randell Jesup <[e-mail]>]

On 2/11/2014 5:47 AM, Michael Tuexen wrote:
> On Nov 11, 2013, at 2:54 PM, Magnus Westerlund <[e-mail]> wrote:
>
>
>> 3. Section 3.2:
>>    U-C 7:  Proxy browsing, where a browser uses data channels of a
>>       PeerConnection to send and receive HTTP/HTTPS requests and data,
>>       for example to avoid local internet filtering or monitoring.
>>
>> Yes, this may be something that is possible, but to express it as a use
>> cases intended to be supported might not be the best. We are after all
>> likely talking about circumventing local security policies. I would also
>> note that "Internet" is with capital I.
> Change to Internet. The use case seems important, since there are already
> implementations doing this (possibly not using data channels, don't know).
> Randell: What do you think?

There are people actively planning to use it for this usecase in 
high-profile applications (using datachannels), or so I am told.

>
>> 6. Section 4:
>> [ TBD: how this is encoded and what the impact of this is. ]
>>
>> Didn't we have some direction decisions on how priority was to be
>> handled at least locally by the end-point. Please add this to the draft.
> I think we decided to have priorities for data channels, which are not strict
> priorities. That is all. The W3C document doesn't mention it.

We haven't discussed it yet at the W3 level.

>> I also hope that the way of representing priorities can get clearer from
>> an API perspective.
> I agree. However, I'm not a member of W3C...

Anyone can take part in the W3 discussions on this.  Please feel free to 
propose something.

>> 12. Section 5:
>> "  Since DTLS is typically implemented in user-land, the SCTP stack also
>>    needs to be a user-land stack."
>>
>> I wonder what the message of this sentence is? The reason is that I
> That you can't use a kernel SCTP stack, even if available.
>> wonder what it should be saying if one implements DTLS in a kernel, or
> I haven't seen this yet. I think you can do the encrypt/decrypt part,
> but doing the key management stuff in kernel land doesn't seem appropriate.
>> similar if one despite a DTLS user-land stack uses a SCTP stack in the
>> kernel through access to raw sockets.
> How can the lower layer run in userland when the upper layer runs in
> kernel land?

It can in theory, but likely not in any of the OS's we're concerned with 
currently.

>> 15. Section 5:
>>    Using a congestion control
>>    different from the standard one might improve the impact on the
>>    parallel SRTP media streams.  Since SCTP does not support the
>>    negotiation of a congestion control algorithm, alternate congestion
>>    controls SHOULD only require a different sender side behavior using
>>    existing information carried in the association.
>>
>> A: I wonder if adding a "yet" into the second sentence to make clear
>> that in the future there might be support for negotiating congestion
>> control.
>>
>> B: Also, what happens if one violate the SHOULD and require receiver
>> side information and the peer don't support it. That clearly can't be
>> acceptable? Can this be formulated in some other way that is tighter
>> without preventing sender side changes?
> OK. Changed to
> Since SCTP does not support the negotiation of a congestion control algorithm
> yet, alternate congestion controls SHOULD either only require a different
> sender side behavior using existing information carried in the association or
> need also specify a negotiation of of a congestion control algorithm.</t>

Sounds good.

>> 18. Section 6.2:
>> "  Additionally,
>>    the negotiation SHOULD include some type of congestion control
>>    selection. "
>>
>> Okay, this appears very fuzzy. And what name space or specifications are
>> you going to use to negotiate what the different options are?
> Randell? Salvatore? I don't think there is anything specified yet.

There is not thus far



-- 
Randell Jesup
[e-mail]