Subject: [pcp] discuss: using PCP to reduce application-level keepalive traffic

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Dec 2010 11:18:33 -0800

This is one of the PCP discussion points.

There are two ways to do this:

1. Let's call this Connect-Then-Lifetime (connect to the server, then set
lifetime using PCP):

  a.  host initiates a TCP connection to a server, such as a SIP
      or XMPP server.
  b.  in order to reduce the frequency of application keepalives,
      the host issues a PCP request.
  c.  Because it issued that PCP request, do we want the PCP 
      client to re-issue a PCP request, or just send some 
      application traffic 

2. Let's call this Lifetime-Then-Connect (set lifetime using PCP, then
connect to the server):

  a.  in order to reduce frequency of application keepalives,
      to host issues a PCP request
  b.  host issues a TCP connection to a server, such as a SIP
      or XMPP server.
  c.  Because it issued that PCP request, do we want the
      PCP client to re-issue the PCP request, or just send
      some application traffic?

An advantage of (2) is that the PCP server (and NAT) know, a priori, that
the client wants a long-lived connection.  It could use that knowledge to
choose a port from a different pool of ports.  This might help some NAT
implementations.

Thoughts?

-d

---

From: Alain Durand <[email-masked]>
Date: Tue, 7 Dec 2010 12:11:08 -0800

> choose a port from a different pool of ports.  This might help some NAT

I think this is an important feature. Reducing keep-alives is critical in radio networks.
We cannot assume that all long-lived connections are received by the hosts, many of them
will be initiated by the host.

>From the host perspective, there is little difference between 1 and 2. I would argue that 1b is a bit more
complex to implement than 2ab as the client has to be ready to handle the case where the PCP server will refuse
for a reason or another to give the port that NAT has allocated to that connection.

2a will help some NAT implementation to be somehow smarter on how they allocate ports and how they plan
to do HA.

Because I see no advantages of doing 1 and doing 2 is both simpler to implement and has some advantages,
I will favor 2.

Now, you have another question embedded here, which is, what to do on the NAT when the PCP lease expires?
I would say, keep the NAT binding open as long as traffic flows. ie, fall back to regular garbage collection.
If application "forgot" to extend the PCP lease, it cannot expect that the connection will not die if let idle too long.

  - Alain.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Dec 2010 20:52:59 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alain
> Durand
> Sent: Tuesday, December 07, 2010 12:11 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] discuss: using PCP to reduce application-level keepalive traffic
> 
> 
> > 1. Let's call this Connect-Then-Lifetime (connect to the server, then
> > set lifetime using PCP):
> >

Important point: ... and in return it learns the lifetime and hence the
keepalive interval it needs to use (which may be different from what
it requested).

> >      client to re-issue a PCP request, or just send some

The advantage of the PCP request is that it will learn the new 
lifetime.  Just sending traffic should (in my view) keep the mapping alive
but the PCP client won't know the lifetime to use if the session goes 
idle (unless we require the lifetime to be fixed).

> > An advantage of (2) is that the PCP server (and NAT) know, a priori,
> > that the client wants a long-lived connection.  It could use that
> > knowledge to choose a port from a different pool of ports.  This might
> > help some NAT implementations.
> 
> We cannot assume that all long-lived connections are received by the hosts,
> many of them will be initiated by the host.
> 
> From the host perspective, there is little difference between 1 and 2. I would
> argue that 1b is a bit more complex to implement than 2ab as the client has to
> be ready to handle the case where the PCP server will refuse for a reason or
> another to give the port that NAT has allocated to that connection.

I don't follow.  If the SYN exchange completed, then the PCP server can't
refuse to give the port, since it already did so.

> 
> 2a will help some NAT implementation to be somehow smarter on how they
> allocate ports and how they plan to do HA.

Personally I don't like the idea that the NAT allocates ports differently.
For example, if I request a connection with minimum lifetime, you have to
allocate the port at that time.  The server can't tell whether the client 
will extend it or let it expire.  I'd rather just keep it simple and say that
it doesn't matter whether the mapping was created by a data packet
(1) or a PCP message (2), the NAT behavior is the same. 

> 
> Because I see no advantages of doing 1 and doing 2 is both simpler to
> implement and has some advantages, I will favor 2.
> 

+1 to that

> If application "forgot" to extend the PCP lease, it cannot expect that the
> connection will not die if let idle too long.
> 
>   - Alain.
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Alain Durand <[email-masked]>
Date: Tue, 7 Dec 2010 13:12:23 -0800

On Dec 7, 2010, at 3:52 PM, Dave Thaler wrote:

>> \

Normally, yes. Now, not sure this will always be implemented like that,
especially for a NAT that reserves a range of port for PCP controlled sessions.

> (1) or a PCP message (2), the NAT behavior is the same. 

There is a lot that is implementation specific here. It really depends on how
the NAT manages its ports internally. Option 1 makes the assumption that
all ports (PCP and dynamic) are managed the same, option 2 does not.
I'll argue that option 2 is 'safer' to implement on the client side.

    - Alain.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Dec 2010 23:46:30 +0000

> From: Alain Durand [mailto:[email-masked]]
> Sent: Tuesday, December 07, 2010 1:12 PM
> To: Dave Thaler
> Cc: Dan Wing; [email-masked]
> >> From the host perspective, there is little difference between 1 and
> >> 2. I would argue that 1b is a bit more complex to implement than 2ab
> >> as the client has to be ready to handle the case where the PCP server
> >> will refuse for a reason or another to give the port that NAT has allocated to
> that connection.
> >
> > I don't follow.  If the SYN exchange completed, then the PCP server
> > can't refuse to give the port, since it already did so.
> 
> >> 2a will help some NAT implementation to be somehow smarter on how
> >> they allocate ports and how they plan to do HA.
> >
> > For example, if I request a connection with minimum lifetime, you have
> > to allocate the port at that time.  The server can't tell whether the
> > client will extend it or let it expire.  I'd rather just keep it
> > simple and say that it doesn't matter whether the mapping was created
> > by a data packet
> There is a lot that is implementation specific here. It really depends on how the
> NAT manages its ports internally. Option 1 makes the assumption that all ports
> (PCP and dynamic) are managed the same, option 2 does not.

>From the other thread, I agree with Simon (and presumably Stuart) that 
it is simplest to have PCP-allocated ports and TCP-allocated ports managed
the same.

-Dave

---

From: Lars Eggert <[email-masked]>
Date: Wed, 8 Dec 2010 12:22:21 +0200

Hi,

I agree with what Dave sent in his other email. Additionally:

> 1. Let's call this Connect-Then-Lifetime (connect to the server, then set
...
> 2. Let's call this Lifetime-Then-Connect (set lifetime using PCP, then
...
> choose a port from a different pool of ports.  This might help some NAT

A disadvantage of (2) is that is adds another message exchange before the TCP handshake, increasing connection-open delays. Yes, mostly the NAT will be local and the delay will be small, but if the NAT is somewhere in the operator network, this delay could be more substantial.

The nice thing about (1) is that data plane traffic is already flowing while you set up the control plane for the flow.

Lars

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 11:58:50 +0100

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alain Durand
Envoyé : mardi 7 décembre 2010 21:11
À : Dan Wing
Cc : [email-masked]
Objet : Re: [pcp] discuss: using PCP to reduce application-level keepalive traffic

Med: Yes. According to a study based on nokia devices: the consumption with a keep-alive interval equal to 20 seconds is 29mA (2G)/34mA (3G). 
This consumption is reduced to 16mA (2G)/24mA (3G) when the interval is increased to 40 seconds, to 9.1mA (2G)/16mA (3G) if the interval is equal to 150s and to 7.3mA (2G)/14mA (3G) if the interval is equal to 180s. When no keep-alive is issued, the consumption would be 5.2mA (2G)/6.1mA (3G)! 

So means to prevent issuing frequent keepalive messages is recommended for battery consumption for mobile UEs.  Note that the battery consumption issue is even exacerbated if several applications require keep-alive messages (e.g., SIP, IPsec, etc.). An issue is how to detect the timer configured in a NAT device.   

Keepalive impacts also the service elements and also the PCP-controls device: frequent refresh should be sent and this overloads the service nodes (e.g., in case of VoIP the expire timer of SIP messages is tweaked to force frequent REGISTER messages).

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Simon Perreault <[email-masked]>
Date: Wed, 08 Dec 2010 09:12:01 -0500

>       the host issues a PCP request.

To construct the PCP request, the host needs to know the external
address allocated by the NAT in step a. How is it supposed to do that? STUN?

>       to host issues a PCP request

To construct the PCP request, the host needs to know the internal
address that will be allocated in step b. It is feasible, but very
impractical from an implementor's point of view. Basically you need to
duplicate the source-address/port selection algorithm from the kernel
into the application. This is not clean and prone to failure.

>       some application traffic?

I think that both 1 and 2 are not ideal from the point of view of the
app implementor. We need to figure out a better way.

Sadly I don't have any idea at the moment.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 17:01:48 +0100

=> 2 (Lifetime-Then-Connect) for exactly the given reason.
   
Regards

[email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Wed, 8 Dec 2010 17:51:52 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Wednesday, December 08, 2010 6:12 AM
> To: [email-masked]
> To construct the PCP request, the host needs to know the external address
> allocated by the NAT in step a. How is it supposed to do that? STUN?

It shouldn't need to know the external address, only its own address/port
to which they're mapped.  Remember that a renewal is the same as a request
and for a request you don't need to know the external address either.

> To construct the PCP request, the host needs to know the internal address that
> will be allocated in step b. It is feasible, but very impractical from an
> implementor's point of view. Basically you need to duplicate the source-
> address/port selection algorithm from the kernel into the application. This is not
> clean and prone to failure.

Or the application needs to ask the kernel what IP would be used for a given
destination.   This is clean and Windows, at least, supports this.

> I think that both 1 and 2 are not ideal from the point of view of the app
> implementor. We need to figure out a better way.

See above.

-Dave

---

From: Simon Perreault <[email-masked]>
Date: Wed, 08 Dec 2010 13:01:04 -0500

> and for a request you don't need to know the external address either.

So the host would set the external address to zero, right?

The problem with that is that the same internal address may have been
allocated to two unrelated TCP connections. To fully identify a TCP
connection, we need the whole 4-tuple. So there is the possibility of a
collision of you only specify the internal address in the PCP request.

> destination.   This is clean and Windows, at least, supports this.

I know of a portable method: connect() a UDP socket and look at the
result of getsockname(). But this method doesn't provide the port
number. Does the Windows-based method you have in mind provide both the
IP and the port?

Simon

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 19:04:34 +0100

In your previous mail you wrote:

=> this philosophy seems nice but relies on a wrong assumption as
I explained...

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 8 Dec 2010 13:11:51 -0500

I see your point. NAT mappings already come in different types today: EIM,
APD or AD. PCP mappings would be, by their very nature, EIM.

When/If PCP is used outgoing connections I'm assuming the mapping could be
of any time - as opposed to a traditional port forwarding mapping.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 8 Dec 2010 18:48:37 +0000

Reinaldo Penno writes:
> IPCP mappings would be, by their very nature, EIM.

I don't think that's a given.   If you want to use PCP to reduce app-level
keepalive traffic, then you want to use it with a full 5-tuple, in which
case it's APD, especially if it's connect-then-use-PCP.

So I think this is still an open issue that the WG needs to decide.
It's too early to assert "PCP mappings would be, by their very nature,
EIM".

-Dave

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 23:13:04 +0100

=> I can't see why but as I believe 2 is far better it doesn't matter.

   
=> the usual way is to connect an UDP socket to the destination address
so you can get the source address the kernel picks up.

BTW it is a generic issue for PCP: as the internal address must be put
in the request one needs to know it before...

Regards

PS: look at traceroute code (findsaddr-udp.c in my FreeBSD 8.1 sources).

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 23:52:41 +0100

=> hum, I propose s/external/destination/ and you have still a problem
with EIM (end-point independent mode, cf behave RFCs).
IMHO the cleanest is to reserve the port (i.e., choose it from
outside the ephemeral port range).

=> this don't make sense: you must choose the port number yourself.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 23:58:04 +0100

=> and you have the same thing for the filter (vs mode) part
(and PCP mappings are EI as you wrote).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2010 00:23:14 +0100

=> as soon as there is no way by design to specify the end-point
I can't see how they can be create in an end-point dependent way.

Regards

PS: of course this is something we can change, and IMHO it will be
different for the firewall part (I proposed to reuse the external
address and port fields for the peer).
BTW if you disagree with the current choice you can ask the other chair
to add a tracker item (and I'll support you as this point was never
really discussed).

---

From: Tina Tsou <[email-masked]>
Date: Thu, 09 Dec 2010 11:17:45 -0800

I don't see why we need post-signal.
The only merit I can see is that before the connection is setup
successfully, it doesn't need to have PCP to request the NAT entries, if the
connection setup fails, it saves PCP message.
However, from Dan's description about PCP mappings same public IP address as
dynamic mappings, mentioning using PCP to reduce application-level keep
alive	traffic, I can see a merit of it. Is it that adopting post-signal
setup NAT entries belong to dynamic NAT, and pre-signal setup entries belong
to PCP NAT. ISPs can adopt different high availability policies based on
these two kinds of NAT entries?

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

---

From: Simon Perreault <[email-masked]>
Date: Thu, 09 Dec 2010 16:57:14 -0500

>   b.  host issues a TCP connection to a server, such as a SIP

Thinking about it some more, I found a very similar problem with
Lifetime-Then-Connect.

1. A PCP request is sent.
   Internal = Z:z
   External = 0:0
The PCP response contains:
   Internal = Z:z
   External = A:a
2. TCP session A is established from Z:z to X:x.

At this point, everything is fine.

Later...

3. TCP session B is established from Z:z to Y:y.

By chance, session B has been assigned the same source address by the
host's kernel. This is a normal situation that happens in everyday life.
There is no need to use SO_REUSEADDR for this to happen. Sessions A and
B may or may not be created by the same application.

Now, depending on the NAT's mapping behaviour, TCP session B may or may
not be assigned A:a for its external address. If it gets A:a, which
would mean that the NAT's mapping is not endpoint-independent, then
future PCP requests will not contain enough information for the PCP
server to determine which of TCP session A or B is the object of the
request.

Conclusion: for Lifetime-Then-Connect to work with the current
definition of PCP, the NAT's mapping behaviour MUST be Endpoint-Independent.

Strawman proposal: What if we added the destination address (in this
example this means X:x or Y:y) to the PCP request? This would make both
Lifetime-Then-Connect and Connect-Then-Lifetime work in all cases. And
when you want to open a port for listening, you set the destination
address to zero.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 10 Dec 2010 09:10:00 -0800

> Sent: Thursday, December 09, 2010 1:57 PM
> To: [email-masked]

Based on your email yesterday, I had written a paragraph describing
a new PCP Option to do that.  I'll expand its scope a bit to cover
this case, too, and share the proposed text in this thread.  This
PCP Option controls if there is filtering on the NAT, and also 
controls what the NAT should do if a new connection is opened to
a different host (which is where my text drifted off and is
incomplete, because this is difficult-to-impossible to mandate
anything around how dynamic connections are created, no matter
what the BEHAVE-published specs prefer for best interoperability).

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 10 Dec 2010 13:28:45 -0500

IMO 'keep it simple' is very much in the eye of the beholder.

For some keep it simple' is allowing PCP to control/take over regular
mappings - extend, delete, etc at any point in time.

Keep it simple could be leaving all NATs in the world working as is even if
they implement PCP - no interactions between the two modules, security
concerns, etc

As PCP matures and we get more experience we can expand the scope of the WG
to allow PCP to control regular mappings. Keeping them separate for now
seems simple to me.

Thanks,

Reinaldo

On 12/7/10 3:46 PM, "Dave Thaler" <[email-masked]> wrote:

>> the

---

From: Francis Dupont <[email-masked]>
Date: Sat, 11 Dec 2010 14:48:36 +0100

=> +1

---

From: <[email-masked]>
Date: Tue, 14 Dec 2010 13:14:13 +0100

Dear all,

I' echo this comment. 

BTW, as I mentioned in a previous message, PCP-instructed mappings should be clearely identified for various reasons: high-availability, special treatment when an operator want to clear those mappings (e.g., double confirmation), etc.

Cheers,
Med  

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : samedi 11 décembre 2010 14:49
À : Reinaldo Penno
Cc : [email-masked]
Objet : Re: [pcp] discuss: using PCP to reduce application-level keepalive traffic

   
=> +1

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Dec 2010 08:56:23 -0800

There are two goals:

  G1.  Applications want to reduce their application-level keepalive
       traffic.  This is especially true of battery-operated devices.
  G2.  We would like PCP to remain simple.

I believe we need to achieve both goals.

I see two ways to achieve both goals:

 1. tell application developers, who want to reduce application
    keepalives by using PCP, to bind() to their application 
    sockets, so that other applications cannot use the same 
    source port.  This meets G1 and G2.
 2. add fields to PCP to disambiguate the specific connection
    being queried/controlled.  This meets G1.

Are there other approaches to achieve both goals?

-d

> [email-masked]
> Sent: Tuesday, December 14, 2010 4:14 AM
> To: Francis Dupont; Reinaldo Penno
> Cc: [email-masked]
> BTW, as I mentioned in a previous message, PCP-instructed mappings
> should be clearely identified for various reasons: high-availability,
> special treatment when an operator want to clear those mappings (e.g.,
> double confirmation), etc.
> 
> Cheers,
> Med
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 14 Dec 2010 12:06:37 -0500

>     source port.  This meets G1 and G2.

I said it many times but it seems I am not clear enough. Let me try
again because I think this is an important point.

==> CALLING bind() IS NOT ENOUGH <==

:)

If you call connect() (either UDP or TCP), the source port can and will
be reused by another socket, whether you call bind() or not. You don't
need to set SO_REUSEADDR for this to happen.

Solution:

- UDP: Do not use connect(). If that's not possible, open a second
socket on which you will not call connect(), bind() it to the same port.
You need to use SO_REUSEADDR on both sockets.

- TCP: Open a second socket, bind() it to the same source port, and call
listen(). Ignore or reject any incoming connection attempt. You need to
use SO_REUSEADDR on both sockets.

This is incredibly complex, ugly, and fragile.

Conclusion:
We cannot demand that applications implement hacks of this magnitude.

Simon

---

From: Dave Thaler <[email-masked]>
Date: Tue, 14 Dec 2010 17:16:06 +0000

> Sent: Tuesday, December 14, 2010 9:07 AM
> To: [email-masked]
> I said it many times but it seems I am not clear enough. Let me try again because
> I think this is an important point.
> 
> If you call connect() (either UDP or TCP), the source port can and will be reused
> by another socket, whether you call bind() or not. You don't need to set
> SO_REUSEADDR for this to happen.
> 
> Solution:
> 
> - UDP: Do not use connect(). If that's not possible, open a second socket on
> which you will not call connect(), bind() it to the same port.
> - TCP: Open a second socket, bind() it to the same source port, and call listen().
> Ignore or reject any incoming connection attempt. You need to use
> SO_REUSEADDR on both sockets.
> 

Personally I agree with Simon here.

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Dec 2010 11:46:06 -0800

Ok.  Adjusting text and will pass it by you before I publish -01.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Dec 2010 11:30:26 +0100

There are two goals:

   

=> BTW one must avoid ephemeral port range too. And this works well
with the Lifetime-Then-Connect (i.e., it will be in order Bind,
Lifetime and Connect).

   
=> nothing easy or simple.

So I'd like to get 1. BTW it is not necessary to change all
applications, 1 can be implemented in a middleware (shared
library "improved" connect for instance).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Dec 2010 11:37:40 +0100

=> I agree: you need to call bind() with a port which is not in
the ephemeral port range and without SO_REUSEADDR (the first avoids
kernel automatical reuse, the second collision with another binding
application)

Regards

PS: two comments:
 - SO_REUSEADDR is off by default so it is enough to not set it.
 - if ephemeral ports are supported by all OSes I know
  (cf http://en.wikipedia.org/wiki/Ephemeral_port)
  the way to get the range is very OS dependent (only a burden
  for portable code...)

---

From: Lars Eggert <[email-masked]>
Date: Wed, 15 Dec 2010 12:09:08 +0100

> We cannot demand that applications implement hacks of this magnitude.

+1

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 15 Dec 2010 12:12:48 +0100

Hi,

I don't like lifetime-then-connect, which was option (2) in Dan's original email for the reason below. I'm breaking this off the main thread so that this point is more visible.

Lars

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Dec 2010 13:05:30 +0100

I don't like lifetime-then-connect, which was option (2) in Dan's
   original email for the reason below. I'm breaking this off the main
   thread so that this point is more visible.
   
   On 2010-12-8, at 11:22, Lars Eggert wrote:

   > A disadvantage of (2) is that is adds another message exchange
   > before the TCP handshake, increasing connection-open delays. Yes,
   > mostly the NAT will be local and the delay will be small, but if
   > the NAT is somewhere in the operator network, this delay could be
   > more substantial.
   >
   > The nice thing about (1) is that data plane traffic is already
   > flowing while you set up the control plane for the flow.
   
=> this is the only disavantage of 2/lifetime-then-connect, the
other option raises two issues:
 - possible collision on the ephemeral port
 - doesn't work if dynamic and PCP mappings use different external
  port ranges (BTW this point is a customer requirement for AFTR)
So I still support 2 aka lifetime-then-connect

Thanks

---

From: <[email-masked]>
Date: Wed, 15 Dec 2010 13:22:53 +0100

Hi Lars, all,

I don't know how we can forbid applications to use option 2 which is the obvious one to avoid overloading service elements with keepalive messages!

As a concrete example: In the current VoIP deployments SBC or P-CSCF forces the SIP User Agent to send frequent REGISTER messages (setting a small value of expire timer); these messages are not forwarded to the core service elements. The main purpose is to maintain the NAT binding in case a NAT is traversed alive. Both the NAT and SBC are overloaded with these keepalive messages. For the NAT side this may not be an issue when the NAT is embedded in the CPE but this may be become sensitive for the CGN case. 

If PCP is used to instruct a mapping before issuing the REGISTER message: (1) the CGN is not overloaded, (2) service contact point is not overloaded, (3) the client can use the external IP address/port to build its application messages (e.g., SIP) and thus no need to implement extra function in the service side (e.g., SBC) or in the CGN (e.g., SIP ALG), (4) the service elements can detect the present of non-transparent NAT by comparing the content of the message with the source IP/port information, (5) the client is aware of the lifetime of the mapping in the CGN which important to avoid sending aggressive keeplines (e.g., 20s for Ipsec clients), etc.

I think Option (2) should be RECOMMENDED in the draft. Option (1) might be defined as Optional and be left to the taste of delay-sensitive applications developers.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Lars Eggert
Envoyé : mercredi 15 décembre 2010 12:13
À : [email-masked]
Objet : [pcp] Against lifetime-then-connect (was: Re: discuss: using PCP to reduce application-level keepalive traffic)

Hi,

Lars

---

From: Simon Perreault <[email-masked]>
Date: Wed, 15 Dec 2010 09:14:41 -0500

>     source port.  This meets G1 and G2.

Another important disadvantage of this method is that it limits the
*whole system* (not only a single app) to a ridiculously low number of
ephemeral connections (that use PCP), whereas normally it is practically
unlimited as long as you connect to different destinations. Using
Francis' method (restricting the source port to the non-ephemeral range)
makes this limit even lower.

Conclusion:
This method does not scale.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 15 Dec 2010 09:22:22 -0500

On 2010-12-15 07:22, [email-masked] wrote:
> If PCP is used to instruct a mapping before issuing the REGISTER
> message: (1) the CGN is not overloaded, (2) service contact point is
> not overloaded, (3) the client can use the external IP address/port
> to build its application messages (e.g., SIP) and thus no need to
> implement extra function in the service side (e.g., SBC) or in the
> CGN (e.g., SIP ALG), (4) the service elements can detect the present
> of non-transparent NAT by comparing the content of the message with
> the source IP/port information, (5) the client is aware of the
> lifetime of the mapping in the CGN which important to avoid sending
> aggressive keeplines (e.g., 20s for Ipsec clients), etc.

The alternative (Connect-then-Lifetime) would have the exact same 5
properties, would it not?

I don't understand your point.

Simon

---

From: Lars Eggert <[email-masked]>
Date: Wed, 15 Dec 2010 15:50:21 +0100

Hi,

> I don't know how we can forbid applications to use option 2 which is the obvious one to avoid overloading service elements with keepalive messages!

I don't want to forbid option 2, I want to make sure that option 2 is at least not the only one allowed by PCP. I'd also not like it to be the default option.

Does option 1 not also lead to keepalive reduction? (See Simon's reponse, too.)

> As a concrete example: In the current VoIP deployments SBC or P-CSCF forces the SIP User Agent to send frequent REGISTER messages (setting a small value of expire timer)

If you do option 1 and it works, you would also remove the need for frequent keep-alives.

I get Francis point that option 1 might have collision possibilities, etc., but at least in my mind, that is a lesser evil compared to increasing the latency of every single TCP connection handshake.

An application will already need to be able to deal with error conditions such as the PCP box not responding, and sane applications will in those cases open the TCP connection anyway and just do keepalives, like it does now. That mechanism will also handle collisions and other corner cases.

Lars

---

From: <[email-masked]>
Date: Wed, 15 Dec 2010 15:58:05 +0100

Hi Simon,

The difference is that Option 1 does not offer property # 3 and in addition the service element may think the NAT in the path is non-transparent (compare the content of the REGISTER message and the source IP address/port) then it will reduce the value of expire (e.g, SIP) and then the keepalive will be forced by the service element (because refresh is forced by the server side and not the client side).

So, implementing Option 1 may not lead to reduce keepalive messages in some scenarios. 

Did I missed something?

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : mercredi 15 décembre 2010 15:22
À : [email-masked]
Objet : Re: [pcp] Against lifetime-then-connect

Simon

---

From: <[email-masked]>
Date: Wed, 15 Dec 2010 16:01:50 +0100

Hi Lars,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Lars Eggert [mailto:[email-masked]] 
Envoyé : mercredi 15 décembre 2010 15:50
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [pcp] Against lifetime-then-connect (was: Re: discuss: using PCP to reduce application-level keepalive traffic)

Hi,

Med: Not in all scenarios: e.g., in SIP keepalive (i.e., issue frequent REGISTER) is forced by the server and not the client.

Med: How the service element (e.g., SBC/P-CSCF) will be then aware that in the client side you are controlling your NAT? Unlike Option 2, SIP messages may contain the internal IP address and not the external one; thus symmetric SIP will be required to be implemented by the service elements (rport is even not required for option 2 since the internal port in the via header will be the one assigned by the NAT).

---

From: Lars Eggert <[email-masked]>
Date: Wed, 15 Dec 2010 16:17:01 +0100

Hi,

we're talking past one another. I think you must have some unstated additional assumptions about what option 1 and 2 are, or assume some specific consequences.

>      some application traffic?

The only different here is is the connect comes first, or the PCP message comes first.

You say:

> Med: How the service element (e.g., SBC/P-CSCF) will be then aware that in the client side you are controlling your NAT? Unlike Option 2, SIP messages may contain the internal IP address and not th…

Option 1 vs. option 2 is not at all about what IP addresses will be contained in SIP messages, etc. It's about whether the connect comes first or not.

Sure, if you *know* that e.g. option 2 will be used, an ISP can configure their CGN and addressing differently. But there's a cost here, and that's end-user perceived latency. Ask Google how hard they try to minimize that.

Lars

---

From: Alain Durand <[email-masked]>
Date: Wed, 15 Dec 2010 07:43:52 -0800

> I get Francis point that option 1 might have collision possibilities, etc., but at least in my mind, that is a lesser evil compared to increasing the latency of every single TCP connection handshak…

Lars, Med:

This is not about increasing latency to every single TCP session.
Using PCP is a voluntary thing that application can use to signal a long live connection, it does not apply to every single connection.
So, if the connection is long lived, I'm not worried much about an extra initial round trip time.

   - Alain.

---

From: Alain Durand <[email-masked]>
Date: Wed, 15 Dec 2010 07:46:09 -0800

> Sure, if you *know* that e.g. option 2 will be used, an ISP can configure their CGN and addressing differently. But there's a cost here, and that's end-user perceived latency. Ask Google how hard t…

There is latency and latency. I'll argue that reducing latency of ephemeral connection is very important, but reducing latency of long lived connection may not be that important.

 - Alain.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Dec 2010 17:43:53 +0100

Conclusion:
   
=> the whole idea doesn't scale but it should be used
in a context where scalability doesn't matter, does it?

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Dec 2010 17:49:29 +0100

I don't want to forbid option 2, I want to make sure that option 2
   is at least not the only one allowed by PCP. I'd also not like it
   to be the default option.
   
=> note if the CGN rejects the option 1 it puts a 'not-authorized'
error in the response so the option 2 can be used as a fallback.

   I get Francis point that option 1 might have collision
   possibilities, etc., but at least in my mind, that is a lesser evil
   compared to increasing the latency of every single TCP connection
   handshake.
   
=> collision is possible but unlikely, in particular in the
target context.

Regards

---

From: Lars Eggert <[email-masked]>
Date: Thu, 16 Dec 2010 11:00:09 +0200

> So, if the connection is long lived, I'm not worried much about an extra initial round trip time.

I'm not sure if an app necessarily knows ahead of time whether a connection will be long lived or not.

Also, if you think about battery powered devices for a minute, if you need to do frequent keep-alives for one connection, you might as well do them for more - once the radio is out of power-save mode to send one keep-alive, the incremental cost of sending several is negligible. (And yes, devices do actually coalesce keep-alives for several connections already.)

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 16 Dec 2010 11:07:51 +0200

(I realized that I didn't actually spell out the conclusion I had in mind in the previous email - sorry.)

> Also, if you think about battery powered devices for a minute, if you need to do frequent keep-alives for one connection, you might as well do them for more - once the radio is out of power-save mo…

The consequence is that mobile devices *will* try to use PCP to increase the keep-alive interval for every single connection.

Lars