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?
>> 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.
Thanks,
--
Yoshifumi Nishida
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm
