Subject: [pcp] PORT_SET for discovering static port set mappings

From: Simon Perreault <[email-masked]>
Date: Fri, 17 May 2013 16:14:02 +0200

WG,

In private email, Cathy Zhou has suggested the following addition to 
draft-ietf-pcp-port-set:

1.4.  Discovering Stateless Port Set Mappings

    A MAP request can be used to discover a stateless mapping.
    Similarly, a MAP request with a PORT_SET request can be used to
    discover a stateless port set mapping.  Hence, PORT_SET is applicable
    for port set mapping discovery in Stateless NAT44
    [I-D.tsou-stateless-nat44].

Unless the WG disagrees, it will be part of the next revision.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Sat, 18 May 2013 21:06:57 +0000

Interesting. How about stateless NAT64?

And last but not least, how about PEER messages? I will send a separate
message about my experiments with transmission Bittorrent to see other
people's opinion.

The current message does not allow the client to specify the internal port
set.

On 5/17/13 11:14 AM, "Simon Perreault" <[email-masked]> wrote:

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 May 2013 07:54:08 +0200

> Interesting. How about stateless NAT64?

Sure, it could be used for that too. Any NATxy static port set mapping 
can be discovered.

> The current message does not allow the client to specify the internal port

Right. So far we have considered PEER out of scope for this draft.

Simon

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 20 May 2013 10:42:23 +0000

>Right. So far we have considered PEER out of scope for this draft.

I have the following scenario so we can gauge if PEER is in scope:

- I changed transmission BT to send a PEER message for every outgoing TCP
connection it makes.

After running a few tests the issue that bubbled up is that both
Transmission and my FW/NAT is paying a penalty for using PCP PEER this way
since they both need manage 100s (or 1000s) of PEER mappings. For P2P
software and some video streaming clients that have a high number of
connections, the use of PCP should be simplified. I thought about two of
ways of doing that:

- Wildcards in PEER messages

- PEER Port set. I guess one can argue a port set is a middle ground
between a fully specified 5-tuple and a wildcard.

Both have issues that need ironing out but I believe it would simplify
considerably PCP use for those types of clients.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 May 2013 13:04:01 +0200

> considerably PCP use for those types of clients.

I understand the need for optimization in this use case. But I don't see 
how PORT_SET could apply, because your 100s of connections are to 100s 
of different remote peer IP addresses. With wildcards you could probably 
cover this, but you would end up with an under-constrained request 
awfully close to meaning "refresh everything".

Why not use a MAP request with a PORT_SET option to get some ports and 
make the BT client use those ports as source for new outbound 
connections? You would not need a very large set since destinations 
would vary so you could overload source ports. Then you can refresh the 
set with a single request.

Simon

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 20 May 2013 11:57:38 +0000

>awfully close to meaning "refresh everything".

The source IP and protocol are the same. The source port many times is the
same across many different connections.

>would vary so you could overload source ports.

This overloading is already heavily done as can be seen by looking at the
connection table. But since destinations are different, usually one
mapping per session is maintained.

>Then you can refresh the

Asking for a MAP PORSET (incoming IP and port are wildcard) isn't the same
as asking for a PEER where the destination IP and port are wildcard? How
would this work with FW?

---

From: Dan Wing <[email-masked]>
Date: Tue, 21 May 2013 12:43:53 -0700

> - I changed transmission BT to send a PEER message for every outgoing TCP

A bittorrent client is operating a symmetric client/server -- it is making outgoing connections and accepting incoming connections.  Seems MAP, as described in http://tools.ietf.org/html/rfc6887#section-10.2, would be appropriate.  With MAP, the problems below seem to all go away.

-d

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 21 May 2013 20:00:18 +0000

Yes, but as long as outgoing and incoming use the same internal source
ports. I will take some measurements and report back.

On 5/21/13 4:43 PM, "Dan Wing" <[email-masked]> wrote:

>A bittorrent client is operating a symmetric client/server -- it is
>making outgoing connections and accepting incoming connections.  Seems
>MAP, as described in http://tools.ietf.org/html/rfc6887#section-10.2,
>would be appropriate.  With MAP, the problems below seem to all go away.
>
>-d
>
>