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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Ben,

Thanks for the detailed review. Please see inline [TR]

From: Ben McCann [mailto:[e-mail]] 
Sent: Wednesday, January 29, 2014 2:25 AM
To: [e-mail]
Subject: [pcp] Draft-wing-pcp-flowdata-000 Comments

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?

[TR] Not all switches and routers in large access network need to be PCP-aware. PCP server in the access network can convey the information to the SDN controller (Policy Decision Point) which in turn installs flow in network devices. For more information refer to draft http://tools.ietf.org/html/draft-penno-pcp-asdn-00 

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.

[TR] Good point. The reason for supporting FLOWDATA with MAP is to use it in SIP/WebRTC calls where an endpoint with multiple interfaces (3G, Wifi etc) can use MAP with FLOWDATA on each available interface to find if any of the networks can meet the requested flow characteristics,  so that the application can prioritize the host candidates accordingly based on FLOWDATA response.  In this case it would be only be one flow per MAP request. The scenario you have mentioned would be typically used by servers and would use MAP for multiple flows.  we will define the behavior of FLOWDATA option with MAP opcode in the next revision. 

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

[TR] PCP third party authorization is required only for some applications. For example in a scenario where access network has business agreement with Netflix, Hulu Plus etc. HTTP Adaptive Streaming client will send PCP request with access token option so that the access network can prioritize the one-way streaming content. Usage of PCP third party authorization in Mobile networks is explained http://tools.ietf.org/search/draft-penno-pcp-mobile-qos-00, where PCP requests with third party authorization will be mapped to QCI values 1 to 4 and Bandwidth Minimum value in FLOWDATA option will be mapped to Guaranteed bit rate (GBR). PCP requests without third party authorization will also be honored but mapped only to QCI values 6 to 8 (Non- GBR). 

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

[TR] Yes, FlowData option should enforce policies for flows which lie or misbehave. In section 3.3 this problem is discussed

<snip>

  A PCP server that processes the FLOWDATA option is likely to create
   state for that flow (e.g., for bandwidth counting so that the
   bandwidth is returned to the bandwidth pool when the flow lifetime
   expires).  Because Memory and other resources limit how much state
   can be created, the PCP server MUST implement a policy limit so that
   all state is not consumed by one host.  It MAY also implement other
   limits, such as rate limits.  The PCP server can implement its own
   policy to remove flows from its memory, such as FIFO.  If a host has
   exceeded its quota, the existing error USER_EX_QUOTA SHOULD be
   returned.

</snip>
 
Cheers,
-Tiru.

Ben McCann,
F5 Networks