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

["Karl Stahl" <[e-mail]>]

All,

 

Isn’t such a low quality fallback channel for penetrating restrictive
NAT/Firewalls NEGATIVE for RTCweb?

 

QUALITY: Any tunneling of RTP through the “always open” HTTP 80 or HTTPS 443
ports is RTP over an error correcting TCP channel. Thus, lost packets will
be retransmitted, resulting in second long packet delays. Jitter buffers
don’t handle that and if they did, we will not be happy with second long
delays in RTC, i.e. two-way real-time communications. That is why we run RTP
over UDP.

 

(When discussing QoS, some will stand up and tell that sound quality really
was good – it is all about bandwidth, etc. Yes, quality in an IP network is
good when you don’t fill the pipe – even this TCP-pipe is. But in today’s
data crowded networks, where you are not alone, the pipe is filled at every
email or click on a webpage. Then packets are lost, and with the fallback
discussed you don’t even have the benefit of UDP over TCP transport.)

 

SKYPE: Yes, I know Skype has a similar fallback – same low quality - and I
have heard the argument “Otherwise we will have to continue answering for
another 10 years "why is this app not working if skype does". But why should
that be the ambition of the RTCweb standards?

 

DECIDING NETWORK USAGE: Doesn’t the network administrator that configured
the firewall have a legitimate right to decide what traffic should be on his
network? If he only wants internal traffic and surfing, shouldn’t it be his
choice to be able to configure just that? And if a service provider (SP)
blocks all but surfing on his access, the user can get another subscription
if he wants to benefit from using  RTCweb (and that SP will go out of
business…or can just offer his access at a very low cost for surfing only
usage).

 

Not getting RTCweb through a restrictive firewall, may rather encourage the
network administer to resolve the problem properly, than if we provide a
fallback with lousy quality. Then the user may not be interested in the “bad
RTCweb” and won’t ask his network administrator to “enable it”.

 

BETTER THAN BEST EFFORT: Actually, it we “enable networks for RTCweb”, we
could quality wise get a BETTER pipes for RTCweb media than for surfing! The
STUN/TURN server address provided actually allows ICE/TURN/STUN media to be
routed another path than data traffic – a better path, maybe even with level
3 QoS (diffserve or RSVP if we are lucky).

 

Remember, that we finally are stepping up from 100 years old 3,5 kHz voice
only to potentially telepresence HiFi HD 3.5 Mbps quality. We should
encourage that the networks support this potential, rather than providing a
low quality fallback, that will bring a bad user experience to RTCweb.

 

NEW VIEW ON ICE: I think it is time to view the ICE/TURN/STUN protocol suit
in an alternative way. Instead of being a way to fool or trick media through
a NAT/Firewall that is unaware of what is happening, regard ICE/TURN/STUN as
a protocol to Request Access for RTC through the firewall. Firewalls – if
combined with the STUN/TURN server – could then respond not just by opening
a path for RTC, but could also prioritize and shape the traffic in the
firewall for much better quality. (A firewall is often the point where
congestion can be controlled.) And the firewall could request quality over
the transport network for the RTC media (heard cable operators were
interested to do that with their reservation type of QoS they use for voice)
– others could use diffserve.

 

TURN and STUN servers also include authentication – Maybe they were intended
for “Request pass trough” rather than “Fool media through”, were they?

 

/Karl

 

 

Från:  <mailto:[e-mail]> [e-mail] [
<mailto:[e-mail]> mailto:[e-mail]] För Hutton,
Andrew
Skickat: den 21 maj 2013 15:34
Till: Simon Pietro Romano
Kopia:  <mailto:[e-mail]> [e-mail];  <mailto:[e-mail]>
[e-mail]
Ämne: Re: [rtcweb] New Version Notification for
draft-chenxin-behave-turn-websocket-00.txt

 

Hi Simon

 

I believe all possible solutions deserve attention however my feeling is
that the HTTP Connect based mechanism for connecting to the TURN server via
TURN/TCP/TLS has a good chance of being implemented by browsers.

 

What I would really like to happen is for
draft-hutton-rtcweb-nat-firewall-considerations to be adopted and progressed
by the WG to describe the preferred solution whatever it might be.

 

In the next update we could add some text describing the alternatives to the
HTTP CONNECT based mechanism to promote further discussion at least we seem
to have some agreement that a solution is needed.

 

Regards

Andy

 

 

From: Simon Pietro Romano [mailto:[e-mail]] 
Sent: 20 May 2013 18:12
To: Hutton, Andrew
Cc: Lorenzo Miniero; Gustavo García; [e-mail]; [e-mail]
Subject: Re: [rtcweb] New Version Notification for
draft-chenxin-behave-turn-websocket-00.txt

 

I keep on thinking that the solution depicted in
http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt deserves
attention.

 

Simon

 

Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto:






Regarding the HTTP fallback and whether this could be adapted to be a TURN
over HTTP based solution then I think the same comments that were made on
the TURN over websockets apply. What are the benefits of creating a new
transport for TURN over what we can do using HTTP Connect as described in
http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-0
0.

Having said that I am really happy we are having this debate as we really
need to find a solution here that the browser vendors will implement so I
would really like to know which options they prefer.

I really hope we can get draft-hutton-rtcweb-nat-firewall-considerations
adopted and use it to document whatever the working group agrees on being
the right solution.

Regards
Andy






-----Original Message-----

From: Lorenzo Miniero [mailto:[e-mail]]

Sent: 20 May 2013 10:15

To: Gustavo García

Cc: Hutton, Andrew; [e-mail]; [e-mail]

Subject: Re: [rtcweb] New Version Notification for draft-chenxin-

behave-turn-websocket-00.txt

 

Il giorno Sun, 19 May 2013 23:20:41 -0700

Gustavo García <[e-mail]> ha scritto:

 

I agree that TURN over websockets doesn't solve much more scenarios

than TURN/TLS.   If trying to fix HTTP Proxy traversal why not doing

it over HTTP that aside of philosophical discussions would be the

solution with better success rate?  Otherwise we will have to

continue answering for another 10 years "why is this app not working

if skype does".

 

Something like this draft sent some months ago but perhaps for TURN

instead of direct connections:

http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt

 

 

 

When I submitted that draft this summer, I had that exact purpose in

mind, that is taking care of corner edge cases like restrictive proxies

and the like. Of course it was not meant to be a solution, just a way

to foster discussion in that direction. In that discussion I also

mentioned some work we did about this in the past, which in part

apparently ended up in draft-hutton-rtcweb-nat-firewall-considerations:

 

http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html

 

At the time most people in the ML thought it was either too useless,

too complex or even harmful, considering it could be considered as a

"sneaky" way to circumvent rules added by a network administrator, and

so unacceptable. Anyway, as I said back then, a solution like this

doesn't have to be sneaky, and it could very well be conceived in order

to be admin-friendly rather than have a parrot and a wooden leg.

 

Whether we actually need something like this or TURN-over-443 is enough

I don't know: I still think it may be useful to tackle scenarios where

everything else fails (the "skype works here" effect), so I'd be glad

to be of help in that direction if needed.

 

Lorenzo

 

 

 

On 16/05/2013, at 01:28, Hutton, Andrew wrote:

 

I agree with Bernard's comments regarding the impact of DPI but of

course such DPI devices do what they do and we can't and even don't

want to stop them from doing it. However for the case when policy

is such that the firewall will only allow traffic to traverse that

comes from the HTTP Proxy or a network specific TURN server and

there is no deliberate policy to block WebRTC media we need a

solution and this is what

draft-hutton-rtcweb-nat-firewall-considerations-00 addresses.

 

So far I don't see the benefit that TURN over websockets would have

in this scenario and it needs additional implementation in the

browser and the TURN server.

 

Regards

Andy

 

 

-----Original Message-----

From: Bernard Aboba [mailto:[e-mail]]

Sent: 15 May 2013 18:20

To: Hutton, Andrew; Chenxin (Xin); [e-mail];

[e-mail]

Subject: RE: [rtcweb] FW: New Version Notification for

draft-chenxin- behave-turn-websocket-00.txt

 

Andrew Hutton said:

When we wrote the draft http://tools.ietf.org/html/draft-hutton-

rtcweb-nat-firewall-considerations-00 we did not include this

option because we did not see the benefit of additional transport

options for TURN given that the existing options (E.g. TURN/TCP

and TURN/TLS) seem to be meet our needs.

 

So what would be the benefits that justify this addition

transport

option for TURN?

 

[BA] In my experience,  institutions with very restrictive

security

policies (e.g. those that don't allow UDP in or out) also tend to

deploy other measures such as deep packet inspection.   So just

because some traffic is allowed in or out on port 80 does not mean

that TURN/TCP will be allowed on that port - a DPI box may examine

the traffic and complain if it doesn't see HTTP being used.  On

the other hand, unless the DPI box is upgraded, it will also

complain about websockets.  So I think draft-chenxin only helps in

a situation where TURN over Websockets would be allowed when

TURN/TCP would not be.  That scenario is rare, at least at the

moment.

 

The argument for TURN over Websocket/TLS is even more difficult to

make. While DPI boxes may examine traffic destined to port 443

carefully to make sure that TLS is really being used,  assuming

that the DPI box does not see anything it considers fishy, the TLS

exchange will complete and the DPI box will lose visibility.

After TLS is running, the DPI box does not have much information

available to distinguish TURN/TLS from HTTP over TLS, with or

without websockets -- and those things it does have (such as

packet size) are as likely to result in an objection to websocket

transport as TURN/TLS.  So I'm not sure that draft-chenxin will

help in that situation either.

 

 

 

 

_______________________________________________

rtcweb mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/rtcweb

 

_______________________________________________

rtcweb mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/rtcweb


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

 

 
_\\|//_

                                                              ( O-O )

   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

                                                        Simon Pietro Romano

                                                Universita' di Napoli
Federico II

                                Computer Engineering Department 

                     Phone: [phone] -- Fax: [phone]

                                           e-mail: [e-mail]

 

                      <<Molti mi dicono che lo scoraggiamento Ë l'alibi
degli 

                      idioti. Ci rifletto un istante; e mi scoraggio>>.
Magritte.

                                                          oooO

  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

                                                                \ (
(   )

                                                             \_)          )
/

                                                                       (_/