Re: [BEHAVE] General Comments on xlate-stateful-07

[marcelo bagnulo braun <[e-mail]>]

Lars Eggert escribió:
> Hi,
>
> On 2010-1-18, at 1:11, Reinaldo Penno wrote:
>   
>> What I mean is that the sentence starts of with "In such cases...".  These
>> 'cases' are those when the NAT cannot determine whether the endpoints of a
>> TCP connection are active, as written.
>>     
>
> right. I believe the thinking was that if you can detect whether the session is alive, you wouldn't time it out if it was, and you would of course time it out if it wasn't.
>
> If you cannot determine this, then the default applies (and can't be shorter than 2 hours.)
>
>   
Right

My proposed way forward is:

- If the NAT64 sees a FIN exchange, then it deletes the binding (after 4 
min) (i.e. we are using the capability of terminating the binding 
earlier than the 2 hr 4 min timeout)
- If the NAT64 sees a RST and no packets for 4 min, then it terminates 
the binding (again we are using the capability of termianting the 
binding earlier)
- if the nat64 times out after 2 hours, it sends a probe packet and if 
no packet is seen after that, it terminates the session after 4 min (in 
this case, we do use the 2 hours and 4 min timeout)

would that sounds ok to you?

Regards, marcelo


> Lars
>
>   
>> Therefore this first paragraph only applies to this condition. If you can
>> actually determine if the NAT endpoints are alive, you do not need to follow
>> this paragraph. 
>>
>> My opinion is that we should just follow REQ-5 as stated. This is would take
>> care of Bryan's proposal as well.
>>
>>
>>
>>
>> On 1/17/10 4:07 AM, "marcelo bagnulo braun" <[e-mail]> wrote:
>>
>>     
>>> Reinaldo Penno escribió:
>>>       
>>>> It clearly says in a)  that the idle timeout MAY be configurable. How
>>>> will my proposed text break 5382?
>>>>
>>>>         
>>> THere are two conditions:
>>> MUST be more than 2 hours and 4 min
>>> MAY be configurable.
>>>
>>> So, my reading of the conditions is an AND of the two conditions, not an
>>> OR.
>>> Maybe someone else should comment whether they think it is an AND or an
>>> OR....?
>>>
>>> If it is an AND, then you can configire the timer, but needs to be
>>> higher than 2 hours and 4 min, in any case, as it is currently stated in
>>> the draft
>>>
>>> It is is an OR, it is as you say, but at this point i don't interpret
>>> the text as a OR
>>>       
>>>> It also says that only in case the NAT cannot determine if endpoints
>>>> are alive.
>>>>
>>>>
>>>>         
>>> right, we are having a disucssion whether the nat64 should send
>>> keepalives to do this, do you think it should or not?
>>>
>>>
>>>
>>>       
>>>> Why we just then just copy REQ5 verbatim?
>>>>
>>>>
>>>>         
>>> on the light of this discussion, it seems that the current wording is
>>> unclear, since you and me have different readings of it
>>>
>>> Regards, marcelo
>>>
>>>
>>>       
>>>> On Jan 16, 2010, at 14:34, "marcelo bagnulo braun"
>>>> <[e-mail]> wrote:
>>>>
>>>>
>>>>         
>>>>> Reinaldo Penno escribió:
>>>>>
>>>>>           
>>>>>> Hello,
>>>>>>
>>>>>> Comment inline...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> Moreover, the ability to
>>>>>>>> configure the idle-timeout is also missing.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> right,
>>>>>>>
>>>>>>> i have added the follwoing text in all the occureences of the the
>>>>>>> setting of the TCP session entry lifetite
>>>>>>>
>>>>>>>                   The lifetime of the TCP session table entry is
>>>>>>> set
>>>>>>> to at least to the maximum session lifetime. The value for the
>>>>>>> maximum
>>>>>>>                   session lifetime MAY be configurable but it
>>>>>>> MUST not
>>>>>>> be less than TCP_EST (the
>>>>>>>                   established connection idle timeout as defined in
>>>>>>> <xref target="RFC5382"></xref>). The default value for the maximum
>>>>>>> session lifetime
>>>>>>>                   SHOULD be set to TCP_EST.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> The whole purpose to have it configurable was to be able to
>>>>>> configure it to
>>>>>> be _less_ than TCP_EST.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> no, that would break REQ5 of RFC5382 that reads:
>>>>>
>>>>>  REQ-5:  If a NAT cannot determine whether the endpoints of a TCP
>>>>>     connection are active, it MAY abandon the session if it has been
>>>>>     idle for some time.  In such cases, the value of the "established
>>>>>     connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
>>>>>     The value of the "transitory connection idle-timeout" MUST NOT be
>>>>>     less than 4 minutes.
>>>>>     a) The value of the NAT idle-timeouts MAY be configurable.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> The text above does not allow it to be set to less than TCP_EST. I
>>>>>> suggest
>>>>>>
>>>>>> "The lifetime of the TCP session table entry is set
>>>>>> to at least to the maximum session lifetime. The value for the
>>>>>> maximum
>>>>>> session lifetime MAY be configurable  The default value for the
>>>>>> maximum
>>>>>> session lifetime SHOULD be set to TCP_EST."
>>>>>>
>>>>>> Tuning TCP idle timeout is widely supported and used.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> right, but the minimum value MOST NOT be less than 2 hours and 4 min
>>>>>
>>>>>           
>>>>>>>> REQ-5: In the NAT64 spec the considerations on NAT throughput
>>>>>>>> performance
>>>>>>>> due to holding session state for TCP RST and TIME_WAIT
>>>>>>>> assassinations due to
>>>>>>>> holding session state are not discussed.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> REQ5 leaves these aspects open and so the nat64 specification. Do
>>>>>>> you
>>>>>>> have any particualr text that you would like to cinlcude in the
>>>>>>> nat64
>>>>>>> spec w.r.t. this?
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> The exact same text (or a reference to it) found in RFC5382.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> could you point out what exact same text you are referring to?
>>>>>
>>>>> Regards, marcelo
>>>>>
>>>>>
>>>>>           
>>>>>> Regards,
>>>>>>
>>>>>> Reinaldo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>>     
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>