Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

I read the two drafts referenced.

http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10 
looks OK both regarding not fighting firewall restrictions, and not
introducing quality degradation.

The enterprise use case with a restrictive firewall not allowing UDP to the
Internet is described under 4.2.5.1 and suggests the use of a local TURN
server on the LAN that "enabling cases where peers are both on the internal
side
to connect without the traffic leaving the internal network." I don't see
that it pin points how rtcweb outside LAN - to the Internet - would happen,
but an additional firewall/router could be added between the LAN TURN server
and the Internet to handle that. 

That would result in a separate pipe for rtcweb media - that the network
administer himself arranges! And he has even the possibility to arrange
better quality (prioritizing etc.) on that pipe than via the ordinary
firewall where rtcweb remains blocked.

Both
http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-0
0 and 
http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-00.txt 
describe ways of tunneling RTP traffic trough HTTP(S) TCP ports 80(443) that
are open in the firewall for surfing usage. 

Whether that tunneling has an extra framing from TURN/TCP, TURN/TLS or WS,
does not affect the discussion about trying to get rtcweb media through a
firewall that is configured to only allow surfing.

All of these fallbacks also results in RTP over TCP (instead of UDP as
usual) and therefore degrades quality due to the error correcting
retransmission. There is no way around that. (I believe the TURN/TLS is only
TCP half of the way - between the client and TURN server, but the firewall
being penetrated is often also the congestion point - so not much
improvement quality wise.) 

So, even if pushing RTC through the surf ports would not be considered
fighting the firewall restriction (How could it?), do we really want a
quality degraded fallback channel for rtcweb anyway? I'd say we should
encourage better quality networks to really step up from POTS quality voice
now that we have chance.

/Karl

-----Ursprungligt meddelande-----
Från: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] 
Skickat: den 23 maj 2013 15:09
Till: Simon Perreault; Karl Stahl
Kopia: rtcweb@ietf.org; behave@ietf.org
Ämne: RE: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for
draft-chenxin-behave-turn-websocket-00.txt

At least with regard to draft-hutton-rtcweb-nat-firewall-considerations we
are not attempting to enter or add to any existing arms race between clients
and firewalls.

We are only describing how to use existing IETF protocols which already
extensively discuss firewall traversal (E.g. TURN / RFC 5766) to meet the
RTCWEB requirements in this area which have existed in
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10
for almost two years now.

Of course if a network administer wants to block RTCWEB media they should be
able to so and nobody is I believe suggesting that we try to prevent this.

Regards
Andy

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On 
> Behalf Of Simon Perreault
> Sent: 22 May 2013 10:31
> To: Karl Stahl
> Cc: rtcweb@ietf.org; behave@ietf.org
> Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification 
> for draft-chenxin-behave-turn-websocket-00.txt
> 
> Le 2013-05-22 11:04, Karl Stahl a écrit :
> >> Firewall traversal is a completely different beast.
> >
> > Not really. There are always firewall functions included in "a NAT"
> (e.g.
> > open for traffic from inside to outside and you can then get traffic
> back
> > the same path - with some timeout), even if the RFCs only call the
> box "a
> > NAT". I prefer to say NAT/Firewall.
> 
> You're focusing on the technical aspect. The difference I'm 
> considering is not technical.
> 
> NAT traversal is performed with the agreement of everyone involved, 
> whereas firewall traversal is a battle between the client implementer 
> and the firewall administrator. There's also a potential arms race:
> firewalls will evolve with the ability to block whatever we 
> standardize, so we will need a newer traversal method, which firewalls 
> will end up blocking as well, etc. etc. etc. We don't want to play 
> that game.
> 
> NAT traversal: ok
> Firewall traversal: not for the IETF
> 
> Simon
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave