Subject: [BEHAVE] STUN relay with push mode QoS reservation

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 5 Jul 2007 20:59:44 -0400

I was trying to figure out how to merge STUN relay with push mode QoS
reservation. In this model, QoS reservation is triggered from network
rather than the UA.

Consider the following scenario:

+----+      +-----+                     +------+
|    |      |     |                     |      |
| UA1+------+ NAT +---------------------+  AF  -------+
|    |xxxxxx|     |                     |      |      |
+----+      +-----+                     +---"--+      |
               x(IP1)                       "         |
               x        +--------+          "      +--+-+
               x        |  STUN  |          "      |    |
               x        |  Relay |xxxxxxxxxxxxxxxxx| UA2|
               x        |        |(IP3)     " (IP4)|    |
               x        +--------+          "      +----+
               x          x(IP2)            "
            +-----+       x             +---"--+
            |     |xxxxxxxx             |      |
            | PEF |                     | PDF  |
            |     """""""""""""""""""""""      |
            +-----+                     +------+

    --- Call Signaling (SIP/SDP)

    """ QoS Signaling (Diameter QoS application)

    xxx Media

    AF  Application Function (Proxy, Application Server,
                              P-CSCF etc...)

    PDF Policy Decision Function

    PEF Policy Enforcement Function (Router, CMTS etc..)

UA1 uses IP3 in the SDP, and UA2 will use IP4. These addresses are
visible to AF (because it is on the SIP signaling path), and it will use
that information while reserving QoS for that particular session.

The problem is PEF needs to know IP1 and IP2 but will get IP3 and IP4.
STUN relay knows the binding between IP1/IP2 and IP3/IP4. This makes me
think whether it would make sense to have a STUN mechanism so that
trusted external entities can query STUN relay about the bindings. 

    Thanks,
    Tolga

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 6 Jul 2007 12:59:52 -0700

Hi.

The rel-addr and rel-port attributes are intended to solve 
that very problem, and is described in appendix B.3 of 
draft-ietf-mmusic-ice-16.  Please let Jonathan know if that 
mechanism is insufficient, as I believe he is working to 
get -17 submitted.  Here is the text of that appendix for
your reference:

    B.3.  Purpose of the <rel-addr> and <rel-port> Attributes
 
    The candidate attribute contains two values that are not used at all
    by ICE itself - <rel-addr> and <rel-port>.  Why is it present?
 
    There are two motivations for its inclusion.  The first is
    diagnostic.  It is very useful to know the relationship between the
    different types of candidates.  By including it, an agent can know
    which relayed candidate is associated with which reflexive candidate,
    which in turn is associated with a specific host candidate.  When
    checks for one candidate succeed and not the others, this provides
    useful diagnostics on what is going on in the network.
 
    The second reason has to do with off-path Quality of Service (QoS)
    mechanisms.  When ICE is used in environments such as PacketCable
    2.0, proxies will, in addition to performing normal SIP operations,
    inspect the SDP in SIP messages, and extract the IP address and port
    for media traffic.  They can then interact, through policy servers,
    with access routers in the network, to establish guaranteed QoS for
    the media flows.  This QoS is provided by classifying the RTP traffic
    based on 5-tuple, and then providing it a guaranteed rate, or marking
    its Diffserv codepoints appropriately.  When a residential NAT is
    present, and a relayed candidate gets selected for media, this
    relayed candidate will be a transport address on an actual STUN
    relay.  That address says nothing about the actual transport address
    in the access router that would be used to classify packets for QoS
    treatment.  Rather, the server reflexive candidate towards that relay
    is needed.  By carrying the translation in the SDP, the proxy can use
    that transport address to request QoS from the access router.

-d

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 9 Jul 2007 14:42:52 -0400

Thanks a lot for the information.

I still have a couple of questions and am probably missing some
important points regarding this issue:

a) How does a proxy learn about the result of the ICE selection?

b) AFAIU, rel-addr/rel-port will give information about server reflexive
candidate. How can proxy learn about the inside address of the STUN
relay (IP2 in the below figure)?

c) What if STUN relay is used but no ICE?

   Thanks,
   Tolga

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Friday, July 06, 2007 4:00 PM
> To: Asveren, Tolga
> Cc: [email-masked]
> Subject: RE: [BEHAVE] STUN relay with push mode QoS reservation
> 
> Hi.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Jul 2007 15:02:13 -0400

> a) How does a proxy learn about the result of the ICE selection?

There is always a subsequent offer/answer exchange to 'fix-up' the SDP 
so that the m/c-lines match the candidates selected by ICE.

No, the rel-addr applies to TURN also:

>   <rel-addr> and <rel-port>:  convey transport addresses related to the
>       candidate, useful for diagnostics and other purposes. <rel-addr>
>       and <rel-port> MUST be present for server reflexive, peer
>       reflexive and relayed candidates.  If a candidate is server or
>       peer reflexive, <rel-addr> and <rel-port> is equal to the base for
>       that server or peer reflexive candidate.  If the candidate is
>       relayed, <rel-addr> and <rel-port> is equal to the mapped address
>       in the Allocate Response that provided the client with that
>       relayed candidate (see Appendix B.3 for a discussion of its
>       purpose).  If the candidate is a host candidate <rel-addr> and
>       <rel-port> MUST be omitted.

This server reflexive related-address is exactly what you'd use in push 
mode QoS.

> c) What if STUN relay is used but no ICE?

Well, then you get what you pay for. At this point we are not 
recommending that. ICE is the IETF solution for SIP nat traversal of 
media, period. Not stun by itself. Not turn by itself.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 9 Jul 2007 15:22:19 -0400

One follow-up question below.

  Thanks,
  Tolga

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, July 09, 2007 3:02 PM
> To: Asveren, Tolga
> Cc: Dan Wing; [email-masked]
> Subject: Re: [BEHAVE] STUN relay with push mode QoS reservation
> 
> 
> 
> Asveren, Tolga wrote:
[TOLGA]Yes, it is one of the addresses needed (the internal remote
transport address). AFAICS, the other address needed is internal local
transport address of STUN relay. What I was wondering was how internal
local transport address is signaled to the proxy.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Jul 2007 16:01:58 -0400

inline.

> local transport address is signaled to the proxy.

I'm not sure which address you mean. For packets forwarded from the TURN 
server, towards the client, the destination address is the 
server-reflexive address towards the TURN server, laerned as above. THe 
source address is the IP/port of the TURN server itself. Is it that one 
you are talking about? That one is not signaled. I don't see why you 
need it though.

-Jonathan R.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 9 Jul 2007 16:10:05 -0400

> 
> >>>   <rel-addr> and <rel-port>:  convey transport addresses related
to
> > the
> >>>       peer reflexive, <rel-addr> and <rel-port> is equal to the
base
> > for
[TOLGA]Yes it was the address I was talking about but you are right that
it is actually not needed. We are dealing with a NAT whose mapping
depends on address/address port in this case. Just specifying the server
reflexive address for the QoS filtering rule should be enough to define
the flow unambiguously.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 20 Jul 2007 14:22:19 -0400

AFAICS <rel-addr> and <rel-port> helps if NAT is between UA and access
endpoint, e.g. a cable modem. Is there anything else, which would help
for the following case:

  UA ------Access Endpoint--- Access Termination--NAT-----STUN
                          ^    (enforces QoS)        ^    Relay
                          |                          |
                          |                          |
                        What is needed             rel-addr
                        for QoS reservation        rel-port

or for the following:

 UA---NAT----Access Endpoint--- Access Termination--NAT-----STUN
                            ^    (enforces QoS)        ^    Relay
                            |                          |
                            |                          |
                          What is needed             rel-addr
                          for QoS reservation        rel-port

    Thanks,
    Tolga

> From: Asveren, Tolga
> Sent: Monday, July 09, 2007 4:10 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]; Dan Wing
> > >>>       reflexive and relayed candidates.  If a candidate is
server
> or
> > >> This server reflexive related-address is exactly what you'd use
in
> > > push

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Jul 2007 19:28:09 -0700

> From: Asveren, Tolga [mailto:[email-masked]] 
> Sent: Friday, July 20, 2007 11:22 AM
> To: Jonathan Rosenberg; [email-masked]

For that, I believe you want to indicate the 'base' in the SDP;
there isn't a mechanism to do that in ICE-17.  At least, in
this situation, the UA does have all the information necessary.

>                           for QoS reservation        rel-port

ICE-17 doesn't have a way to indicate that, either.

However, in this situation, there is a more difficult problem:  
how would the UA learn the IP address and UDP port being used by 
that first NAT (the NAT closest to the UA).  

The UA could could be learned via UPnP or Bonjour; however, if
you throw another NAT into the diagram, that won't work, either:
 
UA--NAT--NAT--Access Endpoint--- Access Termination--NAT---STUN
     1    2                ^    (enforces QoS)        ^    Relay
                           |                          |
                           |                          |
                         What is needed             rel-addr
                         for QoS reservation        rel-port

In the diagram above, UPnP or Bonjour on NAT-1 will only help you 
learn the public address and UDP port on NAT-1; but you need to 
learn the public address and UDP port on NAT-2.  UPnP and Bonjour
don't help (as neither work across NATs).  

If the outer-most NAT (the one closest to the STUN relay in
the figures above) were to support draft-wing-behave-nat-control-stun-usage,
then the UA could query that outer-most NAT and learn the IP address
and UDP port that you need to communicate.

Alternatively, you could declare such nested NATs as 'too hard'
and skip that problem, and just stick with the diagram you
had in your email, and use UPnP or Bonjour to learn the public
IP address and UDP port.

-d

> > > >>>       that server or peer reflexive candidate.  If 
> the candidate
> > is
> > > >>>       relayed, <rel-addr> and <rel-port> is equal to 
> the mapped
> > > > address
> > > >>>       purpose).  If the candidate is a host candidate 
> <rel-addr>
> > and
> > > I'm not sure which address you mean. For packets 
> forwarded from the
> > TURN
> > > server-reflexive address towards the TURN server, laerned 
> as above.
> > THe
> > > source address is the IP/port of the TURN server itself. 
> Is it that
> > one