Subject: [pcp] discuss: even plus one

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Dec 2010 11:18:47 -0800

This is one of the PCP discussion points.

RTP (RFC1889, RFC3550) expects to use an even-numbered port and expects 
its control channel (RTCP) to be on the next higher (odd-numbered) port.
This can be overridden with the SDP attribute a=rtcp (RFC3605), but this
SDP attribute is not ubiquitously supported.  Additionally, some new
mechanisms such as RFC5760 also make a port+1 assumption (there is
ongoing work with draft-ietf-avt-rtcp-port-for-ssm to allow signaling
the RTCP port).  There are also non-SDP protocols, such as H.323, which
use RTP and expect to use port+1.

Because of the fear of interworking with a device that doesn't support
signaling an alternate RTCP port, it seems prudent that PCP include
an option for the PCP client to request an even numbered port (for
RTP) and an adjacent port+1 (for RTCP) from its PCP server.  

The only other protocols that appear to need multiple ports allocated
are protocols that use separate ports for their unencrypted and
encrypted flavors (e.g., HTTP/HTTPS, IMAP/IMAPS, etc.).  But their
ports don't need to be adjacent, nor do they need to be even-numbered
or odd-numbered.  

Please comment on the above.

To work with such RTP implementations (that expect RTP to use an even-
numbered port and RTCP to use port+1), I propose this be done with 
a PCP option called EVEN_PLUS_ONE.  This option will be sent in
a PCP request.  If the server supports this option, the server
will find an available even-numbered port that has an adjacent
available port+1.  The server will return the port number of
the even port in the PCP response, and the server will block
the odd numbered port from being allocated by any other user
(that is, only the same PCP client IP address could request
that odd numbered port). The PCP client will then send a separate 
PCP request to allocate that port+1 and indicate its internal port 
number for the mapping.

Please comment on the above solution.

-d

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 11:30:13 +0100

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : mardi 7 décembre 2010 20:19
À : [email-masked]
Objet : [pcp] discuss: even plus one

Med: I fully agree with this. FWIW, this has been discussed in this list: please see http://www.ietf.org/mail-archive/web/pcp/current/msg00174.html.
Having this capability supported in PCP would avoid "completely" to embed and ALG in the PCP-controlled device and also to avoid service elements (e.g., SBC, P-CSCF) to enable HNT which impacts drastically the performance of those nodes (a decrease up to 60%).

Med: Unlike the RTP/RTCP case, this scenario can be covered by issuing several PCP requests. As an optimisation, I would personally vote for what has been described in http://tools.ietf.org/html/draft-wing-softwire-port-control-protocol-02#section-5.2.1 (allow to ask for pairs of ports up to a hard-coded MAX. The format should be modified to indicate the number of included pairs.)

that odd numbered port). 
The PCP client will then send a separate 

Med: The second PCP request can be avoided. The behaviour would be as follows:

* A PCP Client includes an EVEN_PLUS_ONE IE in a request to indicate to the server than two contiguous ports should be reserved
* If the IE is not supported by the PCP Server, an indication is sent in the response.
* If the IE is supported by the PCP Server, two ports are reserved: odd/even. The even port is sent back to the PCP Client.
* Upon receipt of the response, the PCP Client can use the signalled even port and the even+1.
* To delete the mapping, the PCP Client includes the EVEN_PLUS_ONE IE in the request together with the assigned port number.
* The PCP Server proceeds to deleting the included even port number and even+1.
*********************************
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.
********************************

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 18:20:23 +0100

In your previous mail you wrote:

=> I propose (again) to simplify this a bit: allocate the two ports
with the EVEN_PLUS_ONE request/response exchange. BTW this solves
a detail about "the same PCP client IP address" which is not what
we want, i.e., it is better to require the original requestor is the
same, something which is implicitely enforced with one request only.
Note this removes a freedom about the second internal port but it
doesn't matter for the intented use.

So I propose to change:

       The server will return the port number of

by:

       The server will allocate the two ports and will return
   the even port and the EVEN_PLUS_ONE option in the PCP response.
   The internal port+1 will be mapped to the odd port (== even port+1).

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Dec 2010 09:27:20 -0800

...
> * A PCP Client includes an EVEN_PLUS_ONE IE in a request to indicate to
> the server than two contiguous ports should be reserved
> * If the IE is supported by the PCP Server, two ports are reserved:
> odd/even. The even port is sent back to the PCP Client.

That optimization would only work if that initial PCP request indicated
both of the PCP client's internal port numbers.  That is, it only works
if we add support for creating multiple mappings in one PCP Request 
message as you suggested earlier in your email.  I'm not a chair, but
I do not sense consensus on doing that.

Here is the text I have written for pcp-base-01 for 'even plus one':

12.  PCP Options

   This section defines PCP Options.  More options can be defined in
   other documents as specified in Section 15.

12.1.  EVEN_PLUS_ONE

   RTP [RFC3550] has historically used an even-numbered port, and RTCP
   the next-higher port (often abbreviated as "port + 1").  Some
   equipment still expects RTP/RTCP on adjacent ports.  To accommodate
   that, the PCP Option EVEN_PLUS_ONE can be used by the PCP client and
   server, with the following procedure.

      [Ed.  Note: Are there any other protocols that need adjacent
      ports?]

   The procedure is for the PCP client to bind to two ports on its local
   interface.  It then sends a PCP request for external port 0
   (indicating it will accept any port from the server) for one of those
   internal ports and includes the PCP Option EVEN_PLUS_ONE with this
   request.  If the server understands this option, it will choose an
   even-numbered external port and will reserve the next-higher port
   with a short timeout (suggested duration is 10 seconds) for this same
   PCP client to allocate in a subsequent PCP request.  The PCP server
   sends a response and indicates it performed that operation by
   including the PCP Option EVEN_PLUS_ONE in the response.  The PCP
   client then sends a second PCP request for the next-higher external
   port.  Refreshing the lifetime for both of these ports works as
   normal.
                      
   A diagram of the message flow:

            PCP Client                               PCP Server
               |                                          |
               |----request ext-port=0, EVEN_PLUS_ONE---->|
               |<-response ext-port=23456, EVEN_PLUS_ONE--|
               |----request ext-port=23457--------------->|
               |<-response ext-port=23457-----------------|
               |                                          |

                  Figure 11: Message Flow, EVEN_PLUS_ONE

   The PCP Option EVEN_PLUS_ONE always has an Option-Length of 0.  When
   the PCP client wants an even-numbered port and the next-higher
   adjacent port, it includes the PCP Option EVEN_PLUS_ONE in its PCP
   request.  If the server understands the option, has successfully
   mapped an even-numbered external-port, and temporarily reserved the
   next-higher port for this PCP client, the server MUST include the
   EVEN_PLUS_ONE Option in its response.  If the server understands the
   option, but was unsuccessful at mapping an even-numbered port or
   unsuccessful at temporarily reserving the next-higher port for this
   PCP client, the server MUST NOT include the EVEN_PLUS_ONE Option in
   its response.  If the server receives a PCP request with the
   EVEN_PLUS_ONE option for an odd-numbered requested-external-port, it
   MUST return an error.

If consensus becomes that we don't want/need this PCP option, it's
easy to remove this section.  

I don't know if this Option should be Mandatory To Implement in the
server.  It is obviously Optional To Implement in a client, even
an RTP client if it has high confidence that its peers support
a=rtcp (or a similar semantic in some non-SDP signaling protocol).

-d

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 19:06:56 +0100

Re-,

Please see inline.

Cheers
Med
________________________________________
De : Dan Wing [[email-masked]]
Date d'envoi : mercredi 8 décembre 2010 18:27
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: [pcp] discuss: even plus one

...

Med: Because the only application we are targeting with this is RTP/RTCP, we can assume that the internal port for RTCP is assumed to be the one included in the PCP request + 1. There is no need to signal both internal ports in the same request.  If you think this would complicates the procedure, let's keep what you have proposed so far. 

Med: Except the optimization above, your proposed text is fine with me.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 20:38:07 +0100

* To delete the mapping, the PCP Client includes the EVEN_PLUS_ONE
     IE in the request together with the assigned port number.

=> if I agree with the proposal I make an exception for the delete
(it is a marginal optimization).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Dec 2010 12:25:30 -0800

...
> Med: Because the only application we are targeting with this is
> RTP/RTCP, we can assume that the internal port for RTCP is assumed to
> be the one included in the PCP request + 1. There is no need to signal
> both internal ports in the same request. 

