Subject: [pcp] closing #16 and #17

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Feb 2011 08:17:46 -0800

I would like to close tickets #16 and #17.  Recent discussions include
http://www.ietf.org/mail-archive/web/pcp/current/msg00896.html
and is related to both Ticket #17, "using PCP to reduce application-level
keepalive traffic"
http://trac.tools.ietf.org/wg/pcp/trac/ticket/17
and to Ticket #16, "PCP lifetime expiration with active traffic",
http://trac.tools.ietf.org/wg/pcp/trac/ticket/16

Here are my straw-man proposals.  Please tear them down so we can discuss
this and reach some consensus:

  1. PCP would not define if a MAP-created mapping would be terminated or
extended by inside->outside traffic.  This means this is an
implementation-dependent decision to terminate the mapping once the lifetime
expires if there is still inside->outside traffic.  Obviously, if  a PCP
client wants to ensure its MAP-created mapping continue to survive, it would
need to re-issue MAP requests periodically.  This gives the most
implementation flexibility to the PCP-controlled device, and may be
necessary in some implementations.  However, it also means some lazy PCP
clients (which don't re-issue their MAP requests) will work with some PCP
servers but will fail with other PCP servers -- an aspect I don't like.

  2. PCP would define that if PEER is used, it has no effect on the
destruction of the mapping.  That is, the client can send just one PEER
message, and (potentially) never send any more PEER messages for that
mapping.  Most critically, the PEER response indicates how long the mapping
would survive after _any_ traffic is sent for that mapping.  Let me explain,
because this uncovers a subtle nuance that I would like to get consensus on.
Here is an example scenario:
   a. client establishes TCP connection to a server (e.g., SIP server, XMPP
server)
   b. client issues a PCP PEER request for that connection
   c. PEER response indicates lifetime is 30 minutes
   d. every ~25 minutes, client can keep the mapping alive by sending:
      1. PCP PEER request, _or_
      2. TCP traffic to its SIP/XMPP server
The interesting part is (2)(d)(1), which I would like to get consensus on
writing into the specification.  IMHO, this is exactly how NAPT devices
function today, and seems likely this is how they would function tomorrow.
The advantage of (2)(d)(1) is that a PCP client does not need to consume
bandwidth (or processing cycles) to re-sending PEER messages when it would
have anyway sent an application-level message.  

Please provide feedback so I can close #16 and #17.  Thanks.

-d

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Feb 2011 11:36:32 -0500

> have anyway sent an application-level message.  

It's a good idea, but I think it's hardly implementable. It requires the
PCP server to be able to modify the NAT's behaviour when it receives
data. I think so far we have worked under the assumption that changing
NAT behaviour was out of scope.

Another thing: this is a micro-optimization. A client will presumably
use the PEER request to enlarge the lifetime. Therefore, keep-alive PEER
messages will account for very low traffic already.

IMHO this optimization is not worth it.

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: "Dan Wing" <[email-masked]>
Date: Mon, 28 Feb 2011 08:44:00 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Monday, February 28, 2011 8:37 AM
> To: [email-masked]
> Subject: Re: [pcp] closing #16 and #17
> 
> data.

Not necessarily.  Rather, the PCP server need only know that, when
new inside->outside traffic arrives, it causes the mapping to be
extended by NNN minutes.  That is already how most NAPT (and firewall)
devices function.

> I think so far we have worked under the assumption that changing

Yes, and my straw-man proposal does not violate that assumption.

> messages will account for very low traffic already.

Agreed on that point.

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Feb 2011 11:47:24 -0500

> extended by NNN minutes.  That is already how most NAPT (and firewall)

True, but in many NATs the NNN value is a global setting and cannot be
overridden per-session.

Simon

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Feb 2011 08:52:18 -0800

> extended by NNN minutes.  That is already how most NAPT (and firewall)

By saying that NAT bindings can be created either by TCP SYN or PCP message,
we have already decided that there is a single binding table shared by whatever
the NAT is normally doing and PCP. So, its is normal then to say that binding lifetimes
are extended the same way. IE, either by explicit PCP signaling or by whatever the NAT
normally does. The point is that the NNN minutes extensions (decided by the NAT when
seeing traffic) is NOT under the control of PCP and, as such, not under the control of the app.
So, if the app wants to maintain the mapping in place, it better send a new PCP message anyway.

  - Alain.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Feb 2011 09:01:10 -0800

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Monday, February 28, 2011 8:47 AM
> To: Dan Wing
> Cc: [email-masked]

Agreed.  But I believe the following text already allows for
exactly that case:

   If the PCP-controlled device can have its lifetime adjusted, the PCP
   server uses the smaller of its configured maximum lifetime value and
   the requested lifetime from the PEER request, and sets the lifetime
   to that value.

(Jacni Qin pointed out the text needed some tweaking, so in -05 it
will read:

        If the PCP-controlled device can extend the lifetime
of a mapping, the PCP server uses the smaller of its configured 
maximum lifetime value and the requested lifetime from the PEER 
request, and sets the lifetime to that value.

        The PEER4 or PEER6 OpCodes MUST NOT reduce the lifetime of
        an existing mapping.
        ...
)

-d

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Feb 2011 08:55:31 -0800

> True, but in many NATs the NNN value is a global setting and cannot be

What I would object to is that if a session was signaled with PCP to be up by, say, 25 min,
and the normal NAT timer is 3 min, that after the initial 25 min, every time the NAT
sees a packet for that flow, it would automatically extend the binding lifetime by 25 min.

Alain.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Feb 2011 10:11:08 -0800

> From: Alain Durand [mailto:[email-masked]]
> Sent: Monday, February 28, 2011 8:56 AM
> To: Simon Perreault
> Cc: Dan Wing; [email-masked]

So, the PCP server can either:

  a. store additional information that the
     lifetime of this mapping is 25 minutes (rather than the 
     3 minute default).
or
  b. not extend the lifetime to 25 minutes; rather, extend it only
     to 3 minutes.

This is a tradeoff of memory in the PCP server (a) versus PCP
requests on the wire (b).

I am hearing a preference for (b).  So, I will write it up that
way.  Thanks.

-d

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Feb 2011 10:16:25 -0800

> I am hearing a preference for (b).  So, I will write it up that

Another way to say it:

- PCP messages create/increase lifetimes by amount negotiated by the app in the PCP dialog
- Packets going through the NAT create/increase lifetimes by the NAT-configured amount (unknown to app)

    Alain.

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 28 Feb 2011 13:37:30 -0500

> NAT-configured amount (unknown to app)

It might be one of the 'out of scope' things but a few situations that will
surely happen

* A packet tries to increase the lifetime beyond the one negotiated by PCP.
* PCP tries to reduce the lifetime earlier than one set by the receipt of a
previous packet.
* PCP asks for a lifetime of, say, 30 minutes but the NAT sees a 4-way
close/RST. Should the entry go away?
* Several other similar ones....

Thanks,

Reinaldo

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Feb 2011 12:05:46 -0800

> * A packet tries to increase the lifetime beyond the one negotiated by PCP.

Not an issue, per algorithm I mention before.
PCP says: set lifetime to 1 min, start counting down. Packet flows, lifetime is increased by, say 3 min. 

> * PCP tries to reduce the lifetime earlier than one set by the receipt of a

Same thing. Nothing bad happens.

> close/RST. Should the entry go away?

This is not different than a NAT sees a packet, reset lifetime counter to 3 min, and then immediately
sees a close/RST. 

The larger point here is that PCP negotiated lifetimes are not an absolute thing.
Things are much easier to understand when you start looking at PCP & NAT binding
and one and the same, with 2 different ways to create or extend the lifetimes.

   - Alain.

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Feb 2011 12:18:31 -0800

On Feb 28, 2011, at 3:13 PM, Reinaldo Penno wrote:

> I was implying is a technical issue. I think the proposed algorithm needs
> some wording much like RFC4787. Something like
> 
> "If security policies allow, the receipt of packet will increase the
> lifetime of a binding....", etc. Same for other cases.

Thanks for clarifying. Yes, the wording here is important to get the details right.

  - Alain.

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 28 Feb 2011 15:13:03 -0500

---

From: Jacni Qin <[email-masked]>
Date: Tue, 1 Mar 2011 06:40:50 +0800

On Tue, Mar 1, 2011 at 2:11 AM, Dan Wing <[email-masked]> wrote:

> Jacni>: While in this way, it seems that the "app-keepalive" is not
reduced, since the new PCP keepalive is created.

Cheers,
Jacni

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Feb 2011 14:45:59 -0800

On Feb 28, 2011, at 5:40 PM, Jacni Qin wrote:

Jacni>: While in this way, it seems that the "app-keepalive" is not reduced, since the new PCP keepalive is created.

Jacni:

The App should send a new PCP request before the initial 25 min timeout. The whole discussion here is what happens if the app does not do a PCP renew.

  - Alain.

---

From: Jacni Qin <[email-masked]>
Date: Tue, 1 Mar 2011 09:17:51 +0800

Hi Alain,

On Tue, Mar 1, 2011 at 6:45 AM, Alain Durand <[email-masked]> wrote:

> The App should send a new PCP request before the initial 25 min timeout.
> The whole discussion here is what happens if the app does not do a PCP
> renew.
>

Jacni>: Sorry, I'm a little confused, if "not extend the lifetime to 25
minutes, rather only to 3 minutes", which means the request for extending
lifetime is rejected and the client is told by the response that the mapping
would survive for 3 minutes after any traffic is sent for that mapping, then
if there are normal active traffics sent anyway, that's ok, otherwise the
client will have to maintain the mapping either by sending app-keepalive or
re-initiating a PCP.

Our goal is to reduce the keepalive (by any means) for mappings, so if the
client wants to achieve this it should employ the PCP tools even it is a
lazy one. And a PCP server supporting this feature should accept the
reasonable PCP request for extending lifetime, and in this case it seems ok
for active traffics to reset the lifetime to 25 minutes.
Otherwise, the client is indicated that "No, you should be always active, or
the mapping will be deleted after 3 minutes", so if I understand it
correctly, why do we need the PEER in this case, just to remind the client
the exact value of lifetime?

Cheers,
Jacni

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Feb 2011 17:29:35 -0800

On Feb 28, 2011, at 8:17 PM, Jacni Qin wrote:

Jacni>: Sorry, I'm a little confused, if "not extend the lifetime to 25 minutes, rather only to 3 minutes", which means the request for extending lifetime is rejected and the client is told by the response that the mapping would survive for 3 minutes after any traffic is sent for that mapping, then if there are normal active traffics sent anyway, that's ok, otherwise the client will have to maintain the mapping either by sending app-keepalive or re-initiating a PCP.

Jacni: There seems to be some confusion here.
Why would the PCP server refuse to extend the lifetime by another 25min? I can see no reasons...

The normal mode of operation is:

connect
PCP request set lifetime to 25 min
[time passes]
[less than 25 minutes later]
PCP request to set the lifetime to 25min
repeat

This achieves the stated goal of reducing keep alive.

Alain.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Feb 2011 17:40:55 -0800

> Sent: Monday, February 28, 2011 5:30 PM
> To: Jacni Qin
> Cc: Dan Wing; Simon Perreault; [email-masked]
> minutes, rather only to 3 minutes", which means the request for
> extending lifetime is rejected and the client is told by the response
> that the mapping would survive for 3 minutes after any traffic is sent
> for that mapping, then if there are normal active traffics sent anyway,
> that's ok, otherwise the client will have to maintain the mapping
> either by sending app-keepalive or re-initiating a PCP.
> 

Jacni's point is that if there is inside->outside traffic that
would have kept the mapping alive, the periodic PCP PEER request 
message (send 'less than 25 minutes later', per your example) is 
additional traffic.

-d

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Feb 2011 18:06:42 -0800

> message (send 'less than 25 minutes later', per your example) is 

Are we really concerned about one extra 2-packet exchange every 25 minutes?

   - Alain.

---

From: Jacni Qin <[email-masked]>
Date: Tue, 1 Mar 2011 10:26:22 +0800

> Are we really concerned about one extra 2-packet exchange every 25 minutes?

Jacni>: Another thing is in this way, the mapping can be simply deleted if
the timer expires without any concern.

Cheers,
Jacni