Subject: [pcp] Draft-wing-pcp-flowdata-000 Comments

From: Ben McCann <[email-masked]>
Date: Tue, 28 Jan 2014 20:54:39 +0000

Hi Dan, Reinaldo, and Tiru,

I have a few comments and questions on your PCP flowdata draft. Overall, it looks good.

To summarize, this PCP enhancement enables an application attached to an access network to signal its resource (bandwidth, etc) requirements to the network via a PCP server. The PCP server reserves none, some, or all of the requested resources and returns a response describing that reservation.

*         Section 1: Recursively forwarding PCP FlowData requests hop-by-hop through the access network is an elegant solution for reserving resources from the application to the boundary between the access network and the Internet. That said,  does this introduce scaling problems?

o   Are there administrative scaling challenges for large access networks with many switches and routers? Do most of them have to be configured with PCP servers for the reservation system to be effective?

o   Can upstream PCP servers handle all of the individual reservation requests arriving from multiple downstream PCP servers? Is some kind of reservation aggregation mechanism required to scale to 1000's or 10000s of reservations?

*         Section 3.2 & Figure 3: Does the FlowData option in a MAP request define the aggregate resource requirements for all matching inbound flows going to the application sending that MAP request or is the reservation per flow? Both options have issues:

o   If the reservation is for all flows, then the resource manager can easily reserve resources (bandwidth, etc) in aggregate for that application. That simplifies resource allocation but it is extremely inefficient because resources are pre-allocated for flows that may never arrive.

o   If the reservation is per flow, then how does the resource manager know how many resources to reserve? If the MAP request FlowData option only describes the resource requirements for one flow, then how does the resource reservation system know how many flows to expect?

IMHO, both of these options are broken. Instead, the FlowData option should:

o   Describe the resource requirements per flow. The CGNAT/Firewall/Etc must reserve resources incrementally as clients connect to the mapped server. This provides some level of fairness across multiple servers using the MAP request.

o   Define the maximum number of flows that are expected. The PCP server may return a smaller number in the MAP reply if this is excessive. The CGNAT may reject inbound connections that exceed this upper bound to ensure it has resources for other mapped servers.

o   Define the behavior of the connection when resources (as defined in the MAP request) are unavailable. Should the CGNAT fall back to "best effort", drop the SYN packet and let the client retry, send back something in ICMP, or should it reject the connection request with a RST? (Examples are admittedly TCP-centric).

In summary, FlowData should describe resources per flow, how many flows are expected, and how to handle new inbound flows when resources are unavailable.

Note that the CGNAT/Firewall handles resource reservation errors autonomously because, IMHO, sending PCP packets back to the client when resources are low introduces unacceptable DoS attack vectors.

*         Section 6: Why do we need a separate authorization mechanism for FlowData? The client's identify is verified during PCP Authentication so why doesn't the PCP server consult a policy server at that time to determine the client's resource reservation privileges? We don't need a separate crypto-token for FlowData because the whole PCP request is signed by the PCP Authentication Tag. We should also avoid authorizing individual FlowData requests to an external server because it won't scale.

*         (Other) Should the FlowData option define enforcement policies for non-conformant flows that exceed their bandwidth reservation? For example, best effort, some flavor of random early discard, rate shaping, etc, etc...? The alternative is that the reservation enforcement policy is statically defined per hop and that it is unaware of the best protocol-dependent method to enforce bandwidth reservations.

Ben McCann,
F5 Networks