Thanks for explaining, I hadn't understood that assumption previously.

> If you think this would
> complicates the procedure, let's keep what you have proposed so far.

I don't want to propagate RTP's initial sin of assuming port numbers.

> Med: Except the optimization above, your proposed text is fine with me.

Ok.

-d

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Thu, 9 Dec 2010 22:23:50 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dan Wing (dwing)
Sent: Wednesday, December 08, 2010 3:26 PM
To: [email-masked]; [email-masked]
Subject: Re: [pcp] discuss: even plus one

...
> > * Upon receipt of the response, the PCP Client can use the signalled

> > even port and the even+1.
> 
> That optimization would only work if that initial PCP request 
> indicated both of the PCP client's internal port numbers.  That is, it

> only works if we add support for creating multiple mappings in one PCP

> Request message as you suggested earlier in your email.  I'm not a 
> chair, but I do not sense consensus on doing that.
> 

[Senthil] But you are already assuming that by allocating the
consecutive port on the
PCP server. I don't see an advantage of the PCP client sending a second
message for 
an internal port. When the PCP client chooses to use EVEN_PLUS_ONE then
it implies
that the current internal port and internal port + 1 should be mapped to
an
external port and external port + 1. The only application that we know
of currently
that needs consecutive ports is RTP/RTCP and optimizing for that case
seems 
reasonable. For the other applications that require non-consecutive
ports can use 
the two message approach. 

Ok.

-d

_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: <[email-masked]>
Date: Mon, 20 Dec 2010 14:53:49 +0800

Dear Dan,

You mentioned "reserve the next-higher port with a short timeout " in the following text,  I wonder if the next-higher port is only reserved on the PCP server's memory  or a NAT binding is really created on the NAT device? I guess it indicates a NAT binding is really created on NAT device because otherwise on the NAT device  the next-higher port will probably be assigned to other clients for example triggered by TCP sync, even if it's reserved on PCP server's memory for this client.

>If the server understands this option, it will choose an even-numbered 
>external port and will reserve the next-higher port  with a short 
>timeout (suggested duration is 10 seconds) for this same  PCP client to 
>allocate in a subsequent PCP request.

I have similar doubt about reserving companion ports as it says "which MAY reserve (but not forward) the companion port "  in the section 7.4 of base-01 draft. But in case of companion port, because it's uncertain that if the companion port will be requested later, I assume it suggests only reserving companion port on PCP server's memory instead of creating a NAT binding on the NAT device. 

>In 7.4. OpCode-Specific Server Operation Nevertheless, a configurable 
>feature MAY be supported by the PCP- controlled device, which MAY 
>reserve (but not forward) the companion port so the same PCP Client can 
>request it in the future.

Am I wrong in assumptions about reserving the next-higher/companion ports in these two cases?

BR,
Xiaohong

---------- Forwarded message ----------
From: Dan Wing <[email-masked]>
Date: Thu, Dec 9, 2010 at 1:27 AM
Subject: Re: [pcp] discuss: even plus one
To: [email-masked], [email-masked]

...
> * A PCP Client includes an EVEN_PLUS_ONE IE in a request to indicate 
> to the server than two contiguous ports should be reserved

That optimization would only work if that initial PCP request indicated both of the PCP client's internal port numbers.  That is, it only works if we add support for creating multiple mappings in one PCP Request message as you suggested earlier in your email.  I'm not a chair, but I do not sense consensus on doing that.

12.  PCP Options

12.1.  EVEN_PLUS_ONE

           PCP Client                               PCP Server
              |                                          |

If consensus becomes that we don't want/need this PCP option, it's easy to remove this section.

I don't know if this Option should be Mandatory To Implement in the server.  It is obviously Optional To Implement in a client, even an RTP client if it has high confidence that its peers support a=rtcp (or a similar semantic in some non-SDP signaling protocol).

-d

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Dec 2010 10:54:53 +0100

You mentioned "reserve the next-higher port with a short timeout "
   in the following text, I wonder if the next-higher port is only
   reserved on the PCP server's memory or a NAT binding is really
   created on the NAT device? I guess it indicates a NAT binding is
   really created on NAT device because otherwise on the NAT device
   the next-higher port will probably be assigned to other clients for
   example triggered by TCP sync, even if it's reserved on PCP
   server's memory for this client.
   
