Re: [BEHAVE] Increasing the session timer for long lived UDP sessions (was Re: Review of the NAT64 document?)

["Senthil Sivakumar (ssenthil)" <[e-mail]>]

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of marcelo bagnulo braun
Sent: Wednesday, January 06, 2010 2:21 PM
To: Reinaldo Penno
Cc: Bryan Ford; IETF BEHAVE WG
Subject: Re: [BEHAVE] Increasing the session timer for long lived UDP sessions (was Re: Review of the NAT64 document?)

Reinaldo Penno escribió:
>
> On 1/6/10 10:46 AM, "marcelo bagnulo braun" <[e-mail]> wrote:
>
>   
>> Reinaldo Penno escribió:
>>     
>>> I object to the proposed timeout mechanism since it is 
>>> implementation specific,
>>>       
>> i disagree it is implementation specific. It does affect 
>> interoperability, since with Bryan's suggested changes, the UDP timer 
>> will be longer for long lived flows, so, end nodes and apps can rely 
>> on that (e.g. the keepalives to keep a UDP hole open could also be 
>> sent with increasing intervals)
>>     
>
> Okay, I see your point. I'm coming from the use case point of view. In 
> the case of NAT64 make it configurable with a lower bound (see below) 
> and when a new class of applications appear that can make use of 
> exponential increasing timers the market will drive it and we can work on an experimental RFC.
>
>   
>>
>>     
>>> but not having idle-timeout configurable.
>>>
>>> I would simply proposed that the UDP/TCP idle-timeout be 
>>> configurable since it is already the case in most NAT implementations from CPEs to CGNs.
>>>
>>>   
>>>       
>> again, we need more than that, at least a minimum timer value, in 
>> order to be compliant with behave requirements.
>>
>> This does affect interop.
>>     
>
> Isn't it REQ-5 of RFC4787? Can we just use it as is?
>
> "  REQ-5:  A NAT UDP mapping timer MUST NOT expire in less than two
>       minutes, unless REQ-5a applies.
>
>       a) For specific destination ports in the well-known port range
>          (ports 0-1023), a NAT MAY have shorter UDP mapping timers that
>          are specific to the IANA-registered application running over
>          that specific destination port.
>
>       b) The value of the NAT UDP mapping timer MAY be configurable.
>
>       c) A default value of five minutes or more for the NAT UDP mapping
>          timer is RECOMMENDED."
>
>
>   
current version of the draft certainly complies with bullet c) It used to comply with bullet a) but was removed in v05 due a commnet from a reviewer. I can put the text back in if the wg wants that.
bullet b) and the minimum timer is not contained in the draft, we can certianly add them

but, in order to decide what to do, i would need more input from the WG

[Senthil] I think a configurable timeout value is a very useful utility and we shouldn't deviate from that. I would make sure that these nat64 drafts don't deviate from the other behave RFCs.

Thanks
Senthil

Regards, marcelo
>
>   
>> Regards, marcelo
>>
>>     
>>> On 1/6/10 9:26 AM, "marcelo bagnulo braun" <[e-mail]> wrote:
>>>
>>>   
>>>       
>>>> During the WGLC for the stateful NAt64 document, Bryan Ford 
>>>> suggested the following change
>>>>
>>>> Bryan Ford escribió:
>>>>     
>>>>         
>>>>> * Third issue is with session timers for UDP.  (I think I brought 
>>>>> up this on this list sometime back, but I don't know if there's 
>>>>> been any discussion of it since then.)  While just having a 
>>>>> constant UDP session timeout of 5 minutes should be permitted 
>>>>> behavior, what would be even better and perhaps RECOMMENDED is if 
>>>>> the NAT increases the session timeout as the session's lifetime increases.
>>>>>
>>>>> For example, if the session survives its first 5-minute timeout 
>>>>> (i.e., the NAT sees traffic during that time), it doubles the next 
>>>>> period to 10 minutes, then to 20 minutes, etc., until some 
>>>>> maximum, e.g., the 2:40:00 timeout specified for TCP in the ESTABLISHED state.
>>>>>
>>>>> This behavior still ensures NAT session state gets garbage 
>>>>> collected before its lifetime exceeds about twice the time the UDP 
>>>>> session is actually in-use; it won't affect UDP apps that naively 
>>>>> just send keepalives at <5min periods; but it may greatly benefit 
>>>>> smarter UDP apps on power-constrained mobile devices that want to 
>>>>> reduce power consumption.  In particular, if the UDP app 
>>>>> implements a binding-timeout-testing algorithm that starts with 
>>>>> frequent keepalives and gradually decreases the keepalive 
>>>>> frequency, then on a "naive" NAT with a 5-min timeout the app will 
>>>>> learn that it has to send keepalives every 5min and do that; but 
>>>>> on a NAT with doubling session timeouts, the session will appear 
>>>>> to the smart app to have an "infinite" (or a
>>>>> 2:40-min) session timeout, and the smart app will be able to 
>>>>> gradually reduce its keepalives to a very low rate and conserve 
>>>>> power even while holding a long-term UDP session open.
>>>>>       
>>>>>           
>>>> I would like to have the WG input on this, please comment.
>>>>
>>>> Regards, marcelo
>>>>
>>>> _______________________________________________
>>>> Behave mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>     
>>>>         
>>>   
>>>       
>
>
>   

_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave