Hi Mr.Nishida,
(2012/03/14 5:05), Yoshifumi Nishida wrote:
> Hello Mr. Naito,
>
> Thanks for your reply.
>
> On Tue, Mar 13, 2012 at 2:49 AM, Kengo Naito<
naito.kengo@...> wrote:
>> Hello Mr.Nishida,
>>
>> Thank you for your advice.
>> Sorry some part of my draft is not ready.
>> I'll write the answer below,
>>
>> (2012/03/12 13:20), Yoshifumi Nishida wrote:
>>> Hello Mr. Naito,
>>>
>>> I believe the draft aims to solve the following issue.
>>> If server performs active close, it will enter into TIME_WAIT and keep
>>> connection info for 2MSL. if client or NAT picks the same port for a
>>> new connection to the server during this 2MSL period, the connection
>>> attempt will be rejected. On busy NAT boxes, this will prone to
>>> happen.
>> Well, this may be a problem, but in my draft I focus on NAT equipment,
>> which resource is restricted.
>> Problem I state is TIME_WAIT entered into at NAT equipment,
>> and it disables new connection.
> hmm. Do you mean a NAT box maintains TIME_WAIT state just like TCP?
> Or, does this mean tcp proxies? Could you elaborate a bit?
I mean NAT box maintains TIME_WAIT.
I'm thinking of adopting mechanism to assassinate TIME_WAIT state at NAT,
so that NAT equipment can make new connection immediately.
This will work if we can get timestamp from incoming packet, and
maintain it at NAT equipment.
>
>>> Also, can we use the approach described in the section 4.2.2.13 of
>>> rfc1122 instead of rfc6191?
>> As written in rfc6191, we may use sequence number to terminate TIME_WAIT,
>> but rfc6191 tries to prevent the overlap of the sequence number.
>> So, in my opinion, it is preferable to use timestamp option.
> I think the preference is fine.
> I just thought you might want to state if it can be used or not since
> both address the same issue.
OK. Thank you for your advice.
> Thanks,
> --
> Yoshifumi Nishida
>
>
--
----------------------------------------
NTT Service Integration Laboratories
Kengo Naito
E-Mail:
naito.kengo@...
TEL: +81 422-59-4949
----------------------------------------
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm
