Subject: Re: [tcpm] New Version Notification for draft-naito-nat-resource-optimizing-extension-00.txt

From: Kengo Naito <[email-masked]>
Date: Tue, 06 Mar 2012 09:59:02 +0900

Pasi,
tcpm members,

Hi, I wrote a new draft written below.

https://datatracker.ietf.org/doc/draft-naito-nat-resource-optimizing-extension/?include_text=1

I've already asked Pasi for adding this discussion to Agenda, Paris.
There's some topic I want to add to my draft, which I'll do so by Paris.
(which I wrote like "I'll write this part by Paris" in 00 version)

I would appreciate your comments and advice.

Best regards,

(2012/03/05 21:50), [email-masked] wrote:
> A new version of I-D, draft-naito-nat-resource-optimizing-extension-00.txt has been successfully submitted by Kengo and posted to the IETF repository.
>
> Filename:	 draft-naito-nat-resource-optimizing-extension
> Revision:	 00
> Title:		 NAT resource optimizing extension
> Creation date:	 2012-03-05
> WG ID:		 Individual Submission
> Number of pages: 4
>
> Abstract:
>     When NAT is used in address resource restricted environment, or when
>     a lot of users are located under a NAT device, IP address and port
>     resources may be eaten up, and it brings severe bad effects on user
>     experiences.  This situation can be greatly mitigated by tweaking
>     mapping behavior and session timer handling at NAT function.  This
>     document proposes to NAT IP address and port resource optimizing
>     extension for address resource restricted environment.  One extension
>     is to enable simultaneous use of a port for different transport
>     sessions, and the other is to make use of TCP timestamp for TIME_WAIT
>     Assassination.
>
>
>
>
> The IETF Secretariat
>
>

-- 
----------------------------------------
NTT Service Integration Laboratories
Kengo Naito
E-Mail: [email-masked]
TEL: +81 422-59-4949
----------------------------------------

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 11 Mar 2012 21:20:18 -0700

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.

I think there are 3 entities in this draft: TCP client, TCP server and
NAT. I think it would be better to articulate which entity your
proposals are aiming.
I think the section 2.1 describes the behavior of NAT. This seems to
be a bit out of scope for tcpm.

The section 2.2 seems to describe the behavior of tcp server, although
the section title seems to indicate updating the behavior of NAT.
In addition, in order to make this work properly, I think client, NAT
and server will need to support rfc6191. But, the deployment of this
approach looks difficult. The authors might need to describe the case
where this approach doesn't work.
Also, can we use the approach described in the section 4.2.2.13 of
rfc1122 instead of rfc6191?

Thanks,
--
Yoshifumi Nishida

On Mon, Mar 5, 2012 at 4:59 PM, Kengo Naito <[email-masked]> wrote:
>> A new version of I-D, draft-naito-nat-resource-optimizing-extension-00.txt
>> has been successfully submitted by Kengo and posted to the IETF repository.
>>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Kengo Naito <[email-masked]>
Date: Tue, 13 Mar 2012 18:49:19 +0900

Hello Mr.Nishida,

Thank you for your advice.
Sorry some part of my draft is not ready.
I'll write the answer below,

> 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.

> NAT. I think it would be better to articulate which entity your
OK. I'll write it in my slides for Paris meeting.

> be a bit out of scope for tcpm.
I'm also talking with chairman in behave WG.
I'll discuss this part at behave.

> where this approach doesn't work.
OK. I'll write it in my slides for Paris meeting.
> 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.

regards,

>
> Thanks,
> --
> Yoshifumi Nishida
>
>
> On Mon, Mar 5, 2012 at 4:59 PM, Kengo Naito<[email-masked]>  wrote:
>> Pasi,
>> tcpm members,
>>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 13 Mar 2012 13:05:43 -0700

Hello Mr. Naito,

Thanks for your reply.

> 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?

> 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

---

From: Kengo Naito <[email-masked]>
Date: Thu, 15 Mar 2012 20:12:52 +0900

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<[email-masked]>  wrote:
>> Hello Mr.Nishida,
>>
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.

> both address the same issue.
OK. Thank you for your advice.

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Mar 2012 12:47:48 -0700

> and it disables new connection.

As it should. Please don't forget that as far as the rest of the network 
is concerned, the NAT *is* the endpoint of that TCP connection, and all 
of the rules of IP, ICMP, TCP, and host requirements and their updates 
apply.

Joe