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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Masataka Ohta [mailto:[e-mail]]
> Sent: Saturday, February 11, 2012 1:25 AM
> To: Dan Wing
> Cc: [e-mail]
> Subject: Re: [pcp] draft-ietf-pcp-base-22
> 
> Dan Wing wrote:
> 
> >> 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.
> >
> > 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.
> 
> 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?

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.

> >> 4) PCP over UDP over IPv4 MUST use UDP checksum. IPv6 UDP of
> >> RFC2460 should also be referred.
> >
> > 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.
> 
> > For IPv6, all UDP packets have to be checksummed.  I don't
> > see a need to restate that in this document.
> 
> You shouldn't. Instead, you must give a reference to something
> not stated in RFC768.
> 
> >> 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.
> >
> > Ok, I went with:
> 
> 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).

> > 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?

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.

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

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.


> See below for another example.
> 
> >> 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.
> 
> > The PCP working group had a long discussion regarding the
> > need for sequence numbers / transaction numbers, and decided
> > they were unnecessary.
> 
> The problem is commonly solved in many UDP applications and
> 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
...

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

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.

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

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