Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS

From: <[email-masked]>
Date: Thu, 5 May 2011 18:54:29 +0800

|I wasn't planning on it.  What is your suggested text?  
|
|I slightly changed the wording of " Implementing MAP with 
|non-EIM NATs", 
|http://tools.ietf.org/html/draft-ietf-pcp-base-09#section-11.1,
|to cover both connections from separate hosts (using the same 
|source port) and connections from the same host (using the 
|same source port) -- a change which I think causes the text to 
|include an issue Francis raised in private email.
|
|But I don't know if you're describing a similar, related 
|problem with PREFER_FAILURE or what.  Because, frankly, I 
|don't understand the issue and need some hand-holding to 
|understand the problem.
|With that understanding, I could have a chance to write text.  
|But as I do not understand the problem, I cannot successfully 
|write any text..
|
|So:  can you suggest text, please?

The concern of PREFER_FAILURE option is with EIM NAT:
Assume there is first an implicit dynamic mappings translating X1:x1 to
X1':x1',
and then recieved a MAP4 request with  PREFER_FAILURE option asking for
port y1 which is not equal to x1', how does the EIM NAT behave? return
an error
code?

BR,
Xiaohong

|
|-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 May 2011 07:27:52 -0700

> -----Original Message-----
> From: [email-masked] [mailto:xiaohong.deng@orange-
> ftgroup.com]
> Sent: Thursday, May 05, 2011 3:54 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS
> 
> 
> an error code?

Thanks for the explanation.  Turning it into an example:

dynamic mapping:
  inside address:              192.168.1.1:12345  (X1:x1)
  external address:            192.0.2.1:5555     (X1':x1')

MAP4 request, with PREFER_FAILURE:
  inside address:              ?192.168.1.1:12345?, I assume?
  requested external address:  192.0.2.1:9999 (9999 is different from 5555)

It can return the error CANNOT_PROVIDE_EXTERNAL_PORT.

-d

---

From: <[email-masked]>
Date: Fri, 6 May 2011 20:46:09 +0800

Hello Dan,

Please see inline.
|
|Thanks for the explanation.  Turning it into an example:
|
|dynamic mapping:
|  inside address:              192.168.1.1:12345  (X1:x1)
|  external address:            192.0.2.1:5555     (X1':x1')
|
|MAP4 request, with PREFER_FAILURE:
|  inside address:              ?192.168.1.1:12345?, I assume?
|  requested external address:  192.0.2.1:9999 (9999 is 
|different from 5555)

Exactly!

|
|It can return the error CANNOT_PROVIDE_EXTERNAL_PORT.

But the reason why the PREFER_FAILURE option fails is due to internal
port
conflict with an implicit dynamic mapping (it happens during our UpnP
IWF 
prototype test) rather than external port available, which means
PREFER_FAILURE 
MAP still has a chance to succeed if it waits the implicit dynamic
mapping, which
is usually configured with short expire time  (e.g., 60s) comparing to
explicit dynamic 
mappings, to be expired.

So, I propose another error code instead of CANNOT_PROVIDE_EXTERNAL_PORT
to inform the IWF wait for a short time and sent the request again, so
that the IWF will
succeed in a second try instead of returning an error to UPnP client in
the first place.

How do you think?

Beside, are there some text in base -10 describing how EIM NAT acts when
a MAP4 request
(without PREFER_FAILURE option) hits an implicit dynamic mapping, in
particular, whether or
not change the type and the lifetime of the exist implicit dynamic
mapping?

Thanks,
Xiaohong

|
|-d
|
|
|

---

From: Simon Perreault <[email-masked]>
Date: Fri, 06 May 2011 09:25:19 -0400

> succeed in a second try instead of returning an error to UPnP client in

Why not just set the lifetime in the error response to a low value
instead of creating a new error code?

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: "Dan Wing" <[email-masked]>
Date: Mon, 9 May 2011 15:21:37 -0700

