Rate of growth on IPv6 not fast enough?

James Hess mysidia at gmail.com
Tue Apr 20 06:20:09 UTC 2010


On Mon, Apr 19, 2010 at 11:47 PM, Adrian Chadd
<adrian at 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




More information about the NANOG mailing list