=> it is very implementation dependent. IMHO Dan's wording is the good
one (it describes what you get, not how you can get it). BTW if PCP
uses a dedicated range of ports (something I guess to be common) there
is no issue.

   I have similar doubt about reserving companion ports as it says

=> I agree it is the same issue (and the idea comes from NAT-PMP).
   
   Am I wrong in assumptions about reserving the next-higher/companion
   ports in these two cases?
   
=> yes, you focus on one way to implement this kind of features.

Regards

---

From: <[email-masked]>
Date: Tue, 21 Dec 2010 18:46:01 +0800

Hi, Francis,

Nice to know your opinions! Please see my comments in line. 

|-----邮件原件-----
|发件人: [email-masked] [mailto:[email-masked]] 
|发送时间: 2010年12月20日 17:55
|收件人: DENG Xiaohong ESP/PEK
|抄送: [email-masked]; [email-masked]; WANG Lan ESP/PEK
|主题: Re: [pcp] discuss: even plus one 
|
|
| In your previous mail you wrote:
|
|   You mentioned "reserve the next-higher port with a short timeout "
|   in the following text, I wonder if the next-higher port is only
|   reserved on the PCP server's memory or a NAT binding is really
|   created on the NAT device? I guess it indicates a NAT binding is
|   really created on NAT device because otherwise on the NAT device
|   the next-higher port will probably be assigned to other clients for
|   example triggered by TCP sync, even if it's reserved on PCP
|   server's memory for this client.
|   
|=> it is very implementation dependent. IMHO Dan's wording is 
|the good one (it describes what you get, not how you can get 
|it). BTW if PCP uses a dedicated range of ports (something I 
|guess to be common) there is no issue.

Yes, you are right and the question is from implementation point of view. 
But when it comes to dedicated range of ports, do you have anything in mind about how to differentiate TCP sync created ports and PCP dedicated range?
IMHO, it's not easy to decide a proper PCP dedicated range. It's obvious impractical to reserve all registered ports 1024~49151 to PCP dedicated range as ports become scare resources. On the other hand, from users' point of view, they'd better know which range is reservable otherwise they are likely to fail many times, especially when the range is small, before find one reservable port in the PCP dedicated range.

|
|   I have similar doubt about reserving companion ports as it says
|
|=> I agree it is the same issue (and the idea comes from NAT-PMP).

Yes, and thanks again for the NAT-PMP release implemented by you. :)

|   
|   Am I wrong in assumptions about reserving the next-higher/companion
|   ports in these two cases?
|   
|=> yes, you focus on one way to implement this kind of features.

I suppose you mean ports really reserved on NAT in both cases.

|
|Regards
|
[email-masked]
|

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Dec 2010 12:23:36 +0100

But when it comes to dedicated range of ports, do you have anything
   in mind about how to differentiate TCP sync created ports and PCP
   dedicated range?

