Subject: [pcp] base #27 (new): Maximum lifetime

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 14 Dec 2010 20:18:58 -0000

#27: Maximum lifetime

 From http://www.ietf.org/mail-archive/web/pcp/current/msg00291.html

 In order to avoid having longer lifetime and encourage applications to
 request for a reasonable lifetime value, I propose the Lifetime field to
 be encoded in 16 bits (i.e., the maximum allowed value would be 18 hours)
 instead of 32 bits.

 IMHO, limiting the maximum lifetime value by design is more efficient than
 having a configuration recommendation in the I-D.

 Moreover, with shortened maximum lifetime stale entries will last at
 maximum 18 hours in any case (whatever the config of the PCP Server,
 requested value by the PCP Client) and unwanted mappings (if any) won't
 last for ever (lifetime of 32 bits), etc.

 Opinions?

-- 
--------------------------------------------------+-------------------------
 Reporter:  mohamed.boucadair@…                   |       Owner:     
     Type:  defect                                |      Status:  new
 Priority:  minor                                 |   Milestone:     
Component:  base                                  |     Version:     
 Severity:  Active WG Document                    |    Keywords:     
--------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/27>
pcp <http://tools.ietf.org/pcp/>

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Dec 2010 00:14:18 +0100

In your previous mail you wrote:

   #27: Maximum lifetime
   
    Opinions?
   
=> keep 32 bits. Today we don't know if long lifetimes will be useful.

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Dec 2010 18:41:41 -0800

>  be encoded in 16 bits (i.e., the maximum allowed value would be 18

We could do lots of creative things with the lifetime.  Measuring
lifetime in seconds is too short, really.  It could be measured
in 5 second increments, allowing for fewer bits.  But it also 
increases the likelihood of a buggy implementation.

IMHO, 18 hours is too short - I can envision operations support
systems that want to forward a port for 24 hours and be done with 
it for the day.  If we are going to do any shortening, I wouldn't 
want anything shorter than 24 bits, which if counting seconds is 
194 days.

-d

---

From: <[email-masked]>
Date: Thu, 23 Dec 2010 08:11:48 +0100

Hi Dan,

Yes, we can do a lot of things with the lifetime and play with units, etc; but the issue I have is how to avoid as much stale mappings and therefore avoid unwanted traffic to be forwarded to customers. Another aside effect of "stale" mappings is it consume the per-subscriber port quota.

BTW, the text in the draft around the recommended max lifetime (7200s) should be elaborated to point the aside effects of allowing for longer lifetime.

Having a lifetime of 194 days is still "huge" IMO.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : jeudi 23 décembre 2010 03:42
À : 'pcp issue tracker'; BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : RE: [pcp] base #27 (new): Maximum lifetime

-d

*********************************
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: Francis Dupont <[email-masked]>
Date: Thu, 23 Dec 2010 09:28:59 +0100

The real solution to the stable mapping problem is to provide
a GET mechanism. IMHO this problem is not a good reason to a wild
limit on lifetimes.

Regards

---

From: Simon Perreault <[email-masked]>
Date: Thu, 23 Dec 2010 09:09:43 -0500

On 12/23/2010 02:11 AM, [email-masked] wrote:
> the issue I have is how to avoid as much stale mappings and
> therefore avoid unwanted traffic to be forwarded to customers.
> Another aside effect of "stale" mappings is it consume the
> per-subscriber port quota.

Your operational requirement seems to be already covered:

   The PCP server SHOULD be configurable for permitted minimum and
   maximum lifetime

There's a difference between what we allow the protocol to do (e.g.
gigantic lifetimes) and what is your PCP server's local policy (e.g. cap
the lifetime to 60 minutes).

I don't think we should change what goes on the wire (32 bits, seconds).
It's a very natural encoding that is encountered everywhere, in
protocols as well as in operating system data structures. It doesn't
prevent an operator from configuring the PCP server to apply local
policy on lifetime limits.

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: Thu, 23 Dec 2010 09:38:13 -0800

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, December 22, 2010 11:12 PM
> To: Dan Wing; 'pcp issue tracker'
> Cc: [email-masked]
> Subject: RE: [pcp] base #27 (new): Maximum lifetime
> 
> Hi Dan,
> 
> Yes, we can do a lot of things with the lifetime and play with units,
> etc; but the issue I have is how to avoid as much stale mappings and
> therefore avoid unwanted traffic to be forwarded to customers. Another
> aside effect of "stale" mappings is it consume the per-subscriber port
> quota.

Both the subscriber and PCP operator are in control, by using reasonable
lifetime values.  The choice depends on lots of factors.  For example,
one of the largest residential ISPs in the US (Comcast) does not change
the public IPv4 address of their subscribers.  If/when they start NATting
their subscribers, I would expect they would not change subscriber IP
addresses very often.  Thus, they could configure their PCP server to
allow long lifetimes (many hours).  For another example, other ISPs
like to interfere with their users running servers and rotate subscriber
IP addresses every 24 hours or so.  Those ISPs would configure their
PCP servers with shorter lifetimes, or could configure their PCP servers
to have lifetimes that expire at approximately the same time they will
change the subscriber's IP address.

If new software is being used by the subscriber which crashes often,
or is running on a mobile device (e.g., iPod) and might be taken out
of range of the home network, a reasonably-short lifetime 

> BTW, the text in the draft around the recommended max lifetime (7200s)
> should be elaborated to point the aside effects of allowing for longer
> lifetime.

Added:

<section title="Lifetime Management" anchor="lifetime_management">
<t>The PCP Client requests a certain lifetime, and the PCP Server responds
with the assigned lifetime.  The PCP Server can minimize and maximize
the requested lifetime.  It is suggested that a PCP Server enforce
a minimum lifetime of 3 minutes and a maximum lifetime of 24 hours,
but this is implmentation specific.</t>
<t>An application that forgets its PCP-assigned mappings (e.g.,
application or OS crashed) will request new PCP mappings (consuming
the user's port quota), and the application will likewise also
probably initiate dynamic connections to servers without using PCP
(also consuming the user's port quota).  PCP provides no explicit
protection against such port consumption.  In such environments, it is
RECOMMENDED that applications use shorter PCP lifetimes to reduce the
impact of consuming the user's port quota.</t>

> Having a lifetime of 194 days is still "huge" IMO.

Agreed.  But 18 hours is too short.  It's easier to implement on
8-bit boundaries, which is why I was suggesting 24 bits if we're going
to do anything.

-d

> >  request for a reasonable lifetime value, I propose the Lifetime
> field
> > to

---

From: Jacni Qin <[email-masked]>
Date: Wed, 29 Dec 2010 11:16:45 +0800

Re-,
inline please,

>   The PCP server SHOULD be configurable for permitted minimum and

Jacni>: A question for clarification, If the lifetime requested by the
client was longer than the maximum lifetime configured on the PCP server,
what happened?
Assign a port with the maximum lifetime pre-configured?
Or return an error? BTW, if so, It seems I can't find an appropriate error
code among those listed in issue #29.

Cheers,
Jacni

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 29 Dec 2010 18:36:48 +0100

=> assign it and return the lifetime in the response.

Regards