Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 11 Jul 2005 11:57:15 -0700 (PDT)

> -----Original Message-----
> From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] 
> Sent: Monday, July 11, 2005 2:01 PM
> To: Pyda Srisuresh
> Cc: Senthil Sivakumar (ssenthil); ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] FW: I-D 
> ACTION:draft-ietf-behave-nat-udp-02.txt
> 
> On Sun, 2005-07-10 at 02:10 -0700, Pyda Srisuresh wrote:
> > NAT devices do not time latencies [...] NAT devices use 
> idle timeouts
> 
> "idle timeout" is not defined for protocols where only one 
> packet is ever sent or received, as is the case with many 
> ICMP requests.
> 
> 
> > Making the idle timeouts for UDP Sessions dynamic has serious 
> > ramificatiosn on the resource usage and availability,
> 
> I do not agree. If the NAT has space to allocate new mappings 
> and yet expires existing ones prematurely based on some 
> arbitrary timer in anticipation of new connections that may 
> or may not arrive, then the NAT is _wasting_ resources. In 
> the extreme case, there is not reason why a single host 
> behind a NAT (no other internal hosts) running a single 
> application (no other network activity) has to ever send a 
> 'keep-alive'.

The NAT box is not just a NAT box - it does a bunch of other things.
Resources consumed by NAT cannot be held on by an infinite amount of
time, because there are other applications/protocols need this resource
for something else. It is just not acceptable to customers to fill up
the memory as I have seen with my experience. IMO, any proposal in these
lines will be ignored by the NAT vendors - atlest majority of them. I am
yet to hear anybody in this list saying that they would implement them.
I don't see how a timer here is an arbitrary timer and how the resource
based removal of mappings provide a consistent behavior of NAT boxes. 

Also, I don't understand how you would implement the resource based
mappings to provide consistent behavior. Let's say that within a minute
all my ICMP mappings are taken. I would have to drop the new ICMP
mappings until when? If I am using the LRU algorithm the one I am
removing was last used just a minute ago(the first one that was
created). I could potentially cause thrashing. I assume you would say
now use the timer when you have to decide which one to remove first.
What should be the duration of this timer? I believe this WG should not
mandate the implementation but just the requirements. I think I have
said enough on this  topic, I rest my case with strongly opposing any
proposal of resource availability based removal of mappings.

Senthil

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 12 Jul 2005 06:43:36 -0700 (PDT)

> > packet is ever sent or received, as is the case with many 

[suresh] Saikat - What makes you think that "idle timeout" is not used for ICMP
requests.  If a response is not received within the idle timeout, the NAT
Session associated with ICMP request will be dropped. NAT devices do not do
latency measurements for ICMP, AFAIK. Are you aware of NAT devices that do this
differently using latencies for ICMP requests?
 
> proposal of resource availability based removal of mappings.

[suresh] Right. Fully agree with Senthil's comments. I would strongly oppose
any requirement mandating new resource management algorithm implementation.
There are several caveats to doing this. NATs use idle timeouts to manage their
resources, namely NAT Sessions & Bindings. I donot believe, we should propose
newer algorithms. However, if you have alternate suggestions, that can go as
hints to implementors.

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Tue, 12 Jul 2005 14:10:35 -0700 (PDT)

> differently using latencies for ICMP requests?

I may have caused some confusion. I meant that for an ICMP request
response pair (like ping), the "idle timer" is used to overcome the
latency. I do not know whether or not NATs refresh this "idle timer"
when the ping response comes back -- say you were to modify the host
being pinged to generate multiple ping responses (spread over a couple
of seconds) to a single ping request, would that NAT refresh the timer
each time a ping response came in or would it just expire the mapping
after a fixed duration from sending the request. Just wondering ... not
that this affects the UDP draft.

> if you have alternate suggestions, that can go as
> hints to implementors.

Fair enough.

cheers,
-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 14 Jul 2005 10:02:15 -0700 (PDT)

> that this affects the UDP draft.
[suresh] The idle timer is dealt with the same way for all NAT Sessions
(TCP/UDP/ICMP-pings), AFAIk. So, NAT devices that refresh a NAT Session for
both inbound and outbound packets (belonging to that NAT Session) will do the
same for TCP NAT Sessions, UDP NAT Sessions and ICMP NAT Sessions. If a NAT
device chooses to refresh a NAT Session only for outbound packets (belonging to
that NAT Session), it will follow the same approach for TCP NAT Sessions, UDP
NAT Sessions and ICMP NAT Sessions. There is just not enough justification to
do differently for UDP vs. TCP vs. ICMP NAT Session.

cheers,
suresh