On Mon, Apr 19, 2010 at 11:47 PM, Adrian Chadd <adr...@creative.net.au> wrote: > On Tue, Apr 20, 2010, Perry Lorier wrote: >> could dimension a NAT box for an ISP. His research is available here >> http://www.wand.net.nz/~salcock/spnat/tech_report.pdf . If walls of >> text scare you (why are you reading this mailing list then?) skip >> through and look at the graphs (page 3 onwards) > Interesting. Only a few days, and not really any analysis for worst > case scenarios and how to possibly gracefully recover from those. > (eg, I've done some NAT hacks to detect idle HTTP pconns and toss > those before tossing the others.)
I found some of the premises lacking, at least, in an initial reading; session expiration is a problem for SP NAT, and for that reason, the dimensioning that makes it even worse is questionable, in that the shown er solution to UDP packets creating many sessions was by establishing extra short expiration durations; it attempts to address one problem, while creating an even bigger one..., NAPT with short expiration in a SP environment indicates a point of more breakage to network connectivity than the negative impact of current NAPT practice in enterprise environments. At least table sizings can be met by expanding capacity. Expiring good/still-active "short lived" sessions cannot be fixed, except by not expiring them. A good example of an application this "short lived sessions" treatment may break is DNS, if for example, a domain's authoritative responses are taking >10 seconds to arrive, and the DNS cache on a subscriber's PC submits a query to each of the authoritative servers for that domain, the session will expire, before 1/3rd of the normal DNS timeout has passed -- since only one packet is sent to submit each DNS query, they all get considered "short-lived sessions". Now instead of DNS being slow (response after 10 seconds due to congestion of an overseas link or something), the domain being resolved is completely unreachable ---- the response arrives but was discarded because the session expired, so never seen, unless one of the servers can get a response in within that 10s window.... That's an ungraceful failure result. Expiring sessions early is likely to create a similar problem for P2P client applications -- they were waiting for a response, but will never get it. That "one packet session" concept is just a prediction; in reality, the client likely hopes for a response from many of those requests within a few minutes... If expiring these"short lived sessions" is undesired by the application and if adopted by SPs could probably result in significant changes by the developers to the client software applications observed. Changes to the applications (in reaction to SP NAT) could be expected to effect that peak result of SP NAT, negating portions of state table reductions obtained temporarily through shortening expiration periods. Means that new apps designed for use with such services would probably have to re-transmit much earlier, or flood no-op UDP, TCP packets in order to keep sessions open, in order to provide the user a reasonable experience.. sending additional packets to 'keep sessions alive' on the NAT device consumes more time on the wire (bandwidth), negates and might eventually exceed part of the SP's advantage of early expiration, if the expire is short enough -- -J