Re: [pcp] PCP-base 02: Section 7.7

[<[e-mail]>]

Hi Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[e-mail]] 
Envoyé : mardi 11 janvier 2011 18:35
À : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Francis Dupont'; 'Simon Perreault'
Cc : [e-mail]
Objet : RE: [pcp] PCP-base 02: Section 7.7

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, January 10, 2011 10:55 PM
> To: Dan Wing; 'Francis Dupont'; 'Simon Perreault'
> Cc: [e-mail]
> Subject: RE: [pcp] PCP-base 02: Section 7.7
> 
> Hi Dan,
> 
> As a reminder, I have enumerated a set of advantages of implementing
> what was called option 2 (http://www.ietf.org/mail-
> archive/web/pcp/current/msg00483.html).
> 
> In http://www.ietf.org/mail-archive/web/pcp/current/msg00487.html, I
> tried to explain that implementing option 1 may not reduce keepalives
> in some contexts since the refresh interval is forced by the server and
> not by the client (see SIP example for instance).

Thanks for the pointers.

The first URL says:

    > I don't know how we can forbid applications to use option 2
    > which is the obvious one to avoid overloading service
    > elements with keepalive messages!
    >
    > As a concrete example: In the current VoIP deployments SBC
    > or P-CSCF forces the SIP User Agent to send frequent
    > REGISTER messages (setting a small value of expire timer);
    > these messages are not forwarded to the core service
    > elements. The main purpose is to maintain the NAT binding
    > in case a NAT is traversed alive. Both the NAT and SBC are
    > overloaded with these keepalive messages. For the NAT side
    > this may not be an issue when the NAT is embedded in the
    > CPE but this may be become sensitive for the CGN case.
    >
    > If PCP is used to instruct a mapping before issuing the
    > REGISTER message: (1) the CGN is not overloaded, (2)
    > service contact point is not overloaded, (3) the client can
    > use the external IP address/port to build its application
    > messages (e.g., SIP) and thus no need to implement extra
    > function in the service side (e.g., SBC) or in the CGN
    > (e.g., SIP ALG), (4) the service elements can detect the
    > present of non-transparent NAT by comparing the content of
    > the message with the source IP/port information, (5) the
    > client is aware of the lifetime of the mapping in the CGN
    > which important to avoid sending aggressive keeplines
    > (e.g., 20s for Ipsec clients), etc.

and the second URL reinforces that connect-then-lifetime does not
have property (3).

Here is how I see property (3) implemented when doing connect-then-lifetime,
following the REGISTER
procedure described at
http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-13#page-16

  SIP UA                          PCP server    SIP proxy
    |                                 |             |
    |--SIP REGISTER, rport------------------------->|
    |<-Ok, port=12345-------------------------------|
    |                                 |             |
    |-PIN44, REMOTE_PEER=<sip proxy>->|             |
    |<--lifetime=3600, ext-port=12345-|             |
    |                                 |             |

What is the disadvantage of reducing SIP keepalives that way?

Med: The use of "rport" allows the SIP Proxy to answer to the source port number and not to the one indicated in the via header but it does not help the SIP proxy server to detect the lifetime of the nat binding in the path; therefore a lower expire timers (e.g., 30 or 60s) will be returned by the SIP Proxy to the SIP UA to maintain such binding. The SIP UA has to refresh its registration before the expiry of the returned expiry timer. The PCP request does not help in such case. In some deployments "rport" is not used but SBCs "emulate" a similar functionality but this does not prevent frequent re-registration messages (not forwarded to the core service elements btw). Keepalive messages have a SEVERE impact on the performance of the SBC (60% degradation). This is why I prefer to present a SIP message to the SIP proxy without rport but with the external IP/port assigned by the nat in the path. This would be a hint for the proxy server to return an expire timer with greater value.


For RTP, message flow would be like this, again doing connect-then-lifetime.
The difference is we don't get anything like an "rport=NNN" from the remote
peer.  But, we don't need it anyway except to detect a rogue NAT on the path
between the PCP-controlled NAT and the RTP peer.  If the SIP UA wanted to
detect such a rogue NAT, it would need to send ICE (STUN) messages to the
RTP peer.

Med: Why not doing it simple, use the even_plus_one option to get the ports; use those ports to build the offer/answer and issue the request. We don't need ICE/STUN/etc. 

  SIP UA                          PCP server     RTP peer
    |                                 |             |
    |--RTP message--------------------------------->|
    |--RTP message--------------------------------->|
    |--... more RTP messages ...------------------->|
    |--RTP message--------------------------------->|
    |                                 |             |
    |-PIN44, REMOTE_PEER=<rtp peer>=->|             |
    |<--lifetime=3600, ext-port=12345-|             |
    |                                 |             |

As with SIP, the SIP UA does not need to be in a hurry to communicate with
the PCP server.

-d


> Cheers,
> Med
> 
> -----Message d'origine-----
> De : Dan Wing [mailto:[e-mail]]
> Envoyé : mardi 11 janvier 2011 01:03
> À : 'Francis Dupont'; 'Simon Perreault'; BOUCADAIR Mohamed OLNC/NAD/TIP
> Cc : [e-mail]
> Objet : RE: [pcp] PCP-base 02: Section 7.7
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Francis Dupont
> > Sent: Monday, January 10, 2011 3:02 PM
> > To: Simon Perreault
> > Cc: [e-mail]
> > Subject: Re: [pcp] PCP-base 02: Section 7.7
> >
> >
> >  In your previous mail you wrote:
> >
> >    Note that this was discussed in the virtual interim meeting. I
> seem
> > to
> >    recall the consensus being that the advantage of easy deployment
> >    outweighed the disadvantages.
> >
> > => I am afraid this argument would not close the subject...
> > and there was no consensus, just a 'go to next point'.
> >
> >   (Were the minutes of the meeting posted?)
> >
> > => +1!
> >
> > [e-mail]
> >
> > PS: BTW the 'ease of deployment' is not a good argument as it applied
> > only on hosts, not on NATs, when IMHO at least 50% of the deployed
> > base won't support it.
> 
> For reference, this is Issue #17,
> http://trac.tools.ietf.org/wg/pcp/trac/ticket/17
> 
> In the post http://www.ietf.org/mail-
> archive/web/pcp/current/msg00474.html,
> Simon described the host implementation difficulty.  This got agreement
> from
> Dave Thaler, http://www.ietf.org/mail-
> archive/web/pcp/current/msg00475.html
> and Lars Eggert,
> http://www.ietf.org/mail-archive/web/pcp/current/msg00480.html.
> 
> I do not find a post that describes the NAT implementation difficulty.
> 
> I found posts that suggest NATs want to have different port ranges for
> PCP-controlled ports than for dynamically-created connections.  That's
> makes
> some sense when the user is operating a server.  But I don't understand
> how
> separate NAT port ranges are helpful/necessary for the application
> keepalives case.
> 
> If this does help the NAT, it seems we will need to force (MUST) the
> hosts
> to allocate a source port in the non-ephemeral port range and follow
> the
> other steps described in
> http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html.
> 
> -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.
> ********************************


*********************************
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.
********************************