> Sent: Friday, May 06, 2011 5:46 AM
> To: [email-masked]
> Subject: RE:[pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS
> 
> Hello Dan,
> 
> Please see inline.
> |
> But the reason why the PREFER_FAILURE option fails is due to
> internal port conflict with an implicit dynamic mapping (it happens
> during our UpnP IWF prototype test) rather than external port
> available, which means PREFER_FAILURE MAP still has a chance to
> succeed if it waits the implicit dynamic mapping, which is usually
> configured with short expire time  (e.g., 60s) comparing to explicit
> dynamic mappings, to be expired.
>
> So, I propose another error code instead of
> CANNOT_PROVIDE_EXTERNAL_PORT to inform the IWF wait for a short time
> and sent the request again, so that the IWF will succeed in a second
> try instead of returning an error to UPnP client in the first place.> 

What makes us believe the port would be freed after a short time?  I
mean, the port could be the client's XMPP, SIP, IMAP, or HTTP persistent
connection -- all of which are pretty long-lived.  It could also be a 
short-lived connection (DNS, HTTP non-persistent connection).

Is there a typical amount of time a UPnP control point will wait for
a negative response?

> not change the type and the lifetime of the exist implicit dynamic

You mean, a suggestion that it shorten the lifetime?  That seems
ill-advised, as it would make the NAT's operation less deterministic
(from the perspective of the application that made the implicit
dynamic mapping).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 May 2011 15:23:11 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Friday, May 06, 2011 6:25 AM
> To: [email-masked]
> Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS
> 
> CANNOT_PROVIDE_EXTERNAL_PORT

That seems reasonable.  We could provide guidance that the lifetime
for that error be a short value if it's a non-EIM NAT and an implicit 
dynamic mapping prevents allocating that port, in order to allow the
IWF to retry pretty quickly in the hope the port is no longer used.

-d

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

---

From: <[email-masked]>
Date: Tue, 10 May 2011 18:05:39 +0800

|> So, I propose another error code instead of 
|> CANNOT_PROVIDE_EXTERNAL_PORT to inform the IWF wait for a short time 
|> and sent the request again, so that the IWF will succeed in a second 
|> try instead of returning an error to UPnP client in the first place.>
|
|What makes us believe the port would be freed after a short 
|time?  I mean, the port could be the client's XMPP, SIP, IMAP, 
|or HTTP persistent connection -- all of which are pretty 
|long-lived.  It could also be a short-lived connection (DNS, 
|HTTP non-persistent connection).

The confilict dynamic implicit mappings that we ran into are often HTTP
non-persistent connection. But, yes you're right, it may run into long
life time 
implicit mapping also.

|
|Is there a typical amount of time a UPnP control point will 
|wait for a negative response?

As far as p2p application concerned, utorrent, vuzz and emule will 
wait approximately 150s, 90s, 90s time respectively for a response.

When we made IWF delay 300s to send back a positive response,
All of them recovered from the error.

|
|> How do you think?
|> 
|> Beside, are there some text in base -10 describing how EIM NAT acts 
|> when a MAP4 request (without PREFER_FAILURE option) hits an implicit 
|> dynamic mapping, in particular, whether or not change the 
|type and the 
|> lifetime of the exist implicit dynamic mapping?
|
|You mean, a suggestion that it shorten the lifetime?  That 

No. And if it is a suggestion, should be suggested other wise--extend
the lifetime.
Not that here EIM was referred instead of Non-EIM.

|seems ill-advised, as it would make the NAT's operation less 
|deterministic (from the perspective of the application that 
|made the implicit dynamic mapping).

Would you please elaborate how EIM NAT,which assumed as free of  the 
problem described in section 11.1, acts when a MAP4 request finds
an implicit dynamic already mapping exsit?  And why it doesn't have a
problem
in this case?

Thanks,
Xiaohong
opensource A+P: http://opensourceaplusp.weebly.com/

|
|-d
|

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 May 2011 16:13:14 -0700

> Sent: Tuesday, May 10, 2011 3:06 AM
> To: [email-masked]
> problem in this case?

You're right, that if an EIM (or non-EIM) NAT receives a MAP request
that includes PREFER_FAILURE, it will need to return an error if
there is already an implicit (or explicit) dynamic mapping on the 
requested port.

I believe we have two proposals on the table right now, for when
a MAPx request contains the PREFER_FAILURE option if an implicit
dynamic mapping exists on that requested public port:

  * return the error CANNOT_PROVIDE_EXTERNAL_PORT with a
    short error lifetime to signal that the PCP client
    (IWF) should retry soon.

  * return a new error message, IMPLICIT_MAPPING_EXISTS, 
    with a short error lifetime to signal that the PCP
    client (IWF) should retry soon.

In both cases, the PCP client (IWF) behavior is the same --
after receiving the error, it waits "error lifetime" before
trying again to get the same port.

In both cases, the NAT needs to know if the existing
mapping was created implicitly or created explicitly, in order
to return the short error lifetime.

-d

---

From: <[email-masked]>
Date: Wed, 11 May 2011 18:23:04 +0800

|You're right, that if an EIM (or non-EIM) NAT receives a MAP 
|request that includes PREFER_FAILURE, it will need to return 
|an error if there is already an implicit (or explicit) dynamic 
|mapping on the requested port.
|
|
|I believe we have two proposals on the table right now, for when
|a MAPx request contains the PREFER_FAILURE option if an implicit
|dynamic mapping exists on that requested public port:

I guess you meant "dynamic mapping exists on that requested *internal*
port"?

|
|  * return the error CANNOT_PROVIDE_EXTERNAL_PORT with a
|    short error lifetime to signal that the PCP client
|    (IWF) should retry soon.
|
|  * return a new error message, IMPLICIT_MAPPING_EXISTS, 
|    with a short error lifetime to signal that the PCP
|    client (IWF) should retry soon.
|
|In both cases, the PCP client (IWF) behavior is the same --
|after receiving the error, it waits "error lifetime" before
|trying again to get the same port.
|
|In both cases, the NAT needs to know if the existing
|mapping was created implicitly or created explicitly, in order
|to return the short error lifetime.

Yes, that could do. And how about the NAT  return the aging time 
of existing mapping as the short error lifetime?

Don't see a strong need to define a new error code.
But  will it be more appropriate for IWF provide a more acurate
reason of error IMPLICIT_MAPPING_EXISTS,  to a user (e.g, log file)?

Another question:

Still, when a MAPx request does *not* contain the PREFER_FAILURE
option if an implicit dynamic mapping exists on that requested
*internal*
port, how does *EIM* NAT handle that?

|
|-d
|
|
|> Thanks,
|> Xiaohong
|> opensource A+P: http://opensourceaplusp.weebly.com/

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 11 May 2011 08:21:04 -0700

> Sent: Wednesday, May 11, 2011 3:23 AM
> To: [email-masked]

Yes, that's what I intended to write.  

> of existing mapping as the short error lifetime?

If I understand what you mean by 'aging time' correctly, it
is the lifetime of the existing mapping.  Our NATs (both
low end and high end) will allow a TCP mapping to persist
for a loooong time (an hour or so), idly.  Which means we
would return a lifetime of ~60 minutes.  That doesn't seem
useful for your purposes.

> reason of error IMPLICIT_MAPPING_EXISTS,  to a user (e.g, log file)?

Probably, yes.

I'll see what wording I can craft up later today.

> *internal* port, how does *EIM* NAT handle that?

Seems it would have to return an error or do #2 of
http://tools.ietf.org/html/draft-ietf-pcp-base-10#section-11.1 (which needs
its text changed to accommodate).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 11 May 2011 11:20:22 -0700

Dan Wing wrote:

> Xiaohong Deng wrote:
> http://tools.ietf.org/html/draft-ietf-pcp-base-10#section-11.1 (which
> needs its text changed to accommodate).

I thought about this some more, and I believe EIM have no problem
here.

Let's say a host sends a packet from source port 12345 to the
Internet, which creates a mapping in their EIM NAT.  This will
be mapped to public port "X".  

The host then sends a PCP MAP4 request for internal-port=12345.
This is also mapped to public port "X".

Any traffic from the internal port 12345 is mapped to public
port "X".  And any traffic that arrives from the Internet to
public port "X" is mapped to the internal host's port 12345.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 May 2011 22:45:10 +0200

In your previous mail you wrote:

=> I have to disagree: there is no critical issue but
you can't say there is no issue at all. I know
at least 3 contexts where EIM doesn't really help
with a implicit/explicit collision on the internal port:
 - PREFER_FAILURE
 - explicit dynamic mappings using a dedicated external port pool
 - all the cases where it is important to keep the same
  external port pool (*)

   
   
=> this means the choice of the external port is done by a race
between a packet to the Internet (**) and the MAP request.

Regards

[email-masked]

PS (*): this means if the explicit dynamic mappings have to be
persistent they must be restored first after a reboot. Not something
hard to implement but it can lead to longer unavailability on reboots.

PPS (**): it is less an issue for TCP if only SYN packets are allowed
to create mappings.

---

From: <[email-masked]>
Date: Thu, 12 May 2011 15:13:01 +0800

|
|Dan Wing wrote:
|
|> Xiaohong Deng wrote:
|> > Another question:
|> >
|> > Still, when a MAPx request does *not* contain the PREFER_FAILURE 
|> > option if an implicit dynamic mapping exists on that requested
|> > *internal* port, how does *EIM* NAT handle that?
|> 
|> Seems it would have to return an error or do #2 of
|> 
|http://tools.ietf.org/html/draft-ietf-pcp-base-10#section-11.1 (which 
|> needs its text changed to accommodate).
|
|
|
|I thought about this some more, and I believe EIM have no problem here.
|
|Let's say a host sends a packet from source port 12345 to the 
|Internet, which creates a mapping in their EIM NAT.  This will 
|be mapped to public port "X".  
|
|The host then sends a PCP MAP4 request for internal-port=12345.
|This is also mapped to public port "X".
|
|
|Any traffic from the internal port 12345 is mapped to public 
|port "X".  And any traffic that arrives from the Internet to 
|public port "X" is mapped to the internal host's port 12345.

Doubt if this would always work, consider that the exist mapping 
lifetime is short, in the case that we ran into, less than 60 seconds, 
and it expired quickly as it's a http non-persistent.

Assume a positive response is retured to the PCP client ( is this what 
you implied ?), but if the first incomming connection is issued
more than 60s later after a PCP client assumes the mapping created,
the mapping that the PCP client assumes as successfully created 
would have already been deleted in this case, as there is no traffic
keep alive this mapping during that time.

|
|-d
|
|
|
|