Re: [pcp] Resolving contentious issue #3

[Paul Selkirk <[e-mail]>]

> 3b: for the UPnP intern-etworking function, a mandatory bit would
> simplify the server side implementation because there will be less
> state to keep. Does this outweigh the added complexity in the
> protocol?

It's absolutely essential for the UPnP IWF.  The proposed mechanism in
draft-wing-pcp-design-considerations-00.txt, section 2.3.1, is
entirely unworkable and unrealistic.

It can be argued that UPnP apps that iterate through a small range of
ports are broken even today, and will be irrevocably broken by CGN.
But if we're going to support this behavior at all, there's no reason
to subject the PCP server to the thrash of multiple (unneeded and
unwanted) short-lived port mappings.  And the app won't wait around if
(as suggested) requests are throttled to one per second.

If the purpose is to break UPnP apps, then we can save a lot of time
and effort, and not define a UPnP IWF.

OTOH, if the purpose it to support UPnP apps to the extent possible,
then we need to respect the UPnP semantic that says "give me this port
or don't, but don't give me something else".

The "added complexity" argument is fallacious; this is dead simple to
understand, describe, and implement.

> It has been argued that UPnP apps would go away and be replaced by
> PCP apps, so we can envision a not too far future where the UPnP
> relay is not needed, so if the answer to 3a) is no, then PCP would
> be better off long term by not having a mandatory bit.

It has been argued that IPv4 would go away and be replaced by IPv6,
but here we are.

				paul