Subject: [pcp] PCP robustness for Rapid Recovery

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 May 2012 09:31:49 -0700

Another upcoming change for pcp-base was Pete Resnick's suggestion at IETF83
in the PCP meeting (and in the hallways prior to the PCP meeting), that PCP
be 'more robust' when the server noticed a mapping needed to be updated
(e.g., when the NAT's public IP address changed or when the PCP server lost
state).

As background, Rapid Recovery is the ANNOUNCE Opcode (sent when the PCP
server loses state) and the Mapping Update (the second response in the
"request-response-response" model of PCP, where the PCP server maintains
state but realizes that the mapping information has changed -- such as a new
IP address for the mapping).  The current specification is lenient regarding
Rapid Recovery and Mapping Update, describing both as somewhat optional and
unnecessary.  This is because the PCP philosophy has been that PCP should be
"as good as" sending a TCP SYN.  

Pete suggested that PCP can be better, and that PCP should be better -- that
is, the PCP specification should be changed to say  a PCP server "SHOULD"
implement Mapping Update (see Section 14.2 in draft-ietf-pcp-base-24), and
that it transmit those Mapping Update packets several times (to accommodate
packet loss).  Similarly, when sending the ANNOUNCE Opcode, change from "MAY
send up to 10 times" to "SHOULD transmit 10 times" (I believe the other text
for ANNOUNCE does not need changing).

Please let me know if there are objections to this change.

-d

---

From: Xiaohong Deng <[email-masked]>
Date: Wed, 9 May 2012 16:58:17 +0800

> for ANNOUNCE does not need changing).

Doubt about the necessity of this change, because for some cases, for
example, in case of a nested NAT where the middle level NAT acts both
as a client and a server, there is a need to implement the PCP server
in a light weight, and retransmitting 10 times doesn't look like a
necessity in such a case. So IMO, the word MAY would leave more rooms
for implementers' decision case by case.

My five cent.
-Xiaohong

Open source mB4 for Multicast DS-Lite: http://sourceforge.net/projects/mb4/
Open source PCP: http://sourceforge.net/projects/pcpclient/
Open source A+P: http://opensourceaplusp.weebly.com/
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

--

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 May 2012 08:18:16 -0700

> -----Original Message-----
> From: Xiaohong Deng [mailto:[email-masked]]
> Sent: Wednesday, May 09, 2012 1:58 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pcp] PCP robustness for Rapid Recovery
> 

Sorry -- are you saying you agree with the change in general, and 
would like a lower recommended value than 10?

-d

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 09 May 2012 11:51:39 -0700

> (e.g., when the NAT's public IP address changed or when the PCP  

Pete made good points. Today he runs servers at home, with static IP  
addresses.

Other people run servers at home by manually configuring their NAT  
gateway with static port mappings.

PCP offers a way to automate this, which is great, but *not* if it  
results in hours of server downtime.

Pete wants a NAT gateway with PCP to work at least as well as a NAT  
gateway with manual static port mappings. In other words, after a NAT  
gateway reboot Pete wants his servers reachable again within a few  
seconds, not a few hours.

If it takes PCP an hour or two to restore mappings lost after a NAT  
gateway reboot, then all the "expert" advice is going to be, "Forget  
PCP: make manual static port mappings just like you used to."

If we want PCP to be taken seriously, it has to compete credibly with  
today's status quo.

(Note that NAT-PMP had Rapid Recovery from the start, so it never  
suffered this criticism.)

> Please let me know if there are objections to this change.

I think Pete is right. These changes should be made.

Changing MAY to SHOULD does not in any way change what anyone's code  
has to do. Both are optional. It does however set the a particular  
editorial tone for the document. When a customer tells a vendor  
they'd like the NAT gateway not take an hour or two to recover after  
a reboot, the MAY/SHOULD language signifies whether or not we, as a  
group, believe that's a reasonable thing to want. Using "MAY"  
suggests that we think taking an hour or two to recover is  
acceptable, and wanting it to recover faster is specialized and  
unusual. Using "SHOULD" suggests that we think it's reasonable and  
normal to want the NAT gateway to recover quickly.

I vote for "SHOULD". I want PCP to work really well. I don't want it  
to be the protocol where all the "experts" know that you're better  
off ignoring it and using manual static port mappings instead.

Stuart Cheshire

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 09 May 2012 14:30:53 -0700

PCP needs to be a suitable replacement for static port forwarding
otherwise it will severely weaken PCP applicability. That's why I pushed
for web portals, rapid recovery and third_party. I'm glad that Pete's
statement finally resonated.

PCP also needs to work through non-PCP capable NATs.

---

From: Xiaohong Deng <[email-masked]>
Date: Thu, 10 May 2012 11:56:15 +0800

> would like a lower recommended value than 10?

Yes, I agree the changes in general proposed by Pete are pretty good.

And yes, after comments coming up from Stuart in this thread to vote
using the wording  ‘SHOULD’, for conveying idea of the importance of
PCP’s reliability, which I agree, I vote for lowering recommended time
below 10.  Reasons are below.

10 would be a good recommended value for recovering from network
failure, given the typical retransmission times for the sake of
assuring network reliability. For example,  minimal 3 and maximal 15
are set as TCP retransmission default values, according to previous
RFC and work pretty well in most current and wide deployed practice,
e.g., linux since 2.2.  However, PCP server’s performance limits on
handling concurrent sessions would be another major cause of
retransmission. In this case, thousands of clients concurrently
retransmitting up to 10 after a PCP server has already reached its
limits would, on the opposite, slow down PCP server’s rapid recovery.
Therefore, a compromised recommended value, let’s say 5, taking into
account these two causes IMO, would do better.

My 5 cent.
-Xiaohong

--

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 May 2012 07:59:55 -0700

> Sent: Wednesday, May 09, 2012 8:56 PM
> To: Dan Wing
> >> > Another upcoming change for pcp-base was Pete Resnick's suggestion
> at
> >> IETF83
> >> > As background, Rapid Recovery is the ANNOUNCE Opcode (sent when
> the
> >> PCP
> >> > state but realizes that the mapping information has changed --
> such
> >> as a new
> >> > Pete suggested that PCP can be better, and that PCP should be
> better
> >> -- that

The clients will only react once, no matter how often the server
re-transmits is ANNOUNCE message.  This is because once a client 
receives the first ANNOUNCE, the Epoch Time is "wrong" (too high
or too low) which will cause the client to re-establish its
PCP mappings.  However, subsequent retransmissions of ANNOUNCE
will have the expected Epoch Time value, and will not cause a
reaction by the PCP client (that is, the PCP client will not
send new PCP requests because of that ANNOUNCE).  

  PCP client               PCP server
      |                         |
      |-----MAP---------------->|
      |<-Ok, Epoch=123456-------|
      |                         |
    ...                        ...
    ... (hours later)          ...
    ...                        ...
      |                         | 
      |                     (power lost)
      |                  (power restored)
      |                         |
      |<--ANNOUNCE, Epoch=0-----|
      |   (multicasted)         |
      |                         |
   (Uh-oh.  that PCP            |
    server's Epoch is           |
    wrong.  It must             |
    have lost state.)           |
      |                         |
      |-----MAP---------------->|
      |<-Ok, Epoch=123456-------|
      |                         |
      |<--ANNOUNCE, Epoch=1-----|
      |   (multicasted)         |    
      |                         |
   (that PCP server's           |
    Epoch is correct)           |
      |                         |
      |<--ANNOUNCE, Epoch=2-----|
      |   (multicasted)         |    
      |                         |
   (that PCP server's           |
    Epoch is correct)           |
      |                         |
      |<--ANNOUNCE, Epoch=4-----|
      |   (multicasted)         |    
      |                         |
   (that PCP server's           |
    Epoch is correct)           |
      |                         |
    ...

> account these two causes IMO, would do better.

With the explanation above, do you still want the PCP server to
only send it 5 times?

A problem with sending the unsolicited ANNOUNCE is the PCP server
has no way to determine if all the clients have seen the message.

-d

---

From: Xiaohong Deng <[email-masked]>
Date: Fri, 11 May 2012 14:51:34 +0800

>      |<--ANNOUNCE, Epoch=4-----|

I see..

> With the explanation above, do you still want the PCP server to

Thanks for the explanation. It certainly eliminates my previous
concern of PCP server's handling too many concurrent replies. Then 10
is pretty good recommend value as per reason pointed out previously.

> has no way to determine if all the clients have seen the message.

Yes, this adds another point to stick to a fairly high recommend value
than a lower one.

-Xiaohong

--

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 May 2012 09:02:34 -0700

...
> >      |<--ANNOUNCE, Epoch=4-----|

To make that clearer, -25 includes the additional sentence

   If the Epoch time value is within the expect range for that 
   server, the PCP client does not recreate its mappings.

> is pretty good recommend value as per reason pointed out previously.

Ok.

-d

---

From: Xiaohong Deng <[email-masked]>
Date: Sun, 13 May 2012 12:02:51 +0800

>   server, the PCP client does not recreate its mappings.

Perfect. Thanks.

-Xiaohong