Re: [shara] port randomization (draft-ymbk-aplusp-03)

["MILES DAVID" <[e-mail]>]

Jan Zorz:
>I'm also curious to hear some aproximation from any HW vendor, what
does allocating "one port per request" means for PRR in larger scale. I
suspect this 
>might very well be performance suicide, but this is only my
speculation. If not - good, we can go in that direction, which I
recognise as good also in several other ways.

My concern with "one port per request" is not so much the port
assignment (we are doing high volumes/rates for), but the high
transaction rate of the messaging protocol. Both
draft-bajko-v6ops-port-restricted-ipaddr-assign and
draft-boucadair-dhc-port-range propose DHCP for this CPE-to-PRR. If we
want to support 128k A+P CPE on a single DHCP server (be this the BRAS
itself or a central server) this would generate a high number of DHCP
transactions/second if a single port is returned per request. There is
also going to be some delay associated with the messaging protocol that
may require a different buffering approach in the CPE until an eternal
port is returned.
A "one port per request" approach also suggests the DHCP server is now
making the decision on what outside port you would be given -
consideration would need to be given to methods allowing CPE to request
specific ports not unlike NAT-PMP or UPnP does today. 

Dan Wing:
>Has consideration been given to having the PRR return only *one* port
>for each request, or to returning a list of port numbers which are
>not consecutive and are not a bit-pattern of ports?

Having a well-defined per-subscriber port-range has other benefits for
functions like customer identification (source ip+source port). I'm sure
we have all been involved in cases where either law-enforcement or
another operator/content provider has sought to advise an ISP of a
problem customer by providing IP and timestamp. If we returned a random
list of ports these would need to be stored. 

I agree with Jan's suggestion of port randomization within a port-range.
It would be good to see this in CGN as well.

Regards,

-David