=> configuration (in the next version of our AFTR software (external)
ports are divided into:
 - a range for dynamic mappings
 - a range for PCP mappings
 - remaining ports are available for (config file) static mappings

   IMHO, it's not easy to decide a proper PCP dedicated range. It's
   obvious impractical to reserve all registered ports 1024~49151 to
   PCP dedicated range as ports become scare resources. On the other
   hand, from users' point of view, they'd better know which range is
   reservable otherwise they are likely to fail many times, especially
   when the range is small, before find one reservable port in the PCP
   dedicated range.
   
=> it is the same than for quota/global resources, i.e., you have
the same issue for the dynamic mapping limits. IMHO 10 to 20 PCP
mappings per subscriber is the high limit. As lifetimes are
greater you should use a small multiplexing factor, for instance
make provision for 10 PCP mappings per subscriber in the range size
with a quota of 20.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 21 Dec 2010 08:14:38 -0800

...
> But when it comes to dedicated range of ports, do you have anything in
> mind about how to differentiate TCP sync created ports and PCP
> dedicated range?
> obvious impractical to reserve all registered ports 1024~49151 to PCP
> dedicated range as ports become scare resources. On the other hand,
> from users' point of view, they'd better know which range is reservable
> otherwise they are likely to fail many times, especially when the range
> is small, before find one reservable port in the PCP dedicated range.

If their PIN* request uses requested-external-port=0, they will be
given a port immediately with one round-trip  There is simply no reason 
for PCP clients to ask for a specific port -- they won't get it because
the port is likely to already be assigned to someone else.

-d

---

From: <[email-masked]>
Date: Wed, 22 Dec 2010 19:48:21 +0800

|-----邮件原件-----
|发件人: Dan Wing [mailto:[email-masked]] 
|发送时间: 2010年12月22日 0:15
|收件人: DENG Xiaohong ESP/PEK; [email-masked]
|抄送: [email-masked]; WANG Lan ESP/PEK
|主题: RE: [pcp] discuss: even plus one 
|
|...
|> Yes, you are right and the question is from implementation point of 
|> view.
|> But when it comes to dedicated range of ports, do you have 
|anything in 
|> mind about how to differentiate TCP sync created ports and PCP 
|> dedicated range?
|> IMHO, it's not easy to decide a proper PCP dedicated range. It's 
|> obvious impractical to reserve all registered ports 
|1024~49151 to PCP 
|> dedicated range as ports become scare resources. On the other hand, 
|> from users' point of view, they'd better know which range is 
|> reservable otherwise they are likely to fail many times, especially 
|> when the range is small, before find one reservable port in 
|the PCP dedicated range.
|
|If their PIN* request uses requested-external-port=0, they 
|will be given a port immediately with one round-trip  There is 
|simply no reason for PCP clients to ask for a specific port -- 
|they won't get it because the port is likely to already be 
|assigned to someone else.

Yes, except UPnP IGD interworking function using HONOR_EXTERNAL_PORT option to ask for a specific port.

|
|-d
|
|

---

From: <[email-masked]>
Date: Wed, 22 Dec 2010 19:49:06 +0800

|-----邮件原件-----
|发件人: [email-masked] [mailto:[email-masked]] 
|发送时间: 2010年12月21日 19:24
|收件人: DENG Xiaohong ESP/PEK
|抄送: [email-masked]; [email-masked]; WANG Lan ESP/PEK
|主题: Re: [pcp] discuss: even plus one 
|
|
| In your previous mail you wrote:
|
|   But when it comes to dedicated range of ports, do you have anything
|   in mind about how to differentiate TCP sync created ports and PCP
|   dedicated range?
|
|=> configuration (in the next version of our AFTR software 
|(external) ports are divided into:
| - a range for dynamic mappings
| - a range for PCP mappings
| - remaining ports are available for (config file) static mappings

In this case, you need to preserve a number of ports on each external IP address for PCP mappings range.

|
|   IMHO, it's not easy to decide a proper PCP dedicated range. It's
|   obvious impractical to reserve all registered ports 1024~49151 to
|   PCP dedicated range as ports become scare resources. On the other
|   hand, from users' point of view, they'd better know which range is
|   reservable otherwise they are likely to fail many times, especially
|   when the range is small, before find one reservable port in the PCP
|   dedicated range.
|   
|=> it is the same than for quota/global resources, i.e., you 
|have the same issue for the dynamic mapping limits. IMHO 10 to 
|20 PCP mappings per subscriber is the high limit. As lifetimes 
|are greater you should use a small multiplexing factor, for 
|instance make provision for 10 PCP mappings per subscriber in 
|the range size with a quota of 20.

Yet, how many PCP ports reserved on an external IP address? 20*number of subscriber using the same external IP address?
 I assume it's not easy to guess how many subscribers would use the same external IP address

|
|Regards
|

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Dec 2010 14:00:22 +0100

In this case, you need to preserve a number of ports on each external IP
   address for PCP mappings range.
   
=> yes, this is per external IP address (with defaults to make the config
easier to write).

   Yet, how many PCP ports reserved on an external IP address? 20*number of
   subscriber using the same external IP address?

=> 10*<#subscribers>

    I assume it's not easy to guess how many subscribers would use the same
   external IP address
   
=> it is a per-subscriber static property. It should be ~= <#subscribers> /
<#addresses>. By the way the external IP address of a subscriber is kept
in the stable storage state of the PCP server even in general it is in
the configuration file too (but as it is not required...).

Regards