Subject: Re: [pcp] WG last call on draft-ietf-pcp-base-16.txt

From: Francis Dupont <[email-masked]>
Date: Tue, 01 Nov 2011 09:14:05 +0100

In your previous mail you wrote:

   > This is a big change and IMHO we must discuss it first to
   > understand if it is what we want.
   
   I agree with Stuart's proposed change (the main point of which is
   to keep retrying rather than give up).
   
=> my concern was more about the way this was proposed than about the
change itself...

Regards

[email-masked]

PS: I've put "was" because to work on PCP seems to be a total waste of
my time.

---

From: Paul Selkirk <[email-masked]>
Date: Wed, 02 Nov 2011 19:21:23 +0000

> => my concern was more about the way this was proposed than about the

I have concerns with both.

To Francis's point, this change was not proposed or discussed on the
mailing list, or even amongst the authors. Rather, it was slipped in as
a "minor edit for readability, spelling, consistency, ambiguity, etc."
It's not, it's a normative change to text that has been in since -07.

To the substance of the change, I find it bizarre that we would
recommend retrying forever. You may feel that 3 attempts and 14
seconds is too short, but I feel that infinite attempts and infite
seconds is too long. Certainly TCP doesn't retry forever.

On a practical level, a client API (library or system service) has to
give up and report failure to the application after some reasonable
period of time.

				paul

---

From: Dave Thaler <[email-masked]>
Date: Wed, 2 Nov 2011 23:17:08 +0000

Paul Selkirk writes:
> On a practical level, a client API (library or system service) has to give up and
> report failure to the application after some reasonable period of time.

No it doesn't.   You might have an API that behaves that way but it's absolutely
not the case that an API "has to" give up and report failure.

An example of an alternative API model is one that's event driven and tells the app
whenever the status changes.  I.e., notifies of success, notifies of port changes
(e.g., because you changed networks), etc.   There's no reason such an API has
to give up.

-Dave

---

From: Paul Selkirk <[email-masked]>
Date: Tue, 15 Nov 2011 16:18:45 +0000

On Wed, 2 Nov 2011 23:17:08 +0000, Dave Thaler wrote
> (e.g., because you changed networks), etc.   There's no reason such an API has

In a hallway conversation, Stuart told me he changed PCP to retry
forever because that's what NAT-PMP does.

However, this is what I actually found in draft-cheshire-nat-pmp-03.txt:
   To determine the external IP address or request a port mapping,
   a NAT-PMP client sends its request packet to port 5351 of its
   configured gateway address, and waits 250ms for a response. If no
   NAT-PMP response is received from the gateway after 250ms, the client
   retransmits its request and waits 500ms. The client SHOULD repeat
   this process with the interval between attempts doubling each time.
   If, after sending its 9th attempt (and then waiting for 64 seconds),
   the client has still received no response, then it SHOULD conclude
   that this gateway does not support NAT Port Mapping Protocol and
   MAY log an error message indicating this fact. In addition, if the
   NAT-PMP client receives an "ICMP Port Unreachable" message from the
   gateway for port 5351 then it can skip any remaining retransmissions
   and conclude immediately that the gateway does not support NAT-PMP.

So a NAT-PMP client SHOULD give up after a total of 9 attempts and
127.75 seconds.  It's not required to give up, and Apple's
implementation might in fact retry forever, but a conformant
implementation can quit there.

draft-cheshire-nat-pmp-03.txt goes on to say:
   When deleting a port mapping, the client uses the same initial 250ms
   timeout, doubling on each successive interval, except that clients
   may choose not to try the full nine times before giving up. This
   is because mapping deletion requests are in some sense advisory.

However, this distinction did not make its way into PCP. A conformant
PCP client is required to retry all requests, including deletes, until
it gets a response, full stop (or rather, without stop).

A final point arising from the NAT-PMP comparison is that PCP is silent
on how to handle Port Unreachable errors. Common sense would say that
the client could give up immediately. OTOH, the "retry forever" logic
suggests that the client should keep trying until the server restarts.
Is this something we need to address, or should we let common sense
prevail?

				paul