Subject: [pcp] UPnP IGD interworking function

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Dec 2010 17:24:52 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 26, 2010 2:59 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] draft-wing-pcp-base-01 posted
> 
> Many comments about base-01 (I suggest to not answer in one message!):
...
> 13.  Interworking with UPnP IGD
> 
>    The following diagram shows how UPnP IGD can be interworked with
> PCP,
>    using an interworking function (IWF).
> 
> => as you read the new specs, is it something specified in case
> of host/IWF reboot? For instance, is the IWF supposed to keep
> state? to announce it lost its state?

The interworking function is supposed to look like a UPnP IGD
to UPnP control points (clients), and supposed to look like 
a PCP client to the PCP server.

I don't care if it can be stateful or stateful.  I don't see
how it could be stateless, though.  UPnP IGD does not have
a lifetime, yet PCP has a lifetime.  A stateful interworking
function would remember the PCP lifetime and renew the 
lifetime.  

>    support UPnP IGD 2.0 (which has improved behavior, see Section 13.2)
> 
> => I am happy the 2.o was adopted (now I haven't yet read it so
> perhaps I shan't remain happy :-).
> 
> 13.3.  Lifetime Maintenance
> 
>    UPnP IGD does not provide a lifetime, so the UPnP IGD/PCP
>    interworking function is responsible for extending the lifetime of
>    mappings that are still interesting to the UPnP IGD device.
> 
>       Note: It can be an implementation advantage, where possible, for
>       the UPnP IGD/PCP interworking function to request a port mapping
>       lifetime only while that client is active and connected.  For
>       example, creating a PCP mapping that is equal to the client's
>       remaining DHCP lifetime is one useful approach.  The UPnP IGD/PCP
>       interworking function is responsible for renewing the PCP
> lifetime
>       as necessary.  As long as client renews its DHCP lease, the PCP
>       lifetime should also be extended.  For clients not using DHCP,
>       other mechanisms to check on the client host's liveliness can
> also
>       be useful (e.g., ping, ARP, or WiFi association) can be used to
>       discern liveliness of the UPnP IGD control point.  However, it is
>       NOT RECOMMENDED to attempt to connect to the TCP or UDP port
>       opened on the control point to determine if the host still wants
>       to receive packets; the server could be temporarily down when
>       tested, causing a false negative.
> 
> => I am not against garbage collection (I wrote papers on it) but
> I prefer to be sure it is the intended behavior in UPnP IGD.
> So where is it in specs? (I can't find something in 1.0 specs
> and Reinaldo didn't get the time to present the last point
> in the interim meeting agenda which could help me)

What is the "it" you're referring to?  Is "it" the indented "Note:"
quoted from the draft?  Or something else?

...
> PS: I have a concern about amnesiac clients, i.e., a client which
> sends a request for a PF it already has:

Seems indistinguishable from a lost PCP response, such as:

  PCP client                 PCP server
      |                           |
      |-----request-------------->| 
      |   (dropped)<-response-----|
      |--re-transmitted request-->|
      |                           |

>  - there is a simple way to recognize them from renewals:
>   the requested fields are filled with the right values in renewals
>  - a way to recognize the PF is needed: I propose to use the internal
>   address and port, i.e., the same fields than for a delete
>  - so the issue is about what to do when the requested port is not
>   the same and not zero (BTW this issue is in fact independent of
>   the mandatory bit stuff: even with a hint we are in trouble):
>   * return an error saying 'you should have lost your state'
>    (and the state recovery will fix it)
>   * return the already existing PF (IMHO not good at it can be
>    something different from has been wanted)
>   * delete the already existing PF and create a new one
>    (IMHO very bad: likely not what has been wanted)
>  - there is an extra case where the already existing PF is in hold down
>   (IMHO in this case it should be ignored)
> BTW some UPnP IGD clients are known to exhibit this behavior.

Can the UPnP IGD interworking function contain this client misbehavior?

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Dec 2010 11:15:55 +0100

> state? to announce it lost its state?
   
=> BTW I read the new specs and the IWF is not required to keep state
(so it is not supposed to keep state in stable storage as it runs
on a device without reliable/usable stable storage).

   >    UPnP IGD does not provide a lifetime, so the UPnP IGD/PCP

=> note this is wrong.

   
=> this is true only for renewals, i.e., if you replace in my text
renewals but lost PCP response you get the same thing.
So I disagree: it is distinguishable from lost responses.
   
   >   the requested fields are filled with the right values in renewals

=> s/renewals/renewals or resent requests from lost responses/

   
=> yes but the IWF needs to get the state from the PCP server
according to the previous item.
   
Regards

[email-masked]