nanog mailing list archives
Re: Rate of growth on IPv6 not fast enough?
From: James Hess <mysidia () gmail com>
Date: Tue, 20 Apr 2010 01:20:09 -0500
On Mon, Apr 19, 2010 at 11:47 PM, Adrian Chadd <adrian () 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
Current thread:
- Re: Rate of growth on IPv6 not fast enough?, (continued)
- Re: Rate of growth on IPv6 not fast enough? Bryan Fields (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? Florian Weimer (Apr 20)
- Re: Rate of growth on IPv6 not fast enough? Florian Weimer (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? Owen DeLong (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? Mark Smith (Apr 20)
- Re: Rate of growth on IPv6 not fast enough? Joe Maimon (Apr 20)
- Re: Rate of growth on IPv6 not fast enough? William Herrin (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? Owen DeLong (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? Perry Lorier (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? Adrian Chadd (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? James Hess (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? Jack Bates (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? Joe Greco (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? Jack Bates (Apr 20)
- Re: Rate of growth on IPv6 not fast enough? Dave Pooser (Apr 18)
- Re: Rate of growth on IPv6 not fast enough? Bill Bogstad (Apr 18)
- Re: Rate of growth on IPv6 not fast enough? joel jaeggli (Apr 18)
- Re: Rate of growth on IPv6 not fast enough? Adrian Chadd (Apr 18)
- Re: Rate of growth on IPv6 not fast enough? Patrick Giagnocavo (Apr 18)
- Re: Rate of growth on IPv6 not fast enough? Chris Campbell (Apr 19)
- Re: Rate of growth on IPv6 not fast enough? Owen DeLong (Apr 19)