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" <marcelo@it.uc3m.es> 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

Regards, marcelo
>
>   
>> Regards, marcelo
>>
>>     
>>> On 1/6/10 9:26 AM, "marcelo bagnulo braun" <marcelo@it.uc3m.es> 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
>>>> Behave@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>     
>>>>         
>>>   
>>>       
>
>
>