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

> -----Original Message-----
> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] 
> Sent: Friday, July 20, 2007 11:22 AM
> To: Jonathan Rosenberg; behave@ietf.org
> Subject: RE: [BEHAVE] STUN relay with push mode QoS reservation
> 
> 
> 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

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.

> 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

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

> 
>     Thanks,
>     Tolga
> 
> > -----Original Message-----
> > From: Asveren, Tolga
> > Sent: Monday, July 09, 2007 4:10 PM
> > To: Jonathan Rosenberg
> > Cc: behave@ietf.org; Dan Wing
> > Subject: RE: [BEHAVE] STUN relay with push mode QoS reservation
> > 
> > >
> > > >>>   <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.
> > > > [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.
> > >
> > > 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.
> > [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.
> 
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www1.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave