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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Nov 2013 15:20:13 +0100

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?

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.

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

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.

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.

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

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. 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 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.

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.

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.

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

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.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:33:29 +0000

Hi Magnus,

ICE-TCP shall be used by WebRTC gateways and conference scenario. The related usecases are discussed in http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html (PNTAW mailing alias). So, it should not be simply be removed.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Magnus Westerlund
Sent: Tuesday, November 12, 2013 7:50 PM
To: Harald Tveit Alvestrand; [email-masked]
Subject: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

Hi,

2. Section 2.1:

3. Section 2.1:

4. Section 2.1:

5. Section 2.1:

6. Section 2.2:

7. Section 2.2.:

8. Section 2.2:

9. Section 2.3:

10. Section 2.3:

11. Section 4:

Cheers

Magnus Westerlund

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 12 Nov 2013 20:10:51 +0100

> 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,
> basis may be less commonly working than even just marking a flow

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

> 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.

> 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.

> I think it should point out the advantage of being capable of receiving

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

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

> 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

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?

> likely to work mechanism I would propose to remove it from consideration

Redundant with what other mechanism?

> raised to the WG for further debate.

This is being debated on PNTAW.

> 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".

> draft-ietf-rtcweb-data-channel that should have this text.

I'll check if it does.
> they can cause. Or possibly provide input to the security consideration

Please send text or pointers.

-- 
Surveillance is pervasive. Go Dark.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Nov 2013 08:24:14 +0100

Hi Partha

On 2013-11-12 19:33, Ravindran, Parthasarathi (NSN - IN/Bangalore) wrote:
> Hi Magnus,
> 
> ICE-TCP shall be used by WebRTC gateways and conference scenario. The
> related usecases are discussed in
> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html
> (PNTAW mailing alias). So, it should not be simply be removed.
> '

Sorry, I don't understand what your use case is for ICE-TCP. When do you
need to establish an end-to-end TCP connection between two WebRTC
endpoints. I fail to see the motivation for this given that you are
going to establish a PeerConnection across it, with the purpose of
running STUN, RTP, DTLS-SRTP and DTLS/SCTP messages across it.

So please elaborate on why ICE-TCP with an framing for datagrams is not
just redundant from a functionality perspective with TURN/TCP or
TURN/TLS/TCP?

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Nov 2013 09:25:42 +0100

Hi,

Many follow up comments inline.

> have been arguments in pntaw that it should be a SHOULD).

Okay, I have responded to Partha's question because I don't understand
his motivation yet.

> References? Is this an assumption, or based on actual

Hmm, I might have overstated my case here. I can't actually find a
reference to this. My observation digging through some APIs, like
Windows QoS2, and also the regular socket API is that they appear much
easier to use if you just set a DSCP rather than like to juggle it on
per packet basis. But, I can't support they are impossible to use.

> announces that it's dead.

Okay, we might not have been public enough on this. It was requested by
the Transport ADs quite some time ago that doing the QoS document in our
WG was not appropriate and requested us to direct the document to TSVWG.
Which was done, and where it hasn't made progress.

You might have noted that James Polk did comment in the milestone part
in the monday session of IETF88 about our QoS milestone should be killed.

> between different flows is common enough that it is assumed.

Sorry, for being picky, but what flow definition are you using in the
above sentence. The one related to the applications flows, like an RTP
packet stream with the same SSRC, or a SCTP Stream, or do you mean all
packets with the same six-tuple, i.e. src addr, src port, dest addr,
dest port, Transport protocol, DSCP?

Even so, are there need to discuss also here the possibility that these
transport level limitations have impact on the default behavior of the
WebRTC implementation on what it suggest given that an application have
requested different priorities.

> need to be achievable in that situation, which is the point of this

And my point is that not all WebRTC end-points will have this
limitation. I am all positive in describing the issues when you can't do
it, similar I do like to point out that when one can do it, one should
because it do give an significant advantage.

> observing the packet loss patterns, if done at all. I think that's

I agree that given no possibility to setting DF and receving ICMP one
will be limited. However, there appear to exist a possibility to read
the currently known IP MTU using the Socket API. This might actually be
relevant when using IPv6, where ICMP much more needs to work.

> Is there a benefit, given the point above?

I claim that not all WebRTC endpoints will have this limiation. Either
from being a central conference node with native implementation, or by
being a privileged application.

> Is there a common userspace way to achieve this?

I don't know about common, but some OS do appear to have settings for
it. For example Linux appears to have a setsockopt flag called
IP_MTU_DISCOVER which allows you to force the DF always on IP_PMTUDISC_DO.

> The PNTAW discussion seems to indicate that there are scenarios where

Assuming that the result of the discussion is that it is needed.

> otherwise this won't achieve interoperability. Is RFC 4571 the right

It is is one framing that is defined for RTP over TCP. It will be able
to carry also the DTLS and STUN packets over the TCP connection. The
main question is the need to define a signalling name for this,
especially if one likes to consider it as pure datagram service, instead
of specific ones. The alternative is that we will need
TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP as signalling entities in SDP.

>From my perspective using end to end TCP with ICE-TCP is redundant from
the perspective of getting through restrictive firewalls compared to
TURN/TCP or TURN/TLS/TCP. I will agree with them not being identical,
but I question the motivation for requiring implementation of ICE-TCP
for this case, which anyway are supported by having TURN/TCP.

> This is being debated on PNTAW.

I will look there, however I do recommend that the conclusion from that
discussion being posted to the WG list for confirmation.

> implicit in the statement "we're using ICE".

Fine, the reference do include the STUN separation.

>> draft-ietf-rtcweb-data-channel that should have this text.

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/

Does not appear to have anything about this. But I think this is less
appropriate place to discuss that multiplexing.

> Please send text or pointers.

Will try.

Cheers

Magnus Westerlund

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Wed, 13 Nov 2013 16:33:52 +0000

Hi Magnus,

In case of Browser - GW/Server use cases (Sec 3.4 of draft-ietf-rtcweb-use-cases-and-requirements-12), the end-to-end TCP connection is between browser & Gateway directly. Here, GW/server acts as RTP endpoint/mixer in the middle of the network and acts as "RTP relay" [Note 1] to the actual remote endpoint. TURN server (TCP to UDP relay) is becoming "second middle box" in case GW/server provider has to deploy TURN server as well. ICE-TCP solves the issue as it creates the host candidates from GW/Server.

As Justin indicated in PNTAW, TURN 3rd party authentication is not required in case of ICE-TCP from GW/Server.

Thanks
Partha

Note 1: I could not think of more appropriate IETF terminology.

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, November 13, 2013 12:54 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Harald Tveit Alvestrand; [email-masked]
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

Hi Partha

Cheers

Magnus Westerlund

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Nov 2013 12:38:51 -0500

> In case of Browser - GW/Server use cases (Sec 3.4 of draft-ietf-rtcweb-use-cases-and-requirements-12), the end-to-end TCP connection is between browser & Gateway directly. Here, GW/server acts as R…

All this relies on the possibility that a TCP peer-to-peer connection 
could be successfully established where a UDP one couldn't. IMHO this is 
very unlikely to happen in practice. So unlikely in fact that any 
possible gain over just falling back on a TURN relay wouldn't be worth 
the additional implementation cost.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Wed, 13 Nov 2013 18:02:45 +0000

Hi Simon,

Please note that I'm only taking about Gateway/conference/IVR server usecases wherein Gateway/conference/IVR server will not be behind restrictive firewall and only the browser may be behind the restrictive firewall. 

TURN server will also make TCP connection to the GW provider in the mentioned scenario. So, there is no difference between ICE-TCP/TURN w.r.t TCP connection creation. In case TCP connection could not made between GW provider and the browser, the call will fail irrespective of firewall traversal mechanism (TURN/ICE-TCP) used. Also, there is no need of fallback to TURN server for these usecases. It is one of the reason, I'm asking for the separate usecase which clarify the requirements easily.

Thanks
Partha

-----Original Message-----
From: ext Simon Perreault [mailto:[email-masked]] 
Sent: Wednesday, November 13, 2013 11:09 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); ext Magnus Westerlund; Harald Tveit Alvestrand; [email-masked]
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Nov 2013 19:44:53 +0100

On 11/13/2013 06:38 PM, Simon Perreault wrote:
>> In case of Browser - GW/Server use cases (Sec 3.4 of
>> draft-ietf-rtcweb-use-cases-and-requirements-12), the end-to-end TCP
>> connection is between browser & Gateway directly. Here, GW/server
>> acts as RTP endpoint/mixer in the middle of the network and acts as
>> "RTP relay" [Note 1] to the actual remote endpoint. TURN server (TCP
>> to UDP relay) is becoming "second middle box" in case GW/server
>> provider has to deploy TURN server as well. ICE-TCP solves the issue
>> as it creates the host candidates from GW/Server.
>
> could be successfully established where a UDP one couldn't. IMHO this
> is very unlikely to happen in practice. So unlikely in fact that any

Simon, do you have any numbers on that - how many calls will be going to
servers on the Internet versus how many calls will be going peer-to-peer?
The argument being given only applies to the client-to-gateway usecase
(or to naked destination clients that are not behind a NAT, which
hopefully will become common once IPv6 gets deployed, but aren't common
now).

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Nov 2013 13:57:38 -0500

> servers on the Internet versus how many calls will be going peer-to-peer?

Not sure what you mean.

> The argument being given only applies to the client-to-gateway usecase

My point only applied to peer-to-peer connections, not peer-to-server. 
If we're discussing peer-to-server, then I wonder why we're discussing 
that at all.

> hopefully will become common once IPv6 gets deployed, but aren't common

If we eliminate NAT, then we're left with firewalls. To benefit from 
ICE-TCP (i.e. ICE-TCP successfully establishing a peer-to-peer TCP 
connection instead of ICE-UDP falling back on TURN-over-TCP), you would 
need both peers to be behind firewalls that block inbound UDP (through 
hole punching or otherwise) but allow inbound TCP (through simultaneous 
open or otherwise). My personal experience is that this kind of firewall 
configuration would be very rare. Now, take that probability and square 
it since it needs to apply to both peers. You get something very very rare.

Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Nov 2013 20:19:11 +0100

> If we're discussing peer-to-server, then I wonder why we're discussing

Because we agreed to include server-based systems in section 3.4 of the
use cases and requirements" document?

I think we have WG consensus that client-to-server based use cases,
while less important than browser-to-browser use cases, are still important.