Subject: Re: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response

From: Simon Perreault <[email-masked]>
Date: Wed, 20 Apr 2011 20:21:02 -0400

On 04/20/2011 05:18 PM, Francis Dupont wrote:
>     My question is: what happens when a single mapping with options is too
>     large to fit in a PCP response? This can happen for example when many
>     FILTER options were added in separate PCP requests.
>
> =>  it should not be possible. BTW the FILTER options don't accumulate
> so they can't be easily used to overflow a single mapping.

What do you mean they don't accumulate? On the contrary, they do 
accumulate. If I add filter A in one request then add filter B in 
another request, then a GET should return both A and B.

>     Do we strip off some options? Do we fragment somehow? All solutions I
>     can think of are either too complex or don't fully solve this problem.
>
> =>  it is a known limit of using UDP as the only transport.
> IMHO we can live with it: there is no trivial real world example where
> it can be a credible issue.

Well, the maximal number of filters in a 1024-byte PCP message is around 
80. It's easy to go over that limit. Anyway since PCP is not even born 
yet, I think it's premature to speculate about possible usage patterns.

Another thing: right now FILTER is the only option I can think of that 
would trigger this. But we don't know about future PCP extensions. Other 
options could have the same effect.

So are you suggesting that we truncate the mapping options in a GET 
response?

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