Subject: Re: [pcp] draft-ietf-pcp-base-22

From: Masataka Ohta <[email-masked]>
Date: Mon, 06 Feb 2012 07:40:59 +0900

Dan Wing wrote:

> draft-ietf-pcp-base-22<http://tools.ietf.org/html/draft-ietf-pcp-base-22>
> was just posted with changes as a result of Dave Thaler's review.

I have read the PCP draft for the first time (I noticed
the presence of the WG just recently) to find it,
sorry, extremely verbose and pedantic, which, seemingly,
has hide several essential problems unnoticed by many.

The followings are problems I noticed ordered less
serious ones first.

1) though a minor problem, the same figure is represented
in different ways as "4,294,967,295" and "4294967295",
both of which are pedantic. The useful representation
for most readers should be "2^32-1" or "2**32-1".

2) The draft seemingly assumes, like UPnP, a private network
is a single subnet. A client use PCP, only when an address of
its peer is located outside of the private network (some
peer may not have outside address). But, there is no
information of multiple prefixes which constitute the
private network consisting from multiple subnets, which
means the client must assume local subnet is the single
prefix private network.

3) The following paragraph in 6.2 is self contradictory:

   Reserved:  96 reserved bits, MUST be sent as 0, MUST be ignored when
      received.  This is set by the server.  This padding exists so that
      for unrecognized requests, the server can blindly copy an entire
      request message into a response message and have that response
      make some kind of reasonable sense to the recipient.

It says "MUST be sent as 0" and "the server can blindly copy".

4) PCP over UDP over IPv4 MUST use UDP checksum. IPv6 UDP of
RFC2460 should also be referred.

5) In 7.1, there is a exponential back-off described and I
can't understand why 15 minutes, not 1024 seconds, is the
upper limit. Unlike "4294967295" of 1), "1024 seconds" is a
lot more straight forward here to understand and to implement.

6) More seriously on exponential back-off, in case there are
a lot of clients simultaneously sending requests, the initial
request SHOULD (not "MUST", because there are cases we can
expect clients not synchronized or 1 second is lengthy) be
delayed randomly between 0 to 1 seconds and subsequent waiting
MUST also be random, which SHOULD be between [1, 2], [2, 4],
[4, 8], ... and [512, 1024] seconds.

7) In 6.2, it should be mentioned client must start
decreasing lifetime not when a response packet is received
but when a request packet corresponding to the response
packet was sent.

8) Though there is verbose and pedantic discussion on
idempotency in section 7, it does not make sense.

We may send requests at times 0, 2, 6, 14 and receive a
response at time 25, which may be a response to the
request at time 0. Then, because of 7), 25 seconds of
lifetime has already passed.

Thus, we must be able to match requests and
responses, which means packets needs something like
sequence numbers, which must be copied from requests to
responses, which makes the protocol not idempotent
w.r.t. the sequence numbers.

DHCP, for example, has a "secs" field.

Having such correspondences, there is no point to
blindly copy everything from requests to responses
weakly expecting that we might be able to match
requests and responses, removal of related descriptions
could improve the draft a little.

					Masataka Ohta

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Feb 2012 10:07:32 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Masataka Ohta
> Sent: Sunday, February 05, 2012 11:41 PM
> To: [email-masked]
> Subject: Re: [pcp] draft-ietf-pcp-base-22
> 
> Dan Wing wrote:
> 

Adjusted all to 2^32-1.

> means the client must assume local subnet is the single

The draft assumes there is a default route to the Internet,
which is where outbound packets (towards the Internet) will
be sent (e.g., TCP SYN).  That is the path "to the Internet",
and PCP communications go to that same first hop towards
the Internet.  This is different from UPnP, which uses
an advertisement method -- which can cause a UPnP IGD to
be installed on a network which is not on the path to the
Internet.

> It says "MUST be sent as 0" and "the server can blindly copy".

Fixed, thanks.

> RFC2460 should also be referred.

For IPv4, if a host's UDP checksumming is disabled system-wide,
an application implementing PCP may not be able to enable the 
host's UDP checksum for that socket.  Is there value in making
those deployments violate the PCP specification?

For IPv6, all UDP packets have to be checksummed.  I don't
see a need to restate that in this document.  I mean, the
document also doesn't say that IP header checksum needs to
be calculated.

> upper limit.

Changed from "15 minutes" to "1024 seconds".  Thanks.

> Unlike "4294967295" of 1), "1024 seconds" is a

Ok, I went with:

        <t>When attempting to contact a PCP server, the PCP client
        sends a PCP message to the first server in its list of PCP
        servers, and SHOULD initialize a timer to a random value
        between 2 and 3 seconds.</t>

        <t>For as long as the client still desires the indicated
        mapping, if no response is received before the timer expires
        then the request is re-transmitted.  These re-transmissions
        are sent at a random value between 1.5 and 2.5 of the previous
        transmission interval.  The randomization helps avoid client
        synchronization.  This repeats until a maximum retransmission
        interval between 512 and 1024 seconds, at which point the
        retransmission continue at that interval, until a successful
        response is received or the client no longer desires the
        indicated mapping.</t>

> but when a request packet corresponding to the response

Not sure how that would work.  The client can request whatever
time it wants (e.g., 20 seconds, 720 hours), but the server is
what decides the actual lifetime -- which can be minimized
against a value such as 60 seconds or maximized against a value
such as 24 hours.  

> could improve the draft a little.

The PCP working group had a long discussion regarding the
need for sequence numbers / transaction numbers, and decided
they were unnecessary.

-d

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

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 11 Feb 2012 18:24:46 +0900

> be installed on a network which is not on the path to the

You don't understand what the problem is.

Try to implement a ftp client program using PORT command and
PCP.

Can you understand that client do not use PCP if a server is
within some subnet of a private network?

How can the client program know where the server is?

> For IPv4, if a host's UDP checksumming is disabled system-wide,

That's a violation of Internet Standard of RFC1122:

         4.1.3.4  UDP Checksums

            A host MUST implement the facility to generate and validate
            UDP checksums.  An application MAY optionally be able to
            control whether a UDP checksum will be generated, but it
            MUST default to checksumming on.

> see a need to restate that in this document.

You shouldn't. Instead, you must give a reference to something
not stated in RFC768.

>> [4, 8], ... and [512, 1024] seconds.

You miss randomization before sending initial request.

> a random value between 2 and 3 seconds.</t>

> a random value between 1.5 and 2.5 of the previous transmission
> interval.

> a maximum retransmission interval between 512 and 1024 seconds

I'm afraid I can't understand how you calculated the seemingly
inconsistent value pairs of [2, 3], [1.5, 2.5] and [512, 1024].

> at which point the retransmission continue at that interval

Random interval should be recalculated on each retransmission,
shouldn't it?

> against a value such as 60 seconds or maximized against a value

Values in requests are irrelevant.

If a response with lifetime of 60 seconds is received 5
seconds after a request, a client must interpret that
55 seconds of lifetime is left.

After a server decided a lifetime of 5 seconds, it may
take 5 seconds for the server transmit response, or
for network relay the response.

If a response with lifetime of 60 seconds is received
65 seconds after a request, a client must interpret that
all the lifetime has already expired.

See below for another example.

> need for sequence numbers / transaction numbers, and decided

The problem is commonly solved in many UDP applications and
is not something need so much discussion.

See so simple examples above.

						Masataka Ohta

PS

I recommend people here develop some simple (without
being pedantic) specification of some simple client
(ftp client using PORT command, for example), using
PCP and test it in various common use cases (such as
static UPnP port forwarding), before making PCP a PS.

PPS

I think version numbers of PCP not useful. Details
will be mailed later.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Feb 2012 09:58:41 -0800

> From: Masataka Ohta [mailto:[email-masked]]
> Sent: Saturday, February 11, 2012 1:25 AM
> To: Dan Wing
> Cc: [email-masked]

Yes, I understand the problem you are describing.

> How can the client program know where the server is?

It can't.

Protocols more modern than FTP, such as SIP, DNS, RSTP 2.0 and 
others, allow acquiring exchange multiple IP addresses which can
be tried sequentially or tried (nearly) in parallel (e.g., ICE
(RFC5245), draft-ietf-v6ops-happy-eyeballs).

But to your question about FTP with the PORT command, it would
work fine, although the FTP data traffic would hairpin through
the NAPT device:

               {Internet}
                   |
               192.0.2.1
        IPv4 NAPT with PCP server
                   |
        +----------+--------+
        |                   |
    FTP client          FTP server
    192.168.1.1         192.168.1.2

1. FTP client connects to FTP server and logs in
2. FTP client listens on a TCP port
3. FTP client issues PCP "MAP" Opcode to its default router (in
   this case, its IPv4 NAPT), asking for a mapping to its listenting
   TCP port.  The MAP response indicates the WAN address and 
   TCP port of the NAPT, 192.0.2.1/12345
4. FTP client sends the command "PORT 192,0,2,1,48,57" to the FTP
   server, which was the IP address and port returned in step 3.
5. FTP client issues the LIST command
6. FTP server connects to 192.0.2.1/12345 and starts sending the
   directory listing.

Yes, I agree the traffic path is not optimal (it goes through the 
NAT when it could have gone directly between the FTP client and
FTP server).   If the FTP client wanted an optimal path, it could
use FTP passive-mode, or it could use a protocol that allows 
signaling multiple IP addresses.

> You miss randomization before sending initial request.

We would not want to delay the initial request.  DHCP does
the same sort of thing (initial message is sent when client
wants to send it, retransmissions are slightly randomized).

> Random interval should be recalculated on each retransmission,

Do you have text to suggest, perhaps from an existing RFC?  I can
lift the text straight from 
http://tools.ietf.org/html/rfc2131#page-24 unless you have 
some better source to suggest.

> all the lifetime has already expired.

Thanks for the explanation.  

Added

	<t>To accommodate network latency, PCP server processing
        latency, packet loss, and PCP client retransmissions, the PCP
        client MUST start decrementing its internally-maintained
        lifetime value when it sends its first request for a specific
        mapping.</t>

        <t>Once a PCP server has responded positively to a MAP request
        for a certain lifetime, the port mapping is active for the
        duration of the lifetime indicated in the response, minues the
        time between the PCP client's first request for that specific
        mapping and the reception of the positive response.

> is not something need so much discussion.

The internal IP address (now always 128 bits) and port (16 bits) 
form a transaction ID.  The same problems you outlined above
would exist for retransmissions if the transaction ID were
to stay the same for retransmissions -- which is also pretty
typical of UDP applications.

Minutes from the decision:
  http://www.ietf.org/proceedings/79/slides/pcp-4.pdf, slide 3
  http://www.ietf.org/proceedings/79/minutes/pcp.txt
...
    2. Transaction ID We already have a 48-bit transaction ID
       (internal addr + port) Proposed to reject

    Francis: argument is wrong in the case of DS-lite

    Stuart: What would ICE do? Outbound TCP SYN somehow manages
       to make a port mapping without a transaction ID

    Margaret: There's no answer to an outbound SYN
       haven't talked about flow control, flood restart    
       until we talk about that, don't know if we need transaction ID

    Stuart: Simplicity in reporting a port mapping exists,
       without regard to how a mapping was created
...

> static UPnP port forwarding), before making PCP a PS.

PCP's semantics are very similar to NAT-PMP 
(draft-cheshire-nat-pmp) which has been deployed by Apple 
for several years and available on both OSX and in Windows 
after installing iTunes.  Several applications, including 
uTorrent and dozens of others, use NAT-PMP today.

There was a PCP demonstration and interop test at IETF81.

> I think version numbers of PCP not useful. Details

The version number is currently used to disambiguate
NAT-PMP from PCP, which can utilize the same port.  NAT-PMP
was never an IETF protocol, but did have an IANA-assigned
port which we hope to reclaim for PCP.  The version handling
works (code was written to prove it works), and is valuable.
Running the two protocols on the same port helps avoid 
unnecessary timeouts to discover which protocols are 
supported on a network.

-d

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 14 Feb 2012 09:36:57 +0900

> Yes, I understand the problem you are describing.

Not very well.

Complicated solutions sometimes work. Though it is not easy to
find cases they don't work, it does not mean they always work.

>          IPv4 NAPT with PCP server

Though it does not work with typical UPnP capable NAT with
static port forwarding and dynamic outgoing port mapping,
let's not discuss here (see discussions on version later).

>     server, which was the IP address and port returned in step 3.

Then, it is quite likely that the ftp server in the private
network denies the request including addresses outside of the
private network. The ftp server may not have any route other
than private ones.

There are reasons, such as security, why the ftp server is
located within the private network. That local ftp clients
can fetch contents of the ftp server and somehow relay them
globally does not loosen security policy of the ftp server.

Don't try to solve a simple problem in complicated ways
only to make the problem unsolvable in some simple cases.

> If the FTP client wanted an optimal path, it could

I appreciate incredible pedantism here only to make the
originally simple problem even more unsolvable.

>> That's a violation of Internet Standard of RFC1122:

Have you fixed it?

> wants to send it, retransmissions are slightly randomized).

DHCPv6 does randomize:

   The first Solicit message from the client on the interface MUST be
   delayed by a random amount of time between 0 and SOL_MAX_DELAY.

