headers
Internet-Drafts | 3 Jul 2007 20:15
Picon
Favicon

I-D ACTION:draft-ietf-behave-nat-icmp-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title		: NAT Behavioral Requirements for ICMP protocol
	Author(s)	: P. Srisuresh, et al.
	Filename	: draft-ietf-behave-nat-icmp-04.txt
	Pages		: 24
	Date		: 2007-7-3
	
This document specifies the behavioral properties required of the 
   Network Address Translator (NAT) devices in conjunction with the
   ICMP protocol. The objective of this memo is to make NAT devices
   more predictable and compatible with diverse application protocols
   that traverse the devices. Companion documents provide behavioral
   recommendations specific to TCP, UDP and other protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-behave-nat-icmp-04.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 Jul 2007 21:15
Picon
Favicon

I-D ACTION:draft-ietf-behave-p2p-state-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title		: State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs)
	Author(s)	: P. Srisuresh, et al.
	Filename	: draft-ietf-behave-p2p-state-03.txt
	Pages		: 31
	Date		: 2007-7-3
	
This memo documents the various methods known to be in use by
   applications to establish direct communication in the presence
   of Network Address Translators (NATs) at the current time. This
   memo covers NAT traversal approaches used by both TCP and UDP
   based applications. This memo is not an endorsement of the methods 
   described, but merely an attempt to capture them in a document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-behave-p2p-state-03.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gonzalo Camarillo | 4 Jul 2007 11:01
Picon
Favicon

Re: Multiple allocated addresses per TURN allocation WAS (Re: I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt)

Hi,

yes, it seems that a simple solution would be best. I suggest we do as 
follows. We do not allow multiple addresses per allocation. Instead, if 
a client wants to allocate an IPv4 and an IPv6 address at a relay, it 
performs two different allocations. This way, we do not add any extra 
complexity to the protocol.

Regarding address types, I suggest that we keep things as they are. That 
is, we define the IPv4 and IPv6 address families, which are the ones 
that people will definitively use.

Cheers,

Gonzalo

Philip Matthews wrote:
> My concern about the SourceAddress and DestinationAddress attributes is 
> partly overhead and partly additional complexity in TURN.
> 
> The first could be addressed by enhancing the SetActiveDestination 
> indication to specify the default sending/receiving address so that 
> these attributes can be eliminated once the ICE connectivity checks are 
> finished.
> 
> The second is just because I see STUN and TURN as getting more and more 
> complex to handle marginal cases.
> Personally, I don't see a reasonable use-case for a TURN relay with more 
> than one IPv4 address and one IPv6 address. Unless, some can present 
> one, I suggest we design for that case and not insert things that are
(Continue reading)

Permalink | Reply | 1 comment |
headers
Asveren, Tolga | 5 Jul 2007 04:30
Favicon

Redirect for STUN Relay

I was wondering whether it would make sense to have redirect type of
functionality for STUN Relay, e.g. referring another server in a
negative answer to an initial allocate request.

The use case I am thinking of is load balancing. Discovery of STUN
servers relies on DNS but a predefined weight allocation based on
capacity may not provide always satisfactory results. The load on a
server would be a parameter of capacity, bandwidth for a session and the
duration of the sessions it is relaying. One could argue that on average
sessions with different durations would be more or less evenly
distributed among different STUN relay servers but I think it wouldn't
be wrong to say that this parameter is more volatile than others. 

During times of heavy resource allocation in servers, search based on
weights associated with servers may require multiple request/responses
till an actual allocation is performed. With the ability to refer
another server, information STUN servers in a farm have about other
server's resource usage or a front end may be utilized.

This may not be a good fit for certain architectures/configurations but
for such cases one may simply choose not to refer another server.

     Thanks,
     Tolga
Permalink | Reply | 12 comments |
headers
Rémi Denis-Courmont | 5 Jul 2007 08:09
Picon

Re: Redirect for STUN Relay

On Thursday 05 July 2007 05:30:06 ext Asveren, Tolga wrote:
> I was wondering whether it would make sense to have redirect type of
> functionality for STUN Relay, e.g. referring another server in a
> negative answer to an initial allocate request.

This is *already* in the specification, and has been there for several years.

--

-- 
Rémi Denis-Courmont
Permalink | Reply | 11 comments |
headers
Asveren, Tolga | 5 Jul 2007 14:20
Favicon

RE: Redirect for STUN Relay

O.K., sorry my bad.

  Thanks,
  Tolga

> -----Original Message-----
> From: Rémi Denis-Courmont [mailto:remi.denis-courmont <at> nokia.com]
> Sent: Thursday, July 05, 2007 2:09 AM
> To: behave <at> ietf.org; Asveren, Tolga
> Subject: Re: [BEHAVE] Redirect for STUN Relay
> 
> On Thursday 05 July 2007 05:30:06 ext Asveren, Tolga wrote:
> > I was wondering whether it would make sense to have redirect type of
> > functionality for STUN Relay, e.g. referring another server in a
> > negative answer to an initial allocate request.
> 
> This is *already* in the specification, and has been there for several
> years.
> 
> --
> Rémi Denis-Courmont
Permalink | Reply | 10 comments |
headers
Jonathan Rosenberg | 5 Jul 2007 16:58
Picon
Favicon

Re: Redirect for STUN Relay

Actually, this is something which we were planning on removing in the 
revision coming up. There were comments during last call about the 
utility of the mechanism, security concerns, and so on. Also there 
didn't seem to be anyone who wanted it. There are much better ways of 
doing load balacning, for example utilizing a front-end load balancing 
element that actually tracks capacity of back end relays, and then 
directs the request to the least loaded server. THis is standard 
practice for load balancing for many other protocols. That kind of 
mechanism is also faster and more stable. Redirect mechanisms can result 
in ping-ponging especially near capacity limits.

-Jonathan R.

Asveren, Tolga wrote:
> O.K., sorry my bad.
> 
>   Thanks,
>   Tolga
> 
>> -----Original Message-----
>> From: Rémi Denis-Courmont [mailto:remi.denis-courmont <at> nokia.com]
>> Sent: Thursday, July 05, 2007 2:09 AM
>> To: behave <at> ietf.org; Asveren, Tolga
>> Subject: Re: [BEHAVE] Redirect for STUN Relay
>>
>> On Thursday 05 July 2007 05:30:06 ext Asveren, Tolga wrote:
>>> I was wondering whether it would make sense to have redirect type of
>>> functionality for STUN Relay, e.g. referring another server in a
>>> negative answer to an initial allocate request.
>> This is *already* in the specification, and has been there for several
(Continue reading)

Permalink | Reply | 9 comments |
headers
Marc Petit-Huguenin | 5 Jul 2007 17:15
Picon
Favicon

Re: Redirect for STUN Relay

Jonathan Rosenberg wrote:
> Actually, this is something which we were planning on removing in the
> revision coming up. There were comments during last call about the
> utility of the mechanism, security concerns, and so on. Also there
> didn't seem to be anyone who wanted it. 

OK, I missed the discussion, because I use the 300 response, and plan to
continue to use it.  I also proposed a long time ago to replace the IP
address in the 300 response by a name so the SRV RR processing can be
reapplied, but without success.

There are much better ways of
> doing load balacning, for example utilizing a front-end load balancing
> element that actually tracks capacity of back end relays, and then
> directs the request to the least loaded server. THis is standard
> practice for load balancing for many other protocols. 

This also force to buy expensive stuff that is not needed with the end
to end mechanisms.  It's OK if people want to use B2BUA, SBC, load
balancers, NAT - their money, not mine - but Internet standards should
not force people to do this.

So I am strongly opposed to remove the 300 response from STUN.

> That kind of
> mechanism is also faster and more stable. Redirect mechanisms can result
> in ping-ponging especially near capacity limits.
> 
> -Jonathan R.
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Asveren, Tolga | 6 Jul 2007 02:59
Favicon

STUN relay with push mode QoS reservation

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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Gonzalo Camarillo | 6 Jul 2007 08:57
Picon
Favicon

Re: Multiple allocated addresses per TURN allocation WAS (Re: I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt)

Hi,

I have put together a new revision of this draft. Until it appears in
the archives, you can fetch it from:

http://users.piuha.net/gonzalo/temp/draft-ietf-behave-turn-ipv6-03.txt

Besides addressing a few issues that were identified a while ago, I have
added the following paragraph to this revision:

    For simplicity reasons, STUN relay servers are designed to allocate a
    single address per allocation request.  Therefore, Allocate Requests
    cannot carry more than one REQUESTED-ADDRESS-TYPE attribute.
    Consequently, a client that wishes to allocate more than one address
    at a STUN relay server (e.g., an IPv4 and an IPv6 address) needs to
    perform several allocation requests (one allocation request per
    address).

I believe it captures the result of our mailing list discussions. Even
though this was the approach the draft took from the beginning, it has
been good to have explicit discussions on the list about potential
optimizations such as the allocation of multiple addresses per
allocation, which we have agreed not to implement.

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
> Hi,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane