Subject: Re: [pntaw] Real-time media over TCP

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 7 Oct 2013 23:36:32 +0530

Hi all,

RTP over TCP is unavoidable in case of RTCWeb media traffic has to traverse
through UDP blocking firewalls. TCP candidates with ICE (RFC 6544) may fail
due to the current OS implementation wherein TCP simultaneous Open will not
work. 

I have concern w.r.t TURN server as it introduces one extra network element
for RTCWeb session establishment. The current argument favoring for TURN
server is that RTP over TCP is required only till TURN server whereas the
media traffic between TURN server and the destination is UDP. In couple of
WebRTC deployment in Service provider network and Enterprise network, TURN
server will exist near to the destination and the WebRTC media traffic in
the internet is "RTP over TCP". I guess that Victor scenario falls under the
same category. In these deployment, RTP over TCP has advantage over TURN
over TCP as the extra element shall be avoided. 

Also, SCTP over DTLS over UDP will not work in case of RTCWeb media traffic
has to traverse through UDP blocking firewalls. So, there is a need of SCTP
over DTLS over TCP or multipath TCP kind of transport to meet this
requirement which needs separate discussion. 

Thanks
Partha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dan Wing
> Sent: Wednesday, September 04, 2013 1:47 AM
> To: Harald Alvestrand
> Cc: Bernard Aboba; [email-masked]
> Subject: Re: [pntaw] Real-time media over TCP
> 
> 
> On Sep 3, 2013, at 11:11 AM, Harald Alvestrand <[email-masked]>
> wrote:
> 
> > On 09/03/2013 07:25 PM, Dan Wing wrote:
> >>> Multiple TCP connections seems like a suboptimal design, given the
> existence of other solutions like Minion or SCTP.
> >> Sure.  But those technologies weren't on the table when Victor did
> interactive audio/video over TCP, I'm sure.  Much like they weren't on
> the table when HTTP started doing multiple TCP connections back in the
> early days of Netscape.
> >
> > Victor didn't provide a date, so I was thinking "recently" - SCTP is
> 10 years old at this point.
> 
> SCTP has been around a long time as a protocol but for a variety of
> reasons has seen no deployment on the Internet to date, including no
> availability in the mainstream OSs which is everyone's interest.  SCTP-
> over-UDP was only recently defined and its user-mode release was only
> 12 or 18 months ago or so.
> 
> > Minion is newer than that, of course.
> >>
> >>> If both sides have TURN over TCP (or TURN over HTTP) enabled, and
> their respective TURN servers can talk UDP to each other, communication
> will occur, I think. I don't think we need to add TCP candidates for
> the TURN case in order to bypass firewalls.
> >>>
> >>> We might want to do so for the benefit of the pure peer-to-peer
> case, but I'm not sure it's a case that's important enough to make 6062
> (TURN TCP allocations) or 6544 (ICE TCP allocations, no TURN server)
> into MUSTs for RTCWEB.
> >> I agree.  Additionally, before anyone ventures too far down that
> path it would be useful to understand how well the expected RTCWeb
> endpoints could do peer-to-peer TCP connections.  Reliable peer-to-peer
> TCP needs TCP simultaneous open needs to work well on both hosts, per
> the research by Saikat Guha and Paul Francis
> http://conferences.sigcomm.org/imc/2005/papers/imc05efiles/guha/guha.pd
> f.  In that research, they found Windows XP SP1 doesn't do simultaneous
> open well, but Windows XP with SP2 and SP3 and Linux worked okay.  I
> have not seen similar research for Android, OS X, or Windows 7 or
> Windows 8.
> > Indeed; that article seemed to indicate that the brand of NAT you
> bought was a decisive factor - it would be interesting to see if the
> state of the art has become more or less symmetric-TCP hostile in the
> intervening 8 years.
> 
> -d
> 
> _______________________________________________
> pntaw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pntaw

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Oct 2013 11:32:44 -0700

As you point out, in most cases ICE-TCP will not avoid use of TURN, so we are only talking about a modest efficiency gain for ICE-TCP and RTP over TCP, but a substantial increase in complexity. 

Running SCTP over TCP is undesirable because the congestion control in SCTP and TCP will interact poorly with each other.  

> On Oct 7, 2013, at 11:07 AM, "Parthasarathi R" <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Dan Wing <[email-masked]>
Date: Mon, 7 Oct 2013 13:08:31 -0700

> Running SCTP over TCP is undesirable because the congestion control in SCTP and TCP will interact poorly with each other.  

And, even if a full SCTP stack is run over a full TCP stack, that will work but I agree won't work well.  But working is better than not working in situations where UDP is blocked.

To work well, we might look at SCTP Minion (draft-iyengar-minion-concept, which disables TCP's congestion control in lieu of SCTP's congestion control) is one answer to those conflicting congestion controls.

-d

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 7 Oct 2013 22:14:19 +0200

> To work well, we might look at SCTP Minion (draft-iyengar-minion-concept, which disables TCP's congestion control in lieu of SCTP's congestion control) is one answer to those conflicting congestion…
This would either require changing the TCP stack in the kernel or using a
userland TCP stack without CC, which would require using a raw socket for
sending, for receiving some other strategy, both would require root privileges...
Or am I missing something?

Best regards
Michael

---

From: Dan Wing <[email-masked]>
Date: Mon, 7 Oct 2013 13:34:23 -0700

> Or am I missing something?

Yes, start with something that works but is not optimal (SCTP over TCP) and expect/hope that one of the future paths are better:  OS vendors provide native SCTP support and networks support native SCTP, UDP is permitted by networks (allowing SCTP-over-UDP to work without competing CC), or OS vendors support SCTP Minion (which also avoids competing CC).

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 08 Oct 2013 06:09:35 +0200

On 10/07/2013 10:14 PM, Michael Tuexen wrote:
>>> As you point out, in most cases ICE-TCP will not avoid use of TURN,
so we are only talking about a modest efficiency gain for ICE-TCP and
RTP over TCP, but a substantial increase in complexity.
>>>
>>> Running SCTP over TCP is undesirable because the congestion control
in SCTP and TCP will interact poorly with each other. 
>>
>> And, even if a full SCTP stack is run over a full TCP stack, that
will work but I agree won't work well.  But working is better than not
working in situations where UDP is blocked.
>>
>> To work well, we might look at SCTP Minion
(draft-iyengar-minion-concept, which disables TCP's congestion control
in lieu of SCTP's congestion control) is one answer to those conflicting
congestion controls.
> Or am I missing something?

If I remember the minion overview correctly, it will in fact work on an
unmodified TCP stack, but if there are ioctls available to get frames
out of order, it can work a good deal better.

But you should get Iengar himself to talk about it if it's of interest.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 08 Oct 2013 06:32:04 +0200

On 10/07/2013 08:06 PM, Parthasarathi R wrote:
> media traffic between TURN server and the destination is UDP.

Don't forget the (likely) case where the destination is also reached
through a TURN server, so that the path is

user 1->TCP->TURN server 1->UDP->TURN server 2->TCP->user 2

For extra irony, the two clients may be using the same TURN service, so
that the UDP hop is an intra-datacenter or even intra-machine hop :-)

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 8 Oct 2013 14:38:48 +0200

On Oct 8, 2013, at 6:09 AM, Harald Alvestrand <[email-masked]> wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
His point is that you can work with an unchanged stack, but don't
get any benefit. The point in the above is to use a TCP without CC,
which requires an end-host change. So it is not so easy to get rid
of the TCP CC when using a kernel TCP stack.

Best regards
Michael
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJSU4V/AAoJEIjUFboxkRizAkQH/ixIr8I/pd/hb9FCdvJv9IaT
> 3Rgp/nYIQdaEUOdZNjdTFuoSU9ruhQ5G+Wd8PouDwS+8hdy8Dry/AOYbNxHrRjdO
> 4lvyLslOIwksOjMmkJ198RFzQTzvNjsCJQaDhmf/kMaZ0r1KF3lDjWXCzOPRetLs
> fy+5nuzzuLrInG4rqkMX2nX4J5endXYxUoX8BOclDjm33YfxPw0/bJHQNE0Iq9Oi
> mmw1zf8fzTze/ilqlEpFHv9T/CWGCQGoKinzUbWscOUZNpzPGnur/9pqfQTgMkL/
> QWQcKuy2T7QxzIwMF9vz7xHfJvzDxD8fS9Fy1t65LScqFBnppR0qQrlxhYvnu+I=
> =W/ti
> -----END PGP SIGNATURE-----
> 
>

---

From: Dan Wing <[email-masked]>
Date: Tue, 8 Oct 2013 08:04:03 -0700

On Oct 8, 2013, at 5:38 AM, Michael Tuexen <[email-masked]> wrote:

> get any benefit.

The application sees SCTP -- that must have some benefit.

-d

> The point in the above is to use a TCP without CC,

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 8 Oct 2013 23:22:46 +0530

Hi Bernard/Harald,

I understand that two WebRTC endpoint are behind firewall scenario wherein
TURN server is unavoidable. Most of the SP & Enterprise deployment wherein
one of the endpoint is not surely going to be behind UDP blocking Firewall,
mandating TURN server as a mechanism is overkill. As ICE is mandated in
WebRTC, supporting ICE-TCP should not be such a complex activity.

Thanks
Partha

> Of Bernard Aboba
> Sent: Tuesday, October 08, 2013 12:03 AM
> To: Parthasarathi R
> Cc: Harald Alvestrand; [email-masked]; Dan Wing
> As you point out, in most cases ICE-TCP will not avoid use of TURN, so
> we are only talking about a modest efficiency gain for ICE-TCP and RTP
> over TCP, but a substantial increase in complexity.
> 
> Running SCTP over TCP is undesirable because the congestion control in
> SCTP and TCP will interact poorly with each other.
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Oct 2013 20:25:18 +0200

> WebRTC, supporting ICE-TCP should not be such a complex activity.

A firewall that blocks UDP but allows incoming TCP is not very common, 
is it?

Or did I miss something?

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: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Oct 2013 11:59:03 -0400

> that the UDP hop is an intra-datacenter or even intra-machine hop :-)

If that happens, its time to seek out a new TURN server vendor.
A good one should be able to figure this out and optimize it.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 9 Oct 2013 22:31:06 +0530

Hi Simon,

I have seen only two requirements in
draft-ietf-rtcweb-use-cases-and-requirements-11, NAT/FW that blocks UDP and
FW that only allows http. The relevant draft snippet is attached as a note
of this mail. I'm discussing about NAT/FW that blocks UDP requirement. In
case you foresee that the requirement is not detailed now, we need to sort
out the requirement first before discussion the solutions.

Regards
Partha

PS: In draft-ietf-rtcweb-use-cases-and-requirements-11 snippet,

3.2.2.  Simple Video Communication Service, NAT/FW that blocks UDP

3.2.2.1.  Description

   This use-case is almost identical to the Simple Video Communication
   Service use-case (Section 3.2.1).  The difference is that one of the
   users is behind a NAT that blocks UDP traffic.

3.2.3.  Simple Video Communication Service, FW that only allows http

3.2.3.1.  Description

   This use-case is almost identical to the Simple Video Communication
   Service use-case (Section 3.2.1).  The difference is that one of the
   users is behind a FW that only allows http traffic.

> Of Simon Perreault
> Sent: Tuesday, October 08, 2013 11:55 PM
> To: [email-masked]

---

From: <[email-masked]>
Date: Wed, 9 Oct 2013 17:29:54 +0000

Hi,

I think the clarification is that it is not possible to initiate TCP connections from the "outside" of any NAT or most of the firewalls. So even if the FW does not block TCP per se, it only allows TCP connections to be opened from the "inside". 

I believe ICE-TCP will typically work only in cases where at least one of the endpoints is NOT behind a NAT or FW. In cases where both endpoints are behind firewalls completely blocking all UDP, the only option is to use a relay (TURN) with endpoint initiated TCP connections. ICE allows us to optimize connectivity in special cases, but I think we need also to make the worst case scenarios to work. For that reason I don't see that ICE-TCP could replace TURN as a requirement for every browser to implement. In some specific deployments it may be that TURN does not get used much or at all, but browsers are used everywhere.

Markus 

> Of ext Parthasarathi R
> Sent: 09 October, 2013 20:01
> To: 'Simon Perreault'; [email-masked]
> draft-ietf-rtcweb-use-cases-and-requirements-11, NAT/FW that blocks UDP
> and FW that only allows http. The relevant draft snippet is attached as a note

---

From: <[email-masked]>
Date: Wed, 9 Oct 2013 17:38:55 +0000

Hi Paul,

Paul Kyzivat wrote:
> > For extra irony, the two clients may be using the same TURN service,
> > so that the UDP hop is an intra-datacenter or even intra-machine hop
> > :-)
> 

I think it can happen even if the vendor and the service provider do all they can. For instance if both endpoints are behind a UDP blocking firewall and can only open TCP connections. So unless the endpoints support TCP-based ICE candidates, I think they need to connect to their respective TURN relays and only via them they can reach each other's TURN-allocated UDP candidates. So the transport will be split into 3 hops: TCP - UDP - TCP, where the UDP part can be potentially very short.

Or is there some way to optimize from that? If I've understood correctly, ICE-TCP with TURN-allocated TCP ports would allow using just a single relay in the above scenario. It would be thus be better in case if the relays used by the endpoints were NOT in the same DC.

Markus

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Oct 2013 15:06:30 -0400

> Or is there some way to optimize from that? If I've understood correctly, ICE-TCP with TURN-allocated TCP ports would allow using just a single relay in the above scenario. It would be thus be bett…

My point was that if both use the *same* TURN server, then it should be 
smart enough to avoid establishing a UDP connection to itself.

	Thanks,
	Paul

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Thu, 10 Oct 2013 01:52:36 +0000

Hi

 I agree that ICE-TCP should not replace TURN as a requirement for every browser to implement. If we need support ICE-TCP , should we support TURN-TCP too? I do not think ICE-TCP will be more useful without TURN-TCP in the scenario where both browsers is under the NAT /FW which block UDP. 

  I believe the user 1->TCP->TURN server 1->UDP->TURN server 2->TCP->user 2, which Harald wrote before is workable. It is easy to tunnel the data internally if we need use the same server, right?

Best Regards,
     Xin 

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Thursday, October 10, 2013 1:30 AM
>To: [email-masked]; [email-masked]; [email-masked]
>I think the clarification is that it is not possible to initiate TCP connections from
>the "outside" of any NAT or most of the firewalls. So even if the FW does not
>block TCP per se, it only allows TCP connections to be opened from the "inside".
>
>I believe ICE-TCP will typically work only in cases where at least one of the
>endpoints is NOT behind a NAT or FW. In cases where both endpoints are behind
>firewalls completely blocking all UDP, the only option is to use a relay (TURN)
>with endpoint initiated TCP connections. ICE allows us to optimize connectivity
>in special cases, but I think we need also to make the worst case scenarios to
>work. For that reason I don't see that ICE-TCP could replace TURN as a
>requirement for every browser to implement. In some specific deployments it
>may be that TURN does not get used much or at all, but browsers are used
>everywhere.
>
>Markus
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 10 Oct 2013 23:10:17 +0530

Hi all,

As I mentioned below, ICE-TCP is not replacement for TURN but ICE-TCP helps
for the browser-to-browser media flow without middle box (TURN Server).
Also, please note that both browsers behind UDP blocked firewall is not the
worst case scenario for WebRTC firewall requirements. The actual worst case
scenario is that both browsers are behind HTTP only firewalls and in this
scenario, both TURN server and ICE-TCP will not work. There is a need of one
more solution.

AFAIK, HTTP allowing firewall is not happen by mis-configuration but it is
policy of the given network. It is more appropriate to pass the media over
HTTP based mechanism rather than finding the workarounds. The advantage with
Media over HTTP is that HTTP friendly firewall shall filter out media from
HTTP traffic if required. IMO, Media over HTTP based mechanism has to be
used for HTTP only firewall (Sec 3.2.3 of
draft-ietf-rtcweb-use-cases-and-requirements) requirement and ICE-TCP shall
be used for (Sec 3.2.3 of draft-ietf-rtcweb-use-cases-and-requirements)
requirement. 

Thanks
Partha  

> Of Chenxin (Xin)
> Sent: Thursday, October 10, 2013 7:23 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
>  I agree that ICE-TCP should not replace TURN as a requirement for
> every browser to implement. If we need support ICE-TCP , should we
> support TURN-TCP too? I do not think ICE-TCP will be more useful
> without TURN-TCP in the scenario where both browsers is under the NAT
> /FW which block UDP.
> 
>   I believe the user 1->TCP->TURN server 1->UDP->TURN server 2->TCP-
> >user 2, which Harald wrote before is workable. It is easy to tunnel
> the data internally if we need use the same server, right?
> 
> Best Regards,
>      Xin
> 
> 
> Of
> >> > > I understand that two WebRTC endpoint are behind firewall
> scenario
> >> > wherein
> >> > > TURN server is unavoidable. Most of the SP & Enterprise
> deployment
> >> > wherein
> >> > > one of the endpoint is not surely going to be behind UDP
> blocking
> >> > Firewall,
> >> > > mandating TURN server as a mechanism is overkill. As ICE is
> mandated
> >> > in

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Fri, 11 Oct 2013 03:57:39 +0000

Hi
>HTTP traffic if required.
[xin] And media over websocket should be a option. The sub-protocol attribute in websokcet could also provide the firewall friendly information, so the firewall could decide to filter out the media or not. 

 IMO, Media over HTTP based mechanism has to be
>be used for (Sec 3.2.3 of draft-ietf-rtcweb-use-cases-and-requirements)

  [Xin] I think you means ICE-TCP shall be used for (*Sec 3.2.2* of draft-ietf-rtcweb-use-cases-and-requirements) requirement.:)

Thanks,
  Xin

---

From: <[email-masked]>
Date: Fri, 11 Oct 2013 12:21:37 +0000

Hi Partha,

Parthasarathi R [mailto:[email-masked]] wrote:
> 
> Hi all,
> 
> As I mentioned below, ICE-TCP is not replacement for TURN but ICE-TCP
> helps for the browser-to-browser media flow without middle box (TURN
> Server).

Agree. And we need to consider that BOTH endpoints may be behind such firewalls.
 
> HTTP based mechanism rather than finding the workarounds. The advantage
> with Media over HTTP is that HTTP friendly firewall shall filter out media from
> draft-ietf-rtcweb-use-cases-and-requirements) requirement and ICE-TCP
> shall be used for (Sec 3.2.3 of draft-ietf-rtcweb-use-cases-and-
> requirements)
> requirement.
> 

So, what is the overall set of traversal / connectivity / address gathering mechanisms the browser should support that you are advocating? Mine is:

1.) UDP host candidates (native interface) - MUST
2.)UDP server-reflexive candidates (STUN) - MUST
3.) UDP relay candidates via UDP (TURN) - MUST
4.) UDP relay candidates via TCP (TURN) - MUST
5.) UDP relay candidates via some HTTP/TLS compatible transport (TURN) - MUST/SHOULD
   (TLS via HTTP CONNET or TURN over WebSockets have been proposed.)
6.) TCP based candidates (ICE-TCP) - MAY/SHOULD

I believe 1.), 2.) and 3.) we all have consensus on, probably even on 4.). What we are discussing on this list is whether and how to do 5.), and how important 6.) is. 

My opinion is that 5.) becomes necessary due to the HTTP-limited environments you mention above. So the communication needs to be compliant with HTTP and its upgrade mechanisms. 6.) I see as an optimization to 4.) in cases where you can't do UDP but can establish outgoing TCP connections and the other peer can actually receive them. But that optimization does not hold very often, since most of the time browsers are in networks where they can't receive TCP connections from the "outside world". So that's why I see it as MAY or SHOULD. You may argue that often browsers may talk to gateways or central points that are reachable by TCP, and in those scenarios ICE-TCP might make sense. 

Markus

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 14 Oct 2013 14:42:11 +0000

On: 11 October 2013 13:22  [email-masked] Wrote

> 
> So, what is the overall set of traversal / connectivity / address
> gathering mechanisms the browser should support that you are
> advocating? Mine is:
> 
> I believe 1.), 2.) and 3.) we all have consensus on, probably even on
> 4.). What we are discussing on this list is whether and how to do 5.),
> and how important 6.) is.
> 
> My opinion is that 5.) becomes necessary due to the HTTP-limited
> environments you mention above. So the communication needs to be
> compliant with HTTP and its upgrade mechanisms. 6.) I see as an
> optimization to 4.) in cases where you can't do UDP but can establish
> outgoing TCP connections and the other peer can actually receive them.
> But that optimization does not hold very often, since most of the time
> browsers are in networks where they can't receive TCP connections from
> the "outside world". So that's why I see it as MAY or SHOULD. You may
> argue that often browsers may talk to gateways or central points that
> are reachable by TCP, and in those scenarios ICE-TCP might make sense.
> 

Totally agree with the nice summary above and agree that 5) is necessary we have use cases in draft-ietf-rtcweb-use-cases-and-requirements that say we do. We need some mechanism that is HTTP compatible and we have these two options available and to me there is very little difference between them it is just a matter of whether the use of the additional websockets layers give us any benefit. I am not convinced that 6) is needed but might be some corner cases it satisfies.

Andy

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 14 Oct 2013 08:08:40 -0700

Agree on Markus's summary. I am also not convinced on #6 being a MUST because so far there hasn't been a compelling use case.

> On Oct 14, 2013, at 7:42 AM, "Hutton, Andrew" <[email-masked]> wrote:
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 14 Oct 2013 17:58:07 +0200

+1,

IMO 6) will only have some benefits in the case one of the endpoint been 
a gateway, but you would still have to deal with 5), so you won't avoid 
needing a TURN server (in any of its flavors ;)

BR
Sergio

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 15 Oct 2013 00:00:22 +0530

Xin,

<snip> The
> advantage
> >with
> [xin] And media over websocket should be a option. The sub-protocol
> attribute in websokcet could also provide the firewall friendly
> information, so the firewall could decide to filter out the media or
> not.
</snip>

Agreed. I'll write DTLS-SRTP over WebSocket draft for more clarity.  

Please read inline.

Thanks
Partha

> From: Chenxin (Xin) [mailto:[email-masked]]
> Sent: Friday, October 11, 2013 9:28 AM
> To: Parthasarathi R; [email-masked];
> Subject: RE: [pntaw] Real-time media over TCP
> 
> Hi
> >Hi all,
> >
> helps
> >with
> [xin] And media over websocket should be a option. The sub-protocol
> attribute in websokcet could also provide the firewall friendly
> information, so the firewall could decide to filter out the media or
> not.
> 
> shall
>   [Xin] I think you means ICE-TCP shall be used for (*Sec 3.2.2* of
> draft-ietf-rtcweb-use-cases-and-requirements) requirement.:)

<Partha> Thanks for the indicating the cut&paste issue :-(. Your thinking is
correct. </Partha>

> >> >I think the clarification is that it is not possible to initiate
> TCP
> >> connections from
> >> >the "outside" of any NAT or most of the firewalls. So even if the
> FW
> >> does not
> >> >block TCP per se, it only allows TCP connections to be opened from
> the
> >> "inside".
> >> >
> >> >I believe ICE-TCP will typically work only in cases where at least
> one
> >> of the
> >> >endpoints is NOT behind a NAT or FW. In cases where both endpoints
> are
> >> behind
> >> >> draft-ietf-rtcweb-use-cases-and-requirements-11, NAT/FW that
> blocks
> >> UDP
> >> >> and FW that only allows http. The relevant draft snippet is
> attached
> >> as a note
> >> >> case you foresee that the requirement is not detailed now, we
> need
> >> to sort
> >> >>    Service use-case (Section 3.2.1).  The difference is that one
> of
> >> the
> >> >>    Service use-case (Section 3.2.1).  The difference is that one
> of
> >> the

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 15 Oct 2013 00:24:37 +0530

Hi all,

My point is that the direct media connection has to be given priority over
TURN based mechanism. In case of ICE-TCP, there is a possibility for the
direction connection between two browsers involved in the WebRTC session and
should be given priority over TURN based mechanism. So, 6) TCP based
candidates (ICE-TCP) - MUST

There is an assumption in the discussion that the incoming TCP traffic is
not allowed through firewall. In case it is the problem to be solved, RTCWeb
usecase and requirement has to be updated. I noticed in
draft-ietf-rtcweb-use-cases-and-requirements-12 (published today) that there
is no such requirement. I'll write the mail in RTCWeb WG to get the clarity
on the requirement in case the firewall forbidding incoming TCP traffic is a
matter of missing text in the requirement.

Thanks
Partha  

> Of Sergio Garcia Murillo
> Sent: Monday, October 14, 2013 9:28 PM
> To: [email-masked]
> > Agree on Markus's summary. I am also not convinced on #6 being a MUST
> because so far there hasn't been a compelling use case.
> >
> >> On Oct 14, 2013, at 7:42 AM, "Hutton, Andrew"
> <[email-masked]> wrote:
> >>
> >>> 5.) UDP relay candidates via some HTTP/TLS compatible transport
> (TURN)
> >>> - MUST/SHOULD
> >> Totally agree with the nice summary above and agree that 5) is
> necessary we have use cases in draft-ietf-rtcweb-use-cases-and-
> requirements that say we do. We need some mechanism that is HTTP
> compatible and we have these two options available and to me there is
> very little difference between them it is just a matter of whether the
> use of the additional websockets layers give us any benefit. I am not
> convinced that 6) is needed but might be some corner cases it
> satisfies.
> >>
> >> Andy

---

From: <[email-masked]>
Date: Mon, 14 Oct 2013 19:06:15 +0000

Hi,

In practice I doubt you find many situations where UDP is completely blocked but incoming TCP connections from anywhere are allowed. I'm not sure the use cases and requirements document really claims that to be the case, but I agree it is somewhat ambiguous. That means that while direct TCP connection would be better than TCP based relay, its success rate would be very small. I suppose we agree that UDP based relay would still be better than direct TCP for real-time media.

Markus

> Sent: 14 October, 2013 21:55
> To: [email-masked]
> direction connection between two browsers involved in the WebRTC session
> and should be given priority over TURN based mechanism. So, 6) TCP based
> There is an assumption in the discussion that the incoming TCP traffic is not
> allowed through firewall. In case it is the problem to be solved, RTCWeb
> draft-ietf-rtcweb-use-cases-and-requirements-12 (published today) that
> there is no such requirement. I'll write the mail in RTCWeb WG to get the
> clarity on the requirement in case the firewall forbidding incoming TCP traffic
> is a matter of missing text in the requirement.
> 
> Thanks
> Partha
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Oct 2013 17:42:51 -0400

> In practice I doubt you find many situations where UDP is completely blocked but incoming TCP connections from anywhere are allowed. I'm not sure the use cases and requirements document really clai…

Doesn't that depend on where the relay is?

UDP relayed across the world might not be preferable to TCP direct to a 
point down the street.

But in practice I suppose the relay will be conveniently located 
relative to one of the two endpoints.

	Thanks,
	Paul

---

From: Dan Wing <[email-masked]>
Date: Mon, 14 Oct 2013 17:01:26 -0700

On Oct 14, 2013, at 12:06 PM, [email-masked] wrote:

> Hi,
> 
> In practice I doubt you find many situations where UDP is completely blocked but incoming TCP connections from anywhere are allowed.

Agreed.  

But if both ends are trying to communicate with each other, their communications will appear as a TCP simultaneous-open.  That could (in fact, "should") work across a firewall because the firewall will see an outbound SYN to a host/port after which it will see an inbound SYN from that same host/port.

-d

> I'm not sure the use cases and requirements document really claims that to be the case, but I agree it is somewhat ambiguous. That means that while direct TCP connection would be better than TCP based relay, its success rate would be very small. I suppose we agree that UDP based relay would still be better than direct TCP for real-time media.
> 
> Markus
>

---

From: Dan Wing <[email-masked]>
Date: Mon, 14 Oct 2013 17:04:43 -0700

On Oct 14, 2013, at 2:42 PM, Paul Kyzivat <[email-masked]> wrote:

> UDP relayed across the world might not be preferable to TCP direct to a point down the street.
> 
> But in practice I suppose the relay will be conveniently located relative to one of the two endpoints.

I think that is a separate problem.  Smart ICE candidate prioritization would choose the "best candidate" (for some value of "best candidate").  The ICE connectivity check round-trip time is an oft-cited example of a reasonable metric (although it doesn't measure bandwidth and packet loss is considered by some to mislead [but if a path is lossy it may indeed be a very undesirable path]).  Geolocation of the TURN IP address versus my own IP address could also influence ICE candidate prioritization or candidate selection.

-d

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Oct 2013 17:08:41 -0700

On Mon, Oct 14, 2013 at 5:04 PM, Dan Wing <[email-masked]> wrote:

> I think that is a separate problem.  Smart ICE candidate prioritization
> would choose the "best candidate" (for some value of "best candidate").
>  The ICE connectivity check round-trip time is an oft-cited example of a
> reasonable metric (although it doesn't measure bandwidth and packet loss is
> considered by some to mislead [but if a path is lossy it may indeed be a
> very undesirable path]).  Geolocation of the TURN IP address versus my own
> IP address could also influence ICE candidate prioritization or candidate
> selection.
>
> -d
>
>
Hi Dan,

I don't think I understand who is running a geolocation algorithm in this
scenario.  Can you elaborate?

regards,

Ted

---

From: Dan Wing <[email-masked]>
Date: Mon, 14 Oct 2013 17:52:50 -0700

On Oct 14, 2013, at 5:08 PM, Ted Hardie <[email-masked]> wrote:

> I don't think I understand who is running a geolocation algorithm in this scenario.  Can you elaborate?

The RTCWEB host.  For example, it could ask a geolocation service how many miles away the TURN server's IP address is from itself.  I'm not saying this is better than just doing a STUN transaction with that same TURN server; I just wanted another way to influence ICE candidate selection.

-d

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 15 Oct 2013 06:02:34 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing (dwing)
> Sent: Tuesday, October 15, 2013 5:31 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> > In practice I doubt you find many situations where UDP is completely blocked
> but incoming TCP connections from anywhere are allowed.
> 
> Agreed.
> 
> But if both ends are trying to communicate with each other, their
> communications will appear as a TCP simultaneous-open.  That could (in fact,
> "should") work across a firewall because the firewall will see an outbound SYN
> to a host/port after which it will see an inbound SYN from that same
> host/port.

But firewall TCP inspection causes the inbound SYN from the same host/port to be dropped (Firewalls typically do not permit TCP simultaneous-open). Even with NAT as per the survey results in ICE TCP (http://tools.ietf.org/html/rfc6544#appendix-A) TCP simultaneous-open worked only in roughly 45% of the cases.

-Tiru.

> 
> -d
> 
> 
> > I'm not sure the use cases and requirements document really claims that to
> be the case, but I agree it is somewhat ambiguous. That means that while
> direct TCP connection would be better than TCP based relay, its success rate
> would be very small. I suppose we agree that UDP based relay would still be
> better than direct TCP for real-time media.
> >
> > Markus
> >
> not

---

From: Dan Wing <[email-masked]>
Date: Tue, 15 Oct 2013 09:15:57 -0700

> But firewall TCP inspection causes the inbound SYN from the same host/port to be dropped (Firewalls typically do not permit TCP simultaneous-open). Even with NAT as per the survey results in ICE TC…

If avoiding TURN improves the user experience, and IT policy says TCP is allowed, I expect firewall vendors would make sure TCP simultaneous open works.

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 16 Oct 2013 14:02:51 +0200

> If avoiding TURN improves the user experience, and IT policy says TCP is allowed, I expect firewall vendors would make sure TCP simultaneous open works.
If something improves the user experience if it is possible to do it, 
but the basic functionality works without it, and it's unclear whether 
the special circumstances under which it's going to improve the user 
experience in fact exist in the field, I think that's perfect for a MAY 
implement.

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 20 Oct 2013 21:40:53 +0530

Hi Harald & all,

I agree that ICE-TCP qualifies for "MAY" requirement in case both browsers
are behind firewall. ICE-TCP is good for usecase wherein only one of the
browsers is behind firewall. Existing WebRTC usecase namely FedEx call is
good example for only one browser behind firewall wherein IVR is not going
to be behind UDP blocking firewall. In those usecases, ICE-TCP candidates
has merits over TURN relay candidates. IMO, ICE-TCP MUST be considered.

The current WebRTC FW usecase is (accidentially) inline with one of the
browser behind firewall scenario as mentioned in sec 3.3.2.1 of
draft-ietf-rtcweb-use-cases-and-requirements-12:

"The difference is that one of the users is behind a NAT that blocks UDP
traffic."

Thanks
Partha

> Of Harald Alvestrand
> Sent: Wednesday, October 16, 2013 5:33 PM
> To: [email-masked]
> >> But firewall TCP inspection causes the inbound SYN from the same
> host/port to be dropped (Firewalls typically do not permit TCP
> simultaneous-open). Even with NAT as per the survey results in ICE TCP
> (http://tools.ietf.org/html/rfc6544#appendix-A) TCP simultaneous-open
> worked only in roughly 45% of the cases.
> > If avoiding TURN improves the user experience, and IT policy says TCP
> is allowed, I expect firewall vendors would make sure TCP simultaneous
> open works.
> >
> >