The problem of DHCPv6 is that it is not "SHOULD" but "MUST".
E.g., initial randomization of PCP initiated by DHCPv6 is
a waste of time.

> some better source to suggest.

Page 27 of RFC3315 might be helpful.

> form a transaction ID.

No, not at all. It merely identifies a (half) connection.

Multiple transactions on a connection must be identified
with additional information.

> The same problems you outlined above

OK, to be a little pedantic, a single transaction may
use retransmissions, in which case, the same transaction
ID must be used by all the retransmissions.

However, if another transaction, which may be of the
same type as the original, is performed, new transaction
ID must be used.

Each request of PCP is independent transaction because
of lifetime problem of 7).

>    http://www.ietf.org/proceedings/79/minutes/pcp.txt

The decision does not affect the reality of transactions.

> There was a PCP demonstration and interop test at IETF81.

It means that you need someone else, not me, having
some experience with yet another perspective.

> unnecessary timeouts to discover which protocols are

As  servers of the same version behaves very differently,
the version number does not help clients guess servers'
capability.

Client must check whether some opcode and/or option work
on its servers anyway (as is exemplified with ftp case),
which means  version number negotiation is a waste of time.

New opcode and/or options are enough, which is what DHCP,
extended from BOOTP, is doing with options.

					Masataka Ohta

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 15 Feb 2012 15:34:59 -0800

> Sent: Monday, February 13, 2012 4:37 PM
> To: Dan Wing
> Cc: [email-masked]

What do you suggest be done.

> >> That's a violation of Internet Standard of RFC1122:

No, the document is still silent on UDP checksum.  

>    delayed by a random amount of time between 0 and SOL_MAX_DELAY.

Sure, but DHCPv4 does not randomize.

> Page 27 of RFC3315 might be helpful.

Thanks.  I removed the old retransmission text and now have this:

   7.1.1.  PCP Client Retransmission

   PCP clients are responsible for reliable delivery of PCP request
   messages.  If a PCP client fails to receive an expected response from
   a server, the client must retransmit its message.  The client begins
   the message exchange by transmitting a message to the server.  The
   message exchange terminates when either the client successfully
   receives the appropriate response or responses from the server, or
   when the message exchange is considered to have failed according to
   the retransmission mechanism described below.

   The client retransmission behavior is controlled and described by the
   following variables:

     RT    Retransmission timeout, calculated as described below

     IRT   Initial retransmission time, SHOULD be 2 seconds

     MRC   Maximum retransmission count, SHOULD be 0 (0 indicates no
           maximum)

     MRT   Maximum retransmission time, SHOULD be 1024 seconds

     MRD   Maximum retransmission duration, SHOULD be 0 (0 indicates no
           maximum)

     RAND  Randomization factor, calculated as described below

   With each message transmission or retransmission, the client sets RT
   according to the rules given below.  If RT expires before a response
   is received, the client recomputes RT and retransmits the request.

   Each of the computations of a new RT include a new randomization
   factor (RAND), which is a random number chosen with a uniform
   distribution between -0.1 and +0.1.  The randomization factor is
   included to minimize synchronization of messages transmitted by PCP
   clients.  The algorithm for choosing a random number does not need to
   be cryptographically sound.  The algorithm SHOULD produce a different
   sequence of random numbers from each invocation of the PCP client.

   The RT value is initialized based on IRT:

      RT = IRT + RAND*IRT

   RT for each subsequent message transmission is based on the previous
   value of RT:

      RT = 2*RTprev + RAND*RTprev

   MRT specifies an upper bound on the value of RT (disregarding the
   randomization added by the use of RAND).  If MRT has a value of 0,
   there is no upper limit on the value of RT.  Otherwise:

     if (RT > MRT)
       RT = MRT + RAND*MRT

   MRC specifies an upper bound on the number of times a client may
   retransmit a message.  Unless MRC is zero, the message exchange fails
   once the client has transmitted the message MRC times.

   MRD specifies an upper bound on the length of time a client may
   retransmit a message.  Unless MRD is zero, the message exchange fails
   once MRD seconds have elapsed since the client first transmitted the
   message.

   If both MRC and MRD are non-zero, the message exchange fails whenever
   either of the conditions specified in the previous two paragraphs are
   met.  If both MRC and MRD are zero, the client continues to transmit
   the message until it receives a response.

   Once a PCP client has successfully received a response from a PCP
   server on that interface, it resets RT to its initial value and sends
   subsequent PCP requests to that same server.

> same type as the original, is performed, new transaction

Yes, the protocol can support multiple transactions in 
flight of the same type -- that is, there can be multiple
requests for a mapping to different ports on the network 
at the same time.  There can be a request for an IPv6
mapping and an IPv4 mapping to the same port at the same
time, as well.  All that works.  There is sufficient information 
in the request and response  packets to differentiate those 
requests and responses, and the document describes how the
packets are matched.

> extended from BOOTP, is doing with options.

The version negotiation was used once already (NAT-PMP to 
PCP), and the existence of the version number allowed 
changing the packet layout between those versions.  In the
future, other engineers may well find a need for PCPv2
(or whatever they call it) with yet a different packet
layout, which can leverage the version number.

The document is currently in IETF last call so I am deferring
publishing an update until after IETF last call.

-d

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 23 Feb 2012 20:49:22 +0900

> What do you suggest be done.

I suggest to have a standard request LOCALNETS response for
which returns local subnets with their netmasks.

Reasoning follows.

Making programs PCP capable is good to enable better
communication between local hosts within private networks
and public networks.

However, PCP is a new protocol not necessarily deployed by many.

To make PCP deployed widely, it must be guaranteed that PCP capable
programs do no harm without any configuration efforts.

For the guarantee, it is necessary that PCP enhanced programs
must communicate *identically* with nodes within local networks.

No complicated tricks such as hairpining acceptable here, because
their elaboration changes communication patterns a lot.

It is not acceptable, either, to require users configure what
are local networks.

We SHOULD (or MUST?) make PCP deployed by default and SHOULD
NOT make PCP deployed only with additional effort of some
configuration changes.

To do so, it is necessary that the programs can know whether
their peers are within their local networks or not.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 23 Feb 2012 21:20:03 +0900

> No, the document is still silent on UDP checksum.

Why?

> Sure, but DHCPv4 does not randomize.

RFC2131 says:

: 4.4.1 Initialization and allocation of network address
:
:    The client begins in INIT state and forms a DHCPDISCOVER message.
:    The client SHOULD wait a random time between one and ten seconds to
:    desynchronize the use of DHCP at startup.

> at the same time.

They are different connections.

> There can be a request for an IPv6
> There is sufficient information
> packets are matched.> time, as well. All that works.

The problem is that different transactions on a single
connection can not be distinguished.

You can have a transaction to establish a connection.

You, then, can have a transaction to renew the connection,
which can be distinguished from the previous transaction
because request types are different.

However, if you initiate the second renewal of the connection,
there must be different transaction ID, which does not
present in the current PCP specification, is necessary.

Or, you can only guess that a response to the second renewal
request could actually be a response to the first renewal
request, which means the connection could have been expired
its lifetime.

> PCP),

Not yet, because PCP is not yet PS.

Moreover,

> and the existence of the version number allowed
> changing the packet layout between those versions.

as packet layouts of NAT-PMP depends on OPCODEs, new OPCODEs
are enough to change packet layouts.

					Masataka Ohta

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 23 Feb 2012 07:14:20 -0800

> Sent: Thursday, February 23, 2012 4:20 AM
> To: Dan Wing
> Cc: [email-masked]

UDP is a lower layer, covered adequately by other specifications.
Much like IP checksum is covered by other specifications.

> :    desynchronize the use of DHCP at startup.

I'm not seeing the need for PCP to randomize its initial message.  

> because request types are different.

They don't need to be distinguished; there is nothing the
PCP client or PCP server can do differently by having them
distinguished.

> Not yet, because PCP is not yet PS.

I don't follow the argument that because PCP is not yet
a proposed standard RFC, it does not need version negotiation.

> are enough to change packet layouts.

We are using the version negotiation already.  It needs to
stay.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 23 Feb 2012 07:18:39 -0800

> Sent: Thursday, February 23, 2012 3:49 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: GETLOCALNETS (was Re: [pcp] draft-ietf-pcp-base-22)
> 
> Dan Wing wrote:
> 

Could you explain in more detail how GETLOCALNETS would work,
such as the example you proposed earlier of an FTP client
accessing an FTP server on the local network.

-d

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 24 Feb 2012 08:16:25 +0900

> Much like IP checksum is covered by other specifications.

As is specified in RFC1122, UDP checksuming is controlled by
applications:

            An application MAY optionally be able to
            control whether a UDP checksum will be generated, but it
            MUST default to checksumming on.

