WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> 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
>> 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 184.108.40.206 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.