Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 7 Jan 2015 06:47:39 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Aijun Wang
> Sent: Wednesday, January 07, 2015 11:09 AM
> To: Tirumaleswar Reddy (tireddy); 'Brandon Williams'; Pal Martinsen
> (palmarti)
> Cc: 'Simon Perreault'; [email-masked]; 'Varun Singh'
> Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-
> data-00.txt
> 
> Hi, Reddy,
> 
> Please see the reply inline.
> 
> Best Regards.
> 
> > -----Original Message-----
> > From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> > Sent: Tuesday, January 06, 2015 8:20 PM
> > To: Aijun Wang; 'Brandon Williams'; Pal Martinsen (palmarti)
> > Cc: 'Simon Perreault'; [email-masked]; 'Varun Singh'
> > Subject: RE: [tram] New Version Notification for
> > draft-reddy-tram-stun-path-data-00.txt
> >
> > > -----Original Message-----
> > > From: tram [mailto:[email-masked]] On Behalf Of Aijun Wang
> > > Sent: Tuesday, January 06, 2015 9:13 AM
> > > To: 'Brandon Williams'; Pal Martinsen (palmarti); Tirumaleswar Reddy
> > > (tireddy)
> > > Cc: 'Simon Perreault'; [email-masked]; 'Varun Singh'
> > > Subject: Re: [tram] New Version Notification for
> > > draft-reddy-tram-stun-path- data-00.txt
> > >
> > > Hi, All:
> > >
> > > The draft that given by Reddy illustrating some drawback of the
> > > current ICE solution(RFC5245), and actually provided another
> > > possible solution to improve it.
> >
> > ICE regular and aggressive nomination have certain drawbacks which
> > will be dealt as part of ICE continuous nomination work in mmusic WG,
> > ICE algorithm changes will not be covered in this draft. Note that
> > this draft can also be used with regular ICE when there is no
> > noticeable impact in setting up the media session,  It depends on the
> > number of candidate pairs, time interval for pacing ICE connectivity checks
> and RTO values.
> >
> > > I agree also that it is necessary for ICE to check connectivity
> > > continuously, but still hesitate to agree add more additional
> > > function to its role(such as RTT, loss rate, pathmtu etc.).
> >
> > Why ?
> 
> The functions for detecting RTT, loss rate etc. are useful but not reliable and
> deterministic. 

It depends if the checks are done once or periodically.
 
> Can you assure the applications that relied on them will be
> more efficiency and reliable? I prefer to putting all usable interfaces into a
> pool(via ICE continuously checking proposal) and give more flexibility to the
> application. More detections and decision can be made by the upper layer,
> not the ICE itself.

The decision need not be made by ICE, it can expose path metrics like RTT, packet loss to the upper layer.

> There are other large questions for the connectivity, for example, the NAT
> punching for the BEHAVE-compliant NAT devices and non BEHAVE-compliant
> NAT devices, the selection of appropriate TURN server when the TURN server
> are distributed deployed, the communication between IPv4 endpoint,
> IPv4/IPv6 endpoint and IPv6 endpoint etc. I think ICE should focus more on
> the solution of these challenges.

ICE already addresses NAT and connectivity problems b/w endpoints with different IP address families.

> 
> > Periodic ICE connectivity checks for media streams for consent
> > freshness is already covered in
> > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-11
> >
> I was also curious that how this problem that mentioned in this draft is
> raised. If the corresponding endpoint doesn't want to receive the data from
> other endpoint, it need just close the TCP/UDP session that built by ICE
> process, why should we use the consent freshness check?

Consent freshness will help the endpoint determine if the remote peer is interested in receiving the traffic or not.

-Tiru

> 
> > >
> > > The better solution may be to check the connectivity continuously,
> > > especially for the newly up interface, but only limited to the
> > > connectivity
> > characteristic.
> > > The application layer should balance among these available
> > > interfaces that given by ICE, using their own RTT, loss rate
> > > detection and path-mtu finding solution. This can also reduce the
> > > latency of interface switching of the endpoint.
> >
> > ICE continuous nomination allows checks on new interfaces and the path
> > characteristics discovered using ICE can be used to switch-over the
> > media stream to a new interface. It is discussed in
> > http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.ht
> > ml#se
> > ction-3.1
> >
> > -Tiru
> >
> > >
> > > Best Regards.
> > > Aijun Wang.
> > >
> > > > -----Original Message-----
> > > > From: Brandon Williams [mailto:[email-masked]]
> > > > Sent: Tuesday, January 06, 2015 7:09 AM
> > > > To: Pal Martinsen (palmarti); Tirumaleswar Reddy (tireddy)
> > > > Cc: Aijun Wang; Varun Singh; Simon Perreault; [email-masked]
> > > > Subject: Re: [tram] New Version Notification for
> > > > draft-reddy-tram-stun-path-data-00.txt
> > > >
> > > > Hi Pål-Erik,
> > > >
> > > > You wrote: Down play ICE usage. Focus on what a TRAM drafts should
> > > focus on.
> > > > (In this case provide RTT and loss information)
> > > >
> > > > I'm not certain exactly what you're looking for in the text. I
> > > > don't really see a meaningful use case for the RTT and loss stats
> > > > outside of the end-to-end context of the ICE use case, since using
> > > > partial path stats for decision making will often generate bad
> > > > results. Do you see a use case other than ICE? Or are you simply
> > > > suggesting that the draft should avoid referencing a specific use case
> altogether?
> > > >
> > > > Thanks,
> > > > --Brandon
> > > >
> > > >
> > > > On 01/05/2015 04:01 AM, Pal Martinsen (palmarti) wrote:
> > > > >
> > > > >> On 05 Jan 2015, at 08:27, Tirumaleswar Reddy (tireddy)
> > > > >> <[email-masked] <mailto:[email-masked]>> wrote:
> > > > >>
> > > > >>> -----Original Message-----
> > > > >>> From: tram [mailto:[email-masked]] On Behalf Of Aijun
> > > > >>> Wang
> > > > >>> Sent: Sunday, January 04, 2015 6:12 AM
> > > > >>> To: 'Varun Singh'; Tirumaleswar Reddy (tireddy)
> > > > >>> Cc: 'Simon Perreault'; [email-masked] <mailto:[email-masked]>;
> > > > >>> 'Brandon Williams'
> > > > >>> Subject: Re: [tram] FW: New Version Notification for
> > > > >>> draft-reddy-tram-stun-
> > > > >>> path-data-00.txt
> > > > >>>
> > > > >>> Hi, Singh, Reddy and Simon:
> > > > >>>
> > > > >>> I admitted that the path characteristic can be one factor to
> > > > >>> be considered and can be used to assist the endpoints to
> > > > >>> select the appropriate path. The main point of this value that
> > > > >>> different from other criteria defined in RFC5245 is that this
> > > > >>> value will be changed dynamically and is not determined.
> > > > >>> Consider the ICE connectivity check will be only done once for
> > > > >>> one communication session, is it appropriate for it to rely on
> > > > >>> one unreliable value to make the decision?
> > > > >>
> > > > >> No, consent freshness and ICE continuous nomination explain
> > > > >> that ICE connectivity checks happen even after candidates are
> > > > >> nominated for the media session. An interface can be picked
> > > > >> based on the current path characteristics, continue with ICE
> > > > >> checks on other interfaces or new interfaces discovered later
> > > > >> and switch-over when a better candidate pair is available.  For
> > > > >> more information refer to the discussion in mmusic WG
> > > > >> (http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-
> nombis.
> > > > >> html)
> > > > >
> > > > > I do agree with Aijuns point that RFC5245 limits the usability
> > > > > of this draft. But as you point out there is a lot of
> > > > > discussions going on regarding how we can improve ICE, not all
> > > > > of those discussions are well known. To catch up, reading the
> > > > > MMUSIC mailing-list is probably a good
> > > > idea.
> > > > >
> > > > > To make it easier to read the draft I would propose to do the
> > > > > following in the next version.
> > > > >
> > > > > - Rename draft to “RTT and loss measurements of STUN
> Transactions”.
> > > > > Path characteristics seems to hint that other things like
> > > > > bandwidth and so on is also included.
> > > > > - Down play ICE usage. Focus on what a TRAM drafts should focus on.
> > > > > (In this case provide RTT and loss information)
> > > > >
> > > > >
> > > > > The DISCUSS draft
> > > > > (http://tools.ietf.org/id/draft-martinsen-tram-discuss-01.txt)
> > > > > also have the ability to provide useful information, but it
> > > > > requires support from the network to achieve this.
> > > > >
> > > > >
> > > > >>
> > > > >>> What would you do if it select one idle pair at first but it
> > > > >>> become congest later?
> > > > >>>
> > > > >>> I think the dynamic path selection should be left to and be
> > > > >>> considered by the application layer itself, such as RTCP
> > > > >>> protocol etc.
> > > > >>
> > > > >> In case of MPRTP,  Path characteristics discovered using ICE
> > > > >> will be used for picking the interface for the primary sub-flow
> > > > >> and interfaces for subsequent sub-flows and MPRTP RTCP report
> > > > >> can be used later for load balancing.
> > > > >>
> > > > >
> > > > > A short summary of my understanding of the MMUSIC ICE discussions
> is:
> > > > > - Use ICE to build a valid list
> > > > > - Redefined how we use that valid list. (Keeping pairs warm so
> > > > > we can switch to them fast ++)
> > > > > - Redefine when and how we chose an active candidate pair to
> > > > > send media
> > > > on.
> > > > >
> > > > > .-.
> > > > > Pål-Erik
> > > > >
> > > > >> -Tiru
> > > > >>
> > > > >>>
> > > > >>> Best Regards.
> > > > >>>
> > > > >>>> -----Original Message-----
> > > > >>>> From: Varun Singh [mailto:[email-masked]]
> > > > >>>> Sent: Wednesday, December 31, 2014 7:50 PM
> > > > >>>> To: Tirumaleswar Reddy (tireddy)
> > > > >>>> Cc: Simon Perreault; Brandon Williams; [email-masked]
> > > > >>>> <mailto:[email-masked]>; Aijun Wang
> > > > >>>> Subject: Re: [tram] FW: New Version Notification for
> > > > >>>> draft-reddy-tram-stun-path-data-00.txt
> > > > >>>>
> > > > >>>> On Wed, Dec 31, 2014 at 8:19 AM, Tirumaleswar Reddy (tireddy)
> > > > >>>> <[email-masked] <mailto:[email-masked]>> wrote:
> > > > >>>>> Inline [TR]
> > > > >>>>> On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams
> > > > >>>>> <[email-masked]
> > > > <mailto:[email-masked]>>
> > > > >>>>> wrote:
> > > > >>>>>
> > > > >>>>> You are correct that the currently published RFC makes the
> > > > >>>>> path quality information harder to use in a meaningful way.
> > > > >>>>> However, there is ongoing work in both tram and mmusic
> > > > >>>>> focused on allowing more dynamic path selection that can use
> > > > >>>>> performance metrics rather than the currently defined static
> > priorities.
> > > > >>>>> This draft is just one piece of that
> > > > >>>> bigger picture.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> You're right, of course, but if there's no way to make
> > > > >>>>> practical use of this draft with regular ICE, then that's
> > > > >>>>> useful information that needs to go into the draft. Ideally
> > > > >>>>> with pointers to the bigger picture you
> > > > >>>> mentioned.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> [TR] we will update the introduction section to make it clear.
> > > > >>>>> This draft can be used with regular ICE when there is no
> > > > >>>>> noticeable impact in setting up the media session. It
> > > > >>>>> depends on the number of candidate pairs, time interval (Ta)
> > > > >>>>> for pacing ICE connectivity checks and
> > > > >>> RTO values.
> > > > >>>>>
> > > > >>>>
> > > > >>>> True. Path characteristics can be used in addition to the
> > > > >>>> proprietary criteria the endpoint currently implements. i.e.,
> > > > >>>> if the endpoints wants to stop checking because it met its
> > > > >>>> defined criteria and was using the path characteristics as
> > > > >>>> part of the STUN messages, it could still use the path
> > > > >>>> characteristics for those candidates to make further
> > > > >>> decisions.
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> http://www.netlab.tkk.fi/~varun/
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> tram mailing list
> > > > >>> [email-masked] <mailto:[email-masked]>
> > > > >>> https://www.ietf.org/mailman/listinfo/tram
> > > > >>
> > > > >> _______________________________________________
> > > > >> tram mailing list
> > > > >> [email-masked] <mailto:[email-masked]>
> > > > >> https://www.ietf.org/mailman/listinfo/tram
> > > > >
> > > >
> > > > --
> > > > Brandon Williams; Senior Principal Software Engineer Emerging
> > > > Products Engineering; Akamai Technologies Inc.
> > >
> > >
> > >
> > > _______________________________________________
> > > tram mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/tram
> 
> 
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 7 Jan 2015 17:36:23 +0800

Hi, Reddy:

Please see the reply inline below.

> From: tram [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy
> (tireddy)
> Sent: Wednesday, January 07, 2015 2:48 PM
> > > will be dealt as part of ICE continuous nomination work in mmusic
> > > WG, ICE algorithm changes will not be covered in this draft. Note
> > > that this draft can also be used with regular ICE when there is no
> > > noticeable impact in setting up the media session,  It depends on
> > > the number of candidate pairs, time interval for pacing ICE
> > > connectivity checks
> > and RTO values.
> > >
> > The functions for detecting RTT, loss rate etc. are useful but not
> > reliable and deterministic.
> 
【Aijun】: Even the check is periodical, its result will be influenced by the traffic of the application data itself.  I can give you another example that the path characteristic is valuable in theory but not used in practice: IGP protocol such as OSPF considers its metric value from Bandwidth, delay, reliability and loading value, but actually use only Bandwidth.  Will path-characteristic check try this again?

> 
> > Can you assure the applications that relied on them will be more
> > efficiency and reliable? I prefer to putting all usable interfaces
> > into a pool(via ICE continuously checking proposal) and give more
> > flexibility to the application. More detections and decision can be
> > made by the upper layer, not the ICE itself.
> 

【Aijun】: The upper layer can get such information via its data sending and responding naturally in real time.
> 
> 
> > There are other large questions for the connectivity, for example, the
> > NAT punching for the BEHAVE-compliant NAT devices and non
> > BEHAVE-compliant NAT devices, the selection of appropriate TURN server
> > when the TURN server are distributed deployed, the communication
> > between IPv4 endpoint,
> > IPv4/IPv6 endpoint and IPv6 endpoint etc. I think ICE should focus
> > more on the solution of these challenges.
> 

【Aijun】: 1. Does current ICE consider the communication scenarios that one IPv4-only endpoint wants to talks to one IPv6-only endpoint? 
         2. Can ICE solve the TCP-NAT traversal in BEHAVE-compliant NAT environment in one determined manner, not the possible success rate via trying every pair of check list?
         3. Does ICE mention how to make sure the relayed packet to pass through the non-BEHAVE-compliant NAT device? Especially for TCP protocol?
> > I was also curious that how this problem that mentioned in this draft
> > is raised. If the corresponding endpoint doesn't want to receive the
> > data from other endpoint, it need just close the TCP/UDP session that
> > built by ICE process, why should we use the consent freshness check?
> 
> Consent freshness will help the endpoint determine if the remote peer is
> interested in receiving the traffic or not.

【Aijun】: There is other system to make this decision. For example, If I want to talk to you via Skype, I should first find you in my Skype contact list, and make a call to you. If you accept the call, the ICE process for data transfer then begin. If you drop the call, the ICE process will be terminated. ICE itself needs not do the consent check.
> > > ICE continuous nomination allows checks on new interfaces and the
> > > path characteristics discovered using ICE can be used to switch-over
> > > the media stream to a new interface. It is discussed in
> > > > > don't really see a meaningful use case for the RTT and loss
> > > > > stats outside of the end-to-end context of the ICE use case,
> > > > > since using partial path stats for decision making will often
> > > > > generate bad results. Do you see a use case other than ICE? Or
> > > > > are you simply suggesting that the draft should avoid
> > > > > referencing a specific use case
> > altogether?
> > > > >
> > > > > Thanks,
> > > > > --Brandon
> > > > >
> > > > >
> > > > > >>> select the appropriate path. The main point of this value
> > > > > >>> that different from other criteria defined in RFC5245 is
> > > > > >>> that this value will be changed dynamically and is not determined.
> > > > > >>> Consider the ICE connectivity check will be only done once
> > > > > >>> for one communication session, is it appropriate for it to
> > > > > >>> rely on one unreliable value to make the decision?
> > > > > >>
> > > > > >> and switch-over when a better candidate pair is available.
> > > > > >> For more information refer to the discussion in mmusic WG
> > > > > >> will be used for picking the interface for the primary
> > > > > >> sub-flow and interfaces for subsequent sub-flows and MPRTP
> > > > > >> RTCP report can be used later for load balancing.
> > > > > >>
> > > > > >
> > > > > >>>> On Wed, Dec 31, 2014 at 8:19 AM, Tirumaleswar Reddy
> > > > > >>>> (tireddy) <[email-masked] <mailto:[email-masked]>>
> wrote:
> > > > > >>>>> Inline [TR]
> > > > > >>>>> focused on allowing more dynamic path selection that can
> > > > > >>>>> use performance metrics rather than the currently defined
> > > > > >>>>> static
> > > priorities.
> > > > > >>>>> useful information that needs to go into the draft.
> > > > > >>>>> Ideally with pointers to the bigger picture you
> > > > > >>>> mentioned.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> depends on the number of candidate pairs, time interval
> > > > > >>>>> (Ta) for pacing ICE connectivity checks and
> > > > > >>> RTO values.
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>> proprietary criteria the endpoint currently implements.
> > > > > >>>> i.e., if the endpoints wants to stop checking because it
> > > > > >>>> met its defined criteria and was using the path
> > > > > >>>> characteristics as part of the STUN messages, it could
> > > > > >>>> still use the path characteristics for those candidates to
> > > > > >>>> make further
> > > > > >>> decisions.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> --

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 7 Jan 2015 11:14:59 +0000

> Sent: Wednesday, January 07, 2015 3:06 PM
> 【Aijun】: Even the check is periodical, its result will be influenced by the
> traffic of the application data itself.  I can give you another example that the
> path characteristic is valuable in theory but not used in practice: IGP protocol
> such as OSPF considers its metric value from Bandwidth, delay, reliability and
> loading value, but actually use only Bandwidth.  Will path-characteristic check
> try this again?
> 
> >

ICE can helps get metrics before data is sent.

> 【Aijun】: 1. Does current ICE consider the communication scenarios that
> one IPv4-only endpoint wants to talks to one IPv6-only endpoint?
>          2. Can ICE solve the TCP-NAT traversal in BEHAVE-compliant NAT
> environment in one determined manner, not the possible success rate via
> trying every pair of check list?
>          3. Does ICE mention how to make sure the relayed packet to pass
> through the non-BEHAVE-compliant NAT device? Especially for TCP protocol?

ICE can establish communication b/w peers in all the above scenarios. 
TCP candidates with ICE is explained in RFC 6544.

> 【Aijun】: There is other system to make this decision. For example, If I want
> to talk to you via Skype, I should first find you in my Skype contact list, and
> make a call to you. If you accept the call, the ICE process for data transfer
> then begin. If you drop the call, the ICE process will be terminated. ICE itself
> needs not do the consent check.

You may want to go through the discussions in rtcweb WG to understand the reason for consent freshness.

-Tiru

---

From: Simon Perreault <[email-masked]>
Date: Wed, 7 Jan 2015 09:22:02 -0500

On Wed, Jan 7, 2015 at 4:36 AM, Aijun Wang <[email-masked]>
wrote:

> > The decision need not be made by ICE, it can expose path metrics like
> RTT,
> > packet loss to the upper layer.
>

But how would that work? Assuming the upper layer is RTP, and you want to
modify it so that it measures path RTTs. Wouldn't that enhanced RTP upper
layer then make use of this draft to make its measurements? What
alternative are you concretely proposing?

> 【Aijun】: 1. Does current ICE consider the communication scenarios that one
> IPv4-only endpoint wants to talks to one IPv6-only endpoint?
>

Yes. [RFC6156]

> trying every pair of check list?

I don't understand what you mean. If the NAT is BEHAVE-compliant, then ICE
will pick the STUN candidate. What is missing?

> through the non-BEHAVE-compliant NAT device? Especially for TCP protocol?

I don't understand what you mean. Can you be more specific? Perhaps
illustrate with an example?

> 【Aijun】: There is other system to make this decision. For example, If I
> want to talk to you via Skype, I should first find you in my Skype contact
> list, and make a call to you. If you accept the call, the ICE process for
> data transfer then begin. If you drop the call, the ICE process will be
> terminated. ICE itself needs not do the consent check.

Here's a tip...

You obviously don't understand why consent checks are needed. Fine. Maybe
we're all wrong and consent checks are not needed. But instead of asking
questions you try to argue. Not fine. If you ask questions we can try to
help you understand, and if we're all wrong our answers will make it
obvious to everyone. If instead you try to argue I'm afraid you will just
get ignored.

Ask more, assert less.

Simon

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 8 Jan 2015 14:14:10 +0800

From: Simon Perreault [mailto:[email-masked]] 
Sent: Wednesday, January 07, 2015 10:22 PM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); Brandon Williams; Pal Martinsen (palmarti); [email-masked]; Varun Singh
Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt

But how would that work? Assuming the upper layer is RTP, and you want to modify it so that it measures path RTTs. Wouldn't that enhanced RTP upper layer then make use of this draft to make its measurements? What alternative are you concretely proposing?

[Aiiun] RFC3550 for RTP has the following description:

The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.

And the Sender Report RTCP Packet and Receiver Report RTCP Packet that described in section 6.4.1 and 6.4.2 of this RFC illustrate the detail information that can be gathered by RTCP. Is it sufficient enough for RTP upper layer?

Yes. [RFC6156]

[Aijun]: The function that described in RFC6156 for packet translation is needed for IPv4-Only host to communicate with IPv6-Only host, but the procedure should be re-clarified. For example, when will the endpoint send the “Allocate Request” that includes “REQUSTED-ADDRESS-FAMILY” attribute to require one relay address different from its supported address type?  

There is also other issue for the specific relay address when the endpoint is behind endpoint-dependent NAT. I will give one example below.

I don't understand what you mean. If the NAT is BEHAVE-compliant, then ICE will pick the STUN candidate. What is missing?

[Aijun]: http://tools.ietf.org/html/rfc6544#appendix-A “Limitations of ICE TCP” give more detail description that related to the above two questions. RFC6544 gives only the simultaneous-open solution for TCP NAT transversal, but its success rate is not 100%, even under the BEHAVE-compliant environment.

I don't understand what you mean. Can you be more specific? Perhaps illustrate with an example?

[Aijun]: Here is one example:

1. Suppose Host A and Host B are all behind EDM type NAT(Endpoint Dependent Map NAT, also non-BEHAVE compliant NAT) devices, that Host A is behind NAT-A, and Host B is behind NAT-B

2. Host A and Host B all send the “Allocation Request” to the TURN server’s well-known address, to get its relayed address respectively. At the same time, they all punch one TCP hole at NAT-A and NAT-B, but this TCP hole will only receive the packet from the TURN server’s well-known transport address, this is the behavior of EDM type NAT.

3. when Host A send data traffic to Host B, via the TURN server.  The TURN server will change the packet source address to Host A’s relay address, which is allocated in step 2. Because the packet’s source address did not match any NAT table item in NAT-B, this packet will be discard in silence.

4. Did current ICE notice this? This is same as the UDP transport, but TCP transport maybe more complex. 

Here's a tip...

You obviously don't understand why consent checks are needed. Fine. Maybe we're all wrong and consent checks are not needed. But instead of asking questions you try to argue. Not fine. If you ask questions we can try to help you understand, and if we're all wrong our answers will make it obvious to everyone. If instead you try to argue I'm afraid you will just get ignored.

[Aijun]: Ok. I am trying to catch up with all the relevant discussion. Currently, I read only http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-11 and there is little background introduction for the consent fresh check.  I personally think the consent check should be controlled also by the application layer, not the ICE protocol, which is one basic connectivity check protocol, and may be used by various application, even for that does not require the consent check.

Ask more, assert less.

[Aijun]: Ok, thanks for your advices and all kind attitude of this group, I just want to the TURN/ICE protocol more robust and more efficient. We have implemented one system that cover all the scenarios that mentioned in TURN/ICE related scenarios, but use some different procedures described in current related RFC/Draft.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 8 Jan 2015 10:14:49 -0500

On Thu, Jan 8, 2015 at 1:14 AM, Aijun Wang <[email-masked]>
wrote:
> The data transport is augmented by a control protocol (RTCP) to allow
> monitoring of the data delivery in a manner scalable to large multicast
> networks, and to provide minimal control and identification functionality.
>
>
>
> And the Sender Report RTCP Packet and Receiver Report RTCP Packet that
> described in section 6.4.1 and 6.4.2 of this RFC illustrate the detail
> information that can be gathered by RTCP. Is it sufficient enough for RTP
> upper layer?
>

In general no, it's not sufficient. Off the top of my head:

- You need the special flavour of RTP that multiplexes RTP and RTCP on the
same 5-tuple.
- You need the special flavour of RTP, MPRTP, that could work with multiple
paths simultaneously.

Now, consider other upper-layer protocols that would need to implement that
additional functionality as well. Why wouldn't it make sense that ICE
provide this service for them?

> [Aijun]: The function that described in RFC6156 for packet translation is
> needed for IPv4-Only host to communicate with IPv6-Only host, but the
> procedure should be re-clarified. For example, when will the endpoint send
> the “Allocate Request” that includes “REQUSTED-ADDRESS-FAMILY” attribute to
> require one relay address different from its supported address type?
>

An ICE node should always gather both IPv4 and IPv6 relayed candidates.

See also:
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.2
https://tools.ietf.org/html/rfc6157#section-4

> [Aijun]: http://tools.ietf.org/html/rfc6544#appendix-A “Limitations of
> ICE TCP” give more detail description that related to the above two
> questions. RFC6544 gives only the simultaneous-open solution for TCP NAT
> transversal, but its success rate is not 100%, even under the
> BEHAVE-compliant environment.
>

How is that well-known limitation problematic?

> 1. Suppose Host A and Host B are all behind EDM type NAT(Endpoint
> Dependent Map NAT, also non-BEHAVE compliant NAT) devices, that Host A is
> behind NAT-A, and Host B is behind NAT-B
>
> 2. Host A and Host B all send the “Allocation Request” to the TURN
> server’s well-known address, to get its relayed address respectively. At
> the same time, they all punch one TCP hole at NAT-A and NAT-B, but this TCP
> hole will only receive the packet from the TURN server’s well-known
> transport address, this is the behavior of EDM type NAT.
>
> 3. when Host A send data traffic to Host B, via the TURN server.  The TURN
> server will change the packet source address to Host A’s relay address,
> which is allocated in step 2.
>

That's not what will happen. There are two allocations on the same server.
Conceptually, the packets will loopback from the first allocation's relayed
address to the second allocation's relayed address, and will then be sent
to host B over the same 5-tuple that host B initially used to send its
allocate request.

A server can also notice when two allocations are talking to each other and
apply hairpinning optimization and avoid looping back real packets.

> Because the packet’s source address did not match any NAT table item in
> NAT-B, this packet will be discard in silence.
>

It's exactly the same for TURN-TCP, except that a separate data connection
is used.

Simon

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 9 Jan 2015 09:55:42 +0800

Hi, Simon,

Please see again the reply below.

From: Simon Perreault [mailto:[email-masked]] 
Sent: Thursday, January 08, 2015 11:15 PM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); Brandon Williams; Pal Martinsen (palmarti); [email-masked]; Varun Singh
Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt

On Thu, Jan 8, 2015 at 1:14 AM, Aijun Wang <[email-masked]> wrote:

- You need the special flavour of RTP that multiplexes RTP and RTCP on the same 5-tuple.

[Aijun]: RTP and RTCP use the different 5-tuple, please see RFC3550, section 11, that is described as below:

……RTP relies on the underlying protocol(s) to provide demultiplexing of

   RTP data and RTCP control streams.  For UDP and similar protocols,

   RTP SHOULD use an even destination port number and the corresponding

   RTCP stream SHOULD use the next higher (odd) destination port number……

- You need the special flavour of RTP, MPRTP, that could work with multiple paths simultaneously.

[Aijun]: As Reddy pointed out in previous mail, the original purpose for the path characteristic detection is to utilize the multipath of the available interfaces, so is this one extra requirement?

Now, consider other upper-layer protocols that would need to implement that additional functionality as well. Why wouldn't it make sense that ICE provide this service for them?

[Aijun]: Except RTP, which other upper-layer protocols will use this path characteristic then?  Even if it may be used by other on-coming protocol, I suggest this information should be gathered by the network operator and feedback them to the APP provider, as the work done by ALTO group. 

Yes. [RFC6156]

See also:

[Aijun]: There is no detail description in these sections to answer the above question. It mentioned only “should”, but not “when”.  Specially, in https://tools.ietf.org/html/rfc6157#section-4, it describes as below:

A direct offer/answer exchange between an IPv4-only user agent and an

   IPv6-only user agent does not result in the establishment of a

  session.  The IPv6-only user agent wishes to receive media on one or

   more IPv6 addresses, but the IPv4-only user agent cannot send media

   to these addresses, and generally does not even understand their

   format.  Consequently, user agents need a means to obtain both IPv4

   and IPv6 addresses to receive media and to place them in offers and

   answers.

so, where is the procedures to accomplish the communication task between the IPv4-Only node and IPv6-Only node?

[Aijun]: There are methods to assure the 100% success of TCP NAT transverse under BEHAVE-compliant NAT environment.  ICE does not solve it, this is the problematic.

3. when Host A send data traffic to Host B, via the TURN server.  The TURN server will change the packet source address to Host A’s relay address, which is allocated in step 2.

That's not what will happen. There are two allocations on the same server. Conceptually, the packets will loopback from the first allocation's relayed address to the second allocation's relayed address, and will then be sent to host B over the same 5-tuple that host B initially used to send its allocate request.

A server can also notice when two allocations are talking to each other and apply hairpinning optimization and avoid looping back real packets.

[Aijun]: No. There is only one allocation on TURN server for each client. Actually, there are two address in TURN server, one is the “Relayed Transport Address” for every client, the other is “TURN Server Transport Address” that is same to every client. (please refer to  the figure 1 in http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-2 )

For data sending process, please refer to http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-16, that described as below:

The client now sends a ChannelData message to the server with data

   destined for Peer B.  The ChannelData message is not a STUN message,

   and thus has no transaction id.  Instead, it has only three fields: a

   channel number, data, and data length; here the channel number field

   is 0x4000 (the channel the client just bound to Peer B).  When the

   server receives the ChannelData message, it checks that the channel

   is currently bound (which it is) and then sends the data onward to

   Peer B in a UDP datagram, using the relayed transport address as the

   source transport address and 192.0.2.210:49191 (the value of the XOR-

   PEER-ADDRESS attribute in the ChannelBind request) as the destination

   transport address. 

It described clearly the “relayed transport address” is used as the source transport address, not the address that the host B send the allocate request. So is it problematic?

Because the packet’s source address did not match any NAT table item in NAT-B, this packet will be discard in silence.

It's exactly the same for TURN-TCP, except that a separate data connection is used.

Simon