which means it is a part of application specification whether
an application turns on it or not.

> I'm not seeing the need for PCP to randomize its initial message.

Then, there is no need to randomize subsequent retries nor
exponential backoff.

If initial messages are expected to be sent with well
distributed timing, retries can be sent with fixed timing
with no exponential backoff and the retries are still sent
with well distributed timing.

Worse, that's not a valid counter argument after you mention
DHCPv4.

> PCP client or PCP server can do differently by having them

Hmmmmm, no one in this WG other than me understand how
PCP works.

If identical requests are sent at time 0, 5, 240, 245, 480
and 485 and identical responses with lifetime of 300 are
received at time 10, 250 and 490, you can't be sure that
the latest response is not a response for a request sent
at time 0, in which case lifetime of the response has
expired already 190 seconds ago.

The only way to solve the problem is to let requests
have different transaction IDs. Though requests at time
0 and 5 may have the same transaction ID, it is unnecessary
complication that all the requests have unique transaction
IDs.

> a proposed standard RFC, it does not need version negotiation.

Your statement of "The version negotiation was used" is
invalidated as a reason to keep version numbers.

> We are using the version negotiation already.  It needs to

You fail to state why "It needs to stay".

Do you mean we must increment the version number to 2 if
we change packet format to introduce transaction IDs?

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 24 Feb 2012 08:25:07 +0900

> accessing an FTP server on the local network.

The first thing for an FTP client, which is also an PCP client,
is to issue LOCALNETS request to a PCP server. Its response
should contain local net information as a list of prefixes
with their mask lengths, such as 10.0.0.0/16 and 10.2.0.0/24.

Then, the FTP client further use PCP only if an address of an
FTP server is outside of  10.0.0.0/16 and 10.2.0.0/24.

Thus, it is guaranteed that local FTP servers, local firewalls
and other local equipments see identical behavior of local FTP
clients to access local FTP servers regardless of whether the
clients are PCP capable or not.

						Masataka Ohta

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 24 Feb 2012 16:40:37 -0800

> Sent: Thursday, February 23, 2012 3:16 PM
> To: Dan Wing
> Cc: [email-masked]

I don't interpret the text in RFC1122 the same.

> >> :    The client SHOULD wait a random time between one and ten
> seconds
> >> to

I adjusted the text, on your earlier suggestion, that the
PCP client start its internal countdown based on when it
sends its first request.

The PCP client can't do anything with the mapping until it
gets a response.  And the scenario above requires the PCP
server and/or the network to queue PCP messages for dozens
or hundreds of seconds.

> complication that all the requests have unique transaction

Transaction IDs are an unnecessary complication.  The packets
are sufficiently self describing that the problem described
in your message does not occur.

> we change packet format to introduce transaction IDs?

Changes to the PCP header layout, which are incompatible with
the current version of the PCP header layout, would necessitate
increasing the version number.  

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 24 Feb 2012 16:43:56 -0800

> Sent: Thursday, February 23, 2012 3:25 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: GETLOCALNETS (was Re: [pcp] draft-ietf-pcp-base-22)
> 
> Dan Wing wrote:
> 

So, in other words:  only use PCP to create a mapping when
going off the local network.

-d

---

From: Xiaohong Deng <[email-masked]>
Date: Mon, 27 Feb 2012 15:47:11 +0800

> > expired already 190 seconds ago.

If the first request issued at time 0 was responded at time 10, why would
the client resend request again at time 5 and so on? In case the multiple
requests are occurred due to network layer re-transmitting, as long as the
first response assured the Client that the mapping was established, later
responses wouldn’t bother the client anyway.

> in your message does not occur.

Aggreed.

Cheers,
Xiaohong

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 27 Feb 2012 21:26:42 +0900

Xiaohong Deng wrote:

> the client resend request again at time 5

Huh?

Please don't demonstrate that you don't have any expertise on
protocols at all, please.

						Masataka Ohta

---

From: Xiaohong Deng <[email-masked]>
Date: Mon, 27 Feb 2012 20:45:57 +0800

2012/2/27 Masataka Ohta <[email-masked]>

> protocols at all, please.

Please specify your technical disagreement than your personal feeling which
is of no help.

Xiaohong

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 27 Feb 2012 22:26:23 +0900

> Please specify your technical disagreement than your personal feeling which

I'm afraid you can have no help being incapable to have any
technical opinion.

Or, feel free to have a time machine or two to resend a request
at time 5 *AFTER* you receive a response at time 10.

							Masataka Ohta