Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06
Randell Jesup <randell-ietf@jesup.org> Wed, 12 February 2014 02:05 UTC
Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F921A07C3 for <rtcweb@ietfa.amsl.com>; Tue, 11 Feb 2014 18:05:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.13
X-Spam-Level:
X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy5Pc_GA2lr8 for <rtcweb@ietfa.amsl.com>; Tue, 11 Feb 2014 18:05:35 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4A31A07BD for <rtcweb@ietf.org>; Tue, 11 Feb 2014 18:05:35 -0800 (PST)
Received: from corp-240.mv.mozilla.com ([63.245.220.240]:57728 helo=[10.250.6.245]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <randell-ietf@jesup.org>) id 1WDPCg-0007Dw-4W for rtcweb@ietf.org; Tue, 11 Feb 2014 20:05:34 -0600
Message-ID: <52FAD6EE.3070807@jesup.org>
Date: Tue, 11 Feb 2014 18:05:34 -0800
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5280E181.20104@ericsson.com> <9A62A3AC-F990-4358-B2E7-B8DD39A81B03@fh-muenster.de>
In-Reply-To: <9A62A3AC-F990-4358-B2E7-B8DD39A81B03@fh-muenster.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2014 02:05:37 -0000
On 2/11/2014 5:47 AM, Michael Tuexen wrote: > On Nov 11, 2013, at 2:54 PM, Magnus Westerlund <magnus.westerlund@ericsson.com> 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 randell-ietf@jesup.org
- [rtcweb] Comments on draft-ietf-rtcweb-data-chann… Magnus Westerlund
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Harald Alvestrand
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Randell Jesup
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Magnus Westerlund