Subject: Re: [rtcweb] Review of rtcweb-transports-01

From: Harald Alvestrand <[email-masked]>
Date: Wed, 22 Jan 2014 16:28:38 +0100

On 12/30/2013 01:28 PM, [email-masked] wrote:
> Hi,
>
> I did a review of draft-ietf-rtcweb-transports-01.
>
> This version has recently been reviewed at least by Dan Wing and Wesley Eddy, so I won't raise the same points they already have, unless I have some further input on them.
>
> ---
>
> Overall comments:
>
> The document is on the right track. The main high level issue is how this document relates to and what will happen with draft-dhesikan-tsvwg-rtcweb-qos and especially hutton-rtcweb-nat-firewall-considerations. I don't think there is yet clear consensus let alone decision on what the mandatory/recommended features for either QoS/DSCP handling or NAT/FW traversal are in the "first release" of WebRTC protocols, and what features are left as optional or for future consideration. Those decisions need to happen before rtcweb-transports can properly move forward.
>
> I agree with Dan Wing's review that there should be some more guidance on the trade-offs involving multiplexing everything into a single port (improved call setup success rate and speed?) and keeping the flows separate (DSCP/QoS handling in some networks).

I will include a section on this. I'm not 100% sure it belongs here (it 
may also belong with the place where we reference BUNDLE, which is not 
here), but here's also a relevant place to discuss it.
>
> Section 2.1:
>
> This section lists assumptions about what needs to be supported in order to actually implement the DSCP handling recommendations provided by rtcweb-qos. It does not however say whether rtcweb-qos itself is a MUST, SHOULD or MAY to implement. That should be made clear first in the RTCWEB WG and subsequently in this document.
On the principle that it is better to make a proposal than to leave this 
blank, I added a section making it a SHOULD, and saying that running on 
a system not implementing QoS marking is a valid reason to not do it. 
Let's discuss this further.
>
> Section 2.2:
>
> The relationship between this section and Section 6 of draft-hutton-rtcweb-nat-firewall-considerations needs to become clear. The requirements in draft-hutton are stricter than in this document, and RTCWEB WG needs to decide where the bar is actually set in the first release. This has been discussed on the separate list but I don't think there is yet consensus on the issue. What is currently in rtcweb-transports is a fine minimum set, but not enough to deal with e.g. common enterprise network setups.

At the moment, I think -transport- deals with stuff that is well defined 
in terms of STUN and TURN, while -firewall- deals with stuff that may be 
in use (like .wpad files and uses of the connect method), but not quite 
so well defined. I'm happy with that split.

>
> Section 2.3
>
> I would move the reference to "RTP usage" in front of  refs to data channel drafts just because that's usually the order in which RTCWEB medias are introduced.

Done.

>
> I agree with Dan Wing that it would be useful to show the demultiplexing diagram of DTLS vs. SRTP/RTCP vs. STUN and SCTP vs. Other within DTLS inline in this document. I think it would also be useful to have the protocol stack shown with TCP and UDP as alternatives on the "classic" transport layer, and then DTLS and SRTP on the next and so on. [I don't think that diagram exists  in any or the RTCWEB documents, or does it? In that case I can volunteer take a stab at that unless Harald wants to...]

I'll be happy to take an ASCII art contribution here :-)

>
> Regards,
> 	Markus
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb