Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Jan 2014 11:20:20 +0100

WG,

It has been quite some time since the WG last call ended and a new
revision was submitted. As Document Shepherd I want to push this
document to publication request.

Chenxin proposed below three different sets of changes to the document.
Does the WG support making these changes? Please indicate within the
next week if you support or want to reject these changes.

Thanks

Magnus

On 2013-10-17 12:23, Chenxin (Xin) wrote:
> Hi Andy,
> 
>  
> 
>   I think you means F29 not F27:). When I read it , I realize that there
> is cross and ambiguous between 3.3.2 and 3.3.3
> 
>  
> 
>   More details:
> 
>  
> 
>   The topic of 3.3.2 is "Simple Video Communication Service, *NAT/FW*
> that blocks UDP". But in the description and requirement, only *NAT* is
> considered.
> 
>   The topic of 3.3.3 is "Simple Video Communication Service, FW that
> only allows http", But only *http proxy* deployed scenarios is considered.
> 
>  
> 
>   There are other usecases " FW block UDP, incoming TCP, Http allowing
> FW without http proxy deplolyed under the permission of FW policy" ,
> which is lost in the description. If we need consider these usecases , I
> suggest to make some change to the description.
> 
>  
> 
>   Proposal 1 :
> 
>  
> 
>   add FW related words to section 3.3.2
> 
> -------------------------------------------------
> 
> 3.3.2.  Simple Video Communication Service, NAT/FW that blocks UDP
> 
>  
> 
> 3.3.2.1.  Description
> 
>  
> 
>    This use-case is almost identical to the Simple Video Communication
> 
>    Service use-case (Section 3.3.1).  The difference is that one of the
> 
>    users is behind a NAT*/FW* that blocks UDP traffic.
> 
> .
> 
>  
> 
> 3.3.2.2.  Additional Requirements
> 
>  
> 
>    F29     The browser must be able to send streams and
> 
>            data to a peer in the presence of NATs *and FWs* that
> 
>            block UDP traffic ,* when FW policy allows WebRTC traffic*.
> 
> -------------------------------------------------------
> 
>    Proposal 2: If the" Http allowing FW without http proxy deployed"
> case is impliedly included in F29. I suggest to change the topics of
> 3.3.3 to "Simple Video Communication Service, FW that only allows
> traffic via a http proxy". So the 3.3.3 is a specific case.
> 
>  
> 
>     Proposal 3: If " Http allowing FW without http proxy deployed" case
> need to be explicitly mentioned. I suggest to add some descriptions to 3.3.3
> 
> -----------------------------------------------------------------
> 
> 3.3.3.  Simple Video Communication Service, FW that only allows http
> 
>  
> 
> 3.3.3.1.  Description
> 
>  
> 
>    This use-case is almost identical to the Simple Video Communication
> 
>    Service use-case (Section 3.3.1).  The difference is that one of the
> 
>    users is behind a http allowing FW or a FW that only allows traffic
> via a HTTP Proxy.
> 
>  
> 
> 3.3.3.2.  Additional Requirements
> 
>  
> 
>    F37     The browser must be able to send streams and
> 
>            data to a peer in the presence of http allowing FWs or FWs
> that only
> 
>            allows traffic via a HTTP Proxy, when FW policy
> 
>            allows WebRTC traffic.
> 
> -------------------------------------------------------------------
> 
>  
> 
>  
> 
> Best Regards,
> 
>      Xin
> 
>  
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Jan 2014 11:34:18 +0100

Hi Partha,

I see this as an outstanding question on the use-cases document and I
want to resolve it prior to the publication request.

I want to check my understanding of the points you bring up. See below.

On 2013-10-20 18:35, Parthasarathi R wrote:
> Hi Xin & all,
> 
>  
> 
> Apart from modified F29 by Xin, the following requirement has to be
> discussed:
> 
> 1)      New requirement for blocking incoming TCP connection:
> 
> a.        The browser must be able to send streams and data to a peer in
> the presence of NATs and FWs that block UDP traffic and incoming TCP
> connection

So the point of this requirement would be to differentiate to the other
existing requirements that a NAT/FW combination may provide no UDP and
no support for incoming TCP. Thus, if one goes into solution space, you
need a proxy/relay solution where a peer can establish a point of
presence outside of the NAT/FW which is reachable over non-UDP, thus
assuming TCP as only alternative.

>From my perspective the combination of F2 and F29 implicitly demands the
support of a relay solution, and that it is unnecessary to add an
explicit requirement. This as the failure rate for incoming TCP
connections through any NAT is high irrespective of explicit blocking of
incoming TCP or not.

> 
> 2)      New requirement to cover both browsers are behind the firewall
> 
> a.         The browser must be able to send streams and data to a peer
> in the presence of NATs and FWs that block UDP traffic and incoming TCP
> connection  in both browser side as well as in the peer side (TURN only
> works)

I think this is unclear, as there are two aspects of this. The peers are
either behind different FW or the same FW/NAT. If it is the second, I
think this will simply work the same way two client on an non firewalled
network would work. At least ICE will find it. If it is the first, I
think that is implicitly included in F2.

Thus I question if there any utility in adding anything about this in
the use-case document.

WG, please contribute your views on this and if we need to make any
changes to the document in regards to this proposal.

Cheers

Magnus Westerlund

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 16 Jan 2014 14:18:19 +0000

Some comments in the text below.

As a general comment I suggest changing all the "FW" abbreviations to "Firewall" are have at least a first use definition.

Andy

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: 15 January 2014 10:20
> To: Chenxin (Xin); Hutton, Andrew; Christer Holmberg; Parthasarathi R;
> [email-masked]
> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-
> requirements-12
> 
> WG,
> 

[AndyH] - I support this change.

> >            block UDP traffic ,* when FW policy allows WebRTC

[AndyH] - I support this change.

[AndyH] Yes the heading of 3.3.3 should have been changed during the last edit to "Simple Video Communication Service, FW that only allows traffic via a HTTP Proxy". I support this change.

> >    users is behind a http allowing FW or a FW that only allows

[AndyH] I don't believe the intention here was to state a requirement that WebRTC media should be able to flow through a FW only allowing HTTP.  Therefore I think the original description is ok it is just the heading that needs to change. 

> >            allows traffic via a HTTP Proxy, when FW policy

[AndyH] The existing text is in the 012 draft is ok and I don't think this change is needed as again I don't believe the intention here was to state a requirement that WebRTC media should be able to flow through a FW only allowing HTTP.

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 18 Jan 2014 23:48:00 +0530

Hi Magnus,

I have trouble in the usage of TURN instead of media relay server in the
requirement document as TURN is the solution and not the requirement. 

ICE-TCP and TURN server are two different relay mechanism whenever browser
is not possible to transport the media in UDP. TURN server is good in case
of browser-to-browser scenario wherein ICE-TCP is preferred approach for
browser-to-webrtc gateway. The related mail thread is discussed in PNTAW as
http://www.ietf.org/mail-archive/web/pntaw/current/msg00185.html. So, I
preferred to have the separate requirement as discussed in this mail thread
which leads to the conclusion as part of PNTAW alias discussion. Please let
me know your opinion on the same.

Thanks
Partha

> Sent: Wednesday, January 15, 2014 4:04 PM
> To: Parthasarathi R; 'Chenxin (Xin)'; 'Hutton, Andrew'; 'Christer
> Holmberg'; [email-masked]
> in

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Jan 2014 10:59:04 +0100

Hi Partha,

> requirement document as TURN is the solution and not the requirement. 

Noted, I like to get more input from the WG if they think this should be
changed to use media relay.

> is not possible to transport the media in UDP.

My personal opinion is that the above is incorrect statement. I believe
you may be able to realize a higher layer gateway using ICE-TCP. But ICE
TCP per say is not a relay mechanism. To my understanding the core part
of ICE-TCP is the establishment of an end-to-end TCP connection between
the ICE agents. I also note that with our current transport stacks you
still need a framing on top of the TCP connection to realize the
datagrams that carries the RTP or DTLS packets.

 TURN server is good in case
> me know your opinion on the same.

I personally are uncertain if there exist any need for changing the
use-case and requirements draft. I would like to note the following text
in the use-case and requirements draft:

   This document was developed in an initial phase of the work with
   rather minor updates at later stages.  It has not really served as a
   tool in deciding features or scope for the WGs efforts so far.  It is
   proposed to be used in a later phase to evaluate the protocols and
   solutions developed by the WG.

So, I believe the basic NAT/FW requirement exist. It might be to
solution focused in its description. However, it is also clear that we
have a number of solution parts that exist beyond the requirements.

So, I still see need WG participants to provide feedback on this to
determine if there exist any consensus to modify the use-case document
or not.

Cheers

Magnus Westerlund

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 20 Jan 2014 14:22:37 +0000

I also don't see a need to change the existing text as I believe the required use cases are covered even if the descriptions makes some assumptions about the solutions.  

It maybe that it is not the best requirements language but the assumptions are reasonable and I don't see the need to change the text at this stage unless we are missing an important requirement.

Regards
Andy

> Sent: 20 January 2014 09:59
> To: Parthasarathi R; 'Chenxin (Xin)'; Hutton, Andrew; 'Christer

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 23 Jan 2014 04:48:31 +0530

I support Chenxin proposal.

> Sent: Wednesday, January 15, 2014 3:50 PM

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Jan 2014 10:01:54 +0100

Authors,

I have seen only support for this change. Please introduce it and also
perform the editorial change FW -> Firewall in the text.

Cheers

Magnus

-- 

Magnus Westerlund