Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments ondraft-ietf-behave-nat-udp-05)

From: "Dave Hudson" <[email-masked]>
Date: Tue, 25 Apr 2006 07:45:30 -0700 (PDT)

On a number of residential devices for which we (Ubicom) deliver the
core software we've just upped our timeouts to 5 minutes for UDP and 4
minutes for non-synchronized TCP states from the 2 minutes we used to
use (we did this back in January).  It does lead to more sessions being
tracked but makes a number of P2P-based apps behave better (we see far
fewer firewall messages about rejected packets and those that we do see
now generally come from other NATs that incorrectly translated ICMP
payloads or remapped ports mid-session).  This affects routers from
several vendors (one you queried and several smaller ones you didn't).

Incidently I'd note that there are quite a few different codebases
around in the residential router market and some have very different
implementations of their NAT.  It't not at all unusual to find that
different products shipped by the same OEM have different codebases and
quite different behaviour.

Regards,
Dave

* -----Original Message-----
* From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
* [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
* Pyda Srisuresh
* Sent: 25 April 2006 15:07
* To: Cullen Jennings; Francois Audet; Magnus Westerlund; Dan Wing
* Cc: Behave
* Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution 
* comments ondraft-ietf-behave-nat-udp-05)
* 
* 
* Thank you for the feedback from Linksys. What is the UDP 
* timeout used on the LinkSys, NetGear, D-Link and other 
* residential NAT devices? What are the bounds to the limits 
* they are willing to accept? 
* 
* There are a number of enterprise/data-center devices that 
* embed NAT functioanlity within. They have resource 
* constraints that would be put to test when the timeout is 
* made very long. Not to mention the usage constraints that 
* Ariel mentioned. It woudl be good to consider their feedback 
* as well before mandating.
* 
* Regards,
* suresh
* 
* --- Cullen Jennings <fluffy@xxxxxxxxx> wrote:
* 
* > 
* > I would like to make a comment about low end NAT vendors. Most 
* > comments I make are just my opinion but this morning I 
* contacted the 
* > relevant engineers and Linksys and am passing on the 
* information from 
* > Linksys. I believe and support all this information.
* > 
* > Linksys is by far and away the number one NAT vendors when 
* measured by 
* > number of units shipped. None of the Linksys NATs have a time out 
* > value as low as one minute for this timer. There is no problem with 
* > running out of ports on any of the residnetintial NATs and 
* that is not 
* > a concern. Even with heavy P2P applications, port depletion 
* is not an 
* > issue. The memory to store state for a large number ports is a very 
* > small portion of the total memory budget for the devices 
* and not an issue.
* > 
* > In conversations with Netgear and DLink, I believe they have very 
* > similar beliefs on all this - basically all the low end NAT 
* > manufactures are using very similar code bases on nearly identical 
* > hardware so it is not surprising that if this is not a 
* problem for any of them.
* > 
* > I don't in anyway believe that a 1 minute time out will be 
* useful for 
* > the residential style NATs. I don't know anyone involved 
* with building 
* > these style NATs that believes that 1 minute is needed - 
* there might 
* > be someone but I have not seen them post to the list or talk to me.
* > 
* > I did not go and discuss this issue with the people that build high 
* > end enterprise style NATs at Cisco.
* > 
* > This is a tradeoff between running out of ports on the NAT, and 
* > running out of bandwidth on the link and processing keep alive 
* > transactions on the servers and batter life on mobile clients. Many 
* > people have expressed many concerns about having this 
* number too low.
* > 
* > Cullen <with my individual contributor hat on and passing 
* on data from
* > Linksys>
* > 
* > 
* > On 4/23/06 8:13 PM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:
* > 
* > > 
* > > 
* > > --- Francois Audet <audet@xxxxxxxxxx> wrote:
* > > ...
* > >>>>> 5. Section 4.3: REQ-5:
* > >>>>>    "A NAT UDP mapping timer MUST NOT expire in less 
* than 1 minute,
* > >>>>>        unless REQ-5a applies.
* > >>>>>        a) A NAT MAY have UDP mapping timers that have 
* much shorter
* > >>>>>           timers, but only for specific ports in the
* > >>> well-known port
* > >>>>>           range (i.e., ports 0-1023) where the IANA-
* > >>> registered protocol
* > >>>>>           is strictly a request/response protocol, such as
* > >>> for example
* > >>>>>           DNS over UDP/53.
* > >>>>>        b) The value of the NAT UDP mapping timer MAY be
* > >>> configurable.
* > >>>>>        c) A default value of 5 minutes for the NAT UDP
* > >>> mapping timer is
* > >>>>>           RECOMMENDED."
* > >> 
* > >> We have been trying to balance our requirement for timer values 
* > >> between what makes sense for "residential-grade" NATs 
* versus large 
* > >> Enterprise NATs (who happens to be Firewall at the same time).
* > >> 
* > >> The larger timers make sense for the residential-grade NATs. Req 
* > >> 5-c is useful for residential-grade NATs, because often, the 
* > >> manufacturers are very amiable to a recommended default.
* > >> 
* > >> What we have found however is that the Enterprise NAT 
* vendors where 
* > >> quite uncomfortable with long timers. The change from "2 
* minutes" 
* > >> to "1 minute" for the minimum was a result of request from 
* > >> Enterprise NAT vendors. We are a bit worried that if the 
* timer is 
* > >> too long, they will simply ignore the requirement.
* > >> Req 5a was introduced to allow for optimizations that are very 
* > >> common for large Enterprise NATs.
* > >> 
* > >> So, I think we have three options:
* > >> a - Keep the original value (before -05), which was 2 minutes.
* > >> b - Keep the lower limit from the -05 draft, which is 1 
* minute c - 
* > >> Use 3 minutes, as per Magnus and Cullen's dialog
* > >> 
* > >> Personally, I think that we should revert to what we had 
* before -05 
* > >> which is the 2 minutes. It seems to me that we circled 
* the argument 
* > >> many times now, and that it is the best compromise.
* > >> 
* > >> But I'm happy with any of those values.
* > >> 
* > > [suresh] I agree, makinng the timers long can be problematic to a 
* > > number of NAT vendors, especially those that make low-end NAT 
* > > devices with limited resources.
* > > NAT vendors fine tune these timeouts to suit their customer 
* > > environmets. If IETF mandates the timeouts to be long, 
* the vendors 
* > > could run into support problems they had not not 
* anticipated as NATs run out of resources quickly.
* > > IETF will not be there to help them with the support issues.
* > > 
* > > My vote is to keep the timer at 1 minute. I believe, 
* setting this to 
* > > more
* > than
* > > 2 minutes  could potentially invite unknown support issues. Many 
* > > vendor
* > might
* > > in turn choose not to adapt the madanted timeouts. My 2c.
* > > 
* > > regards,
* > > suresh
* > 
* 
* 
* 
* _______________________________________________
* Ietf-behave mailing list
* Ietf-behave@xxxxxxxxxxxxxxxxxxx
* https://list.sipfoundry.org/mailman/listinfo/ietf-behave
* 
* 
*****************************************************************************
**UPDATE 4/12/06***
Ubicom is Moving!
Effective May 1st, 2006 our new address and phone number will be:
 
Ubicom, Inc.
510 N. Pastoria Ave
Sunnyvale, CA 94085
>>>>NEW NUMBER: (408) 789-2200 - Main
(408) 739-2427 - Fax
www.ubicom.com
 
******************************************************************************

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 25 Apr 2006 18:02:50 -0700 (PDT)

> several vendors (one you queried and several smaller ones you didn't).

[suresh] Thank you for the feedback. This is good to hear, especially the
positive effect the change had on P2P connenctions.

regards,
suresh