Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

[Harald Alvestrand <[e-mail]>]

On 11/12/2013 03:20 PM, Magnus Westerlund wrote:
> Hi,
>
> Here are my review comments on draft-ietf-rtcweb-transports-01:
>
> 1. Front page: I would strongly suggest moving requirements language
> into some numbered section.
>
> 2. Section 2.1:
>
>    o  TCP.  This is used for HTTP/WebSockets, as well as for TURN/SSL
>       and ICE-TCP.
>
> Are there really any need for ICE-TCP? Can't this simply be removed?

This question belongs in 2.2 - it's a MAY requirement there (but there
have been arguments in pntaw that it should be a SHOULD).
In both cases,
>
> 3. Section 2.1:
>    For both protocols, this specification assumes the ability to set the
>    DSCP code point of the sockets opened on a per-packet basis, in order
>    to achieve the prioritizations described in [I-D.ietf-rtcweb-qos].
>
> First, I don't think one can assume the ability to set DSCP code points.
> I think one should express that it is desirable to do it.
>
> Secondly, I think one has to be aware that setting DSCP on a per packet
> basis may be less commonly working than even just marking a flow
> consistently.

References? Is this an assumption, or based on actual
experiments/experiences?

>
> Thirdly, the I-D.ietf-rtcweb-qos is dead, and if anything it should be
> replaced by draft-dhesikan-tsvwg-rtcweb-qos-02.

I will take instructions from the chairs on this point; I think we need
to specify what -qos- used to say, and resurrecting that draft may be
easier/better than adopting a new one.

So far, I have not seen anything from the chairs (before now) that
announces that it's dead.

>
> 4. Section 2.1:
>    If DSCP code points can only be set on a per-socket basis, not per-
>    packet, one loses the ability to have the network discriminate
>    reliably between classes of traffic sent over the same transport, but
>    this does not prevent communication.
>
> As this means all packets in the flow gets same treatment, one can point
> out that using multiple RTP sessions and transport flows allow one to
> have multiple different priority levels.

That's an implication of what this says. The ability to differentiate
between different flows is common enough that it is assumed.

>
> 5. Section 2.1:
>    This specification does not assume that the implementation will have
>    access to ICMP or raw IP.
>
> I think it should point out the advantage of being capable of receiving
> ICMP in MTU discovery.

I think this is not realistic for the browser use case, where the stack
is implemented as an unprivilleged application. I think the requirements
need to be achievable in that situation, which is the point of this
explicit non-assumption.

That means that path MTU discovery for UDP will have to depend on
observing the packet loss patterns, if done at all. I think that's
realistic.

>
> In addition I think you can bring up the benefits from being capable of
> setting DF bit.

Is there a benefit, given the point above?
Is there a common userspace way to achieve this?

>
> 6. Section 2.2:
>    ICE TCP candidates [RFC6062] MAY be supported; this may allow
>    applications to achieve peer-to-peer communication across UDP-
>    blocking firewalls, but this also requires use of the SRTP/AVPF/TCP
>    profile of RTP.
>
> I would question if this at all should be discussed. First of all a
> TURN/TCP or TURN/TLS/TCP relay fulfills the needs to cross a only TCP
> allowing firewall.
The PNTAW discussion seems to indicate that there are scenarios where
this is realistic.
> Secondly, if one likes to use TCP/TLS/RTP/SAVPF then
> one would need to use RFC 4571 framing, or do you have another proposal?

I think the spec has to point to something that defines the framing,
otherwise this won't achieve interoperability. Is RFC 4571 the right
reference?

> I would also note that such a combination do require us to do a bit of
> specification work to bring RFC 4571 up to date to allow us use both
> profiles beyond AVP as well as indicating usage of DTLS-SRTP over that
> TCP framing. Considering that this appears to be a redundant and less
> likely to work mechanism I would propose to remove it from consideration
> even for MAY.

Redundant with what other mechanism?

>
> 7. Section 2.2.:
>
>    o  TURN, including TURN over TCP[RFC5766].
>
> Missing space between TCP and reference.
>
> 8. Section 2.2:
>
>    TURN over TLS over TCP MAY be supported.  (QUESTION: SHOULD?  MUST?)
>
> I think MAY is a fine level for this. But it clearly should be an issue
> raised to the WG for further debate.

This is being debated on PNTAW.

>
> 9. Section 2.3:
>    The setup protocol for RTCWEB data channels is described in
>    [I-D.jesup-rtcweb-data-protocol].
>
> That draft is now a WG draft.
>
> 10. Section 2.3:
>    RTCWEB implementations MUST support multiplexing of DTLS and RTP over
>    the same port pair, as described in the DTLS_SRTP specification
>    [RFC5764], section 5.1.2.  Further separation of the DTLS traffic
>    into SCTP and "other" is described in <need reference>.
>
> A. I would note that one actually must be capable of multiplexing DTLS,
> RTP and STUN messages on the same port pair.

That is described in RFC 5764 section 5.1.2. Since ICE is completely
useless if it can't be multiplexed over the same port pair as the stuff
it's probing for, I regard the ability to demultiplex STUN packets as
implicit in the statement "we're using ICE".

>
> B. What about that needed reference. I think it is
> draft-ietf-rtcweb-data-channel that should have this text.

I'll check if it does.
>
> 11. Section 4:
>
> I think this document do need to discuss DSCP and ICMP and the issues
> they can cause. Or possibly provide input to the security consideration
> document.

Please send text or pointers.

>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>


-- 
Surveillance is pervasive. Go Dark.