Re: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis

[Kengo Naito <[e-mail]>]

Hi Ivan,

Thanks for comments,

(2013/06/19 1:50), ivan c wrote:
> Hi Kengo,
>
> See my answers interleaved below.
>
> On Tue, 18 Jun 2013 13:56:54 +0900, Kengo Naito  wrote:
>
>>   Then, how about using 3.1.2.2 ? This alternative do not rewrite
>> timestamps nor ISNs.
>>   Also, I do not intend to make 3.1.2.1 "must", this is only one of
>> alternatives.
> 3.1.2.1 will be most definitely frowned upon. Before suggesting such
> alternative, the benefits need to be quantified in terms of CGN resources
> usage. Is the TIME_WAIT state really that much of an issue for CGN resource
> utilization? It looks to me as a micro-optimization. Of course, this can
> still be suggested as a MAY in the document (as it's an interesting idea).
For someone who uses CGN and do not have enough ports ready can use this 
micro-optimization(3.1.2).
Ofcourse, there are other ways to handle port shortage problem(such as 
port-overloading).
So, I agree with your point that this should be suggested as MAY.
Also, we should remove 3.1.2.1 and only write 3.1.2.2.
I'll explain 3.1.2.2 below.

>
> 3.1.2.2 I was unable to fully grasp the idea and its relationship with the
> TIME_WAIT state, it would be nice if you could elaborate on this.
In this mechanism, usable port set are splited to each client, which 
means that for each port,
arriving packets have monotonically increasing values of TCP timestamp 
or ISN.
In this case, as values are monotonically increasing, 6191 will work and 
terminate TIME_WAIT.


> 3.1.2.3 you're mangling with the TCP protocol itself, which is arguably
> even more intrusive than mangling with so fields in the TCP header like in
> 3.1.2.1
Okay.
If the last ACK getting lost is the rare case and  no bad effects 
occure,  we should remove this part.

>
> 3.1.2.4 I don't think that RFC6191 is widely deployed, do you have any
> reference for this?
>
Section 1. of RFC 6191 says that RFC 1122 4.2.2.13(which uses ISN to 
terminate TIME_WAIT) is included in the Linux kernel.
(RFC 1122 4.2.2.13 functuion is a part of 6191.)
Also, I checked some OSes a year ago which had RFC 1122 4.2.2.13 function.

-Linux 2.6.18(CentOS 5.6)
-FreeBSD 7.4R
-Windows 7
-MacOSX Lion


>> In
>> the draft, I meant that Port overlapping behavior can only be used when
> the
>> 5-tupple of connections are different.
>> So I think it is a bit different from overlapping behavior you wrote.
>> Does this behavior cause any bad effect?
>
> There are a few issues with the section 4. of the draft.
>
> Quoting: "This document clarifies that this port
>     overlapping behavior can be extended to connections originating from
>     different interal source IP:ports as long as their destinations are
>     different.  This known as EDM (Endpoint Dependent Mapping)."
>
> No, EDM, EIM, always refer to sessions originating from the *same local
> endpoint*.
> Here you are describing a "port overlapping" behavior for sessions
> originating from distinct endpoints. This is known as "port overloading".
> EDM refers to the case where we can sometimes "break" the EIM requirement,
> for example when we know it doesn't adversely affect the application (such
> as with HTTP).
>
> In your second paragraph, you clearly describe the "port overloading"
> behavior. Thus, I think you should drop the "port overlapping" terminology,
> replace it with "port overloading", and don't mention EDM
> (Endpoint-Dependent Mapping), which is not directly related to the topic.
  I understood that as you wrote below, 5-tuple uniqueness for port 
overloading is a MUST, and  that means I was trying to describe "port 
overloading".
Excuse me for my misunderstanding.
I should write "port overloading" in next revision.

>
> Port overloading does not have any bad effects. Of course, as long as the
> 5-tuple uniqueness is preserved by the NAT, which is a MUST in any case.
> However, doing aggressive port overloading generates opportunities for
> collisions, which must be dealt with by dropping a session or breaking the
> EIM requirement, which is a serious problem for UDP, but not so much for
> TCP. Such collision events remain rare, and it is OK to break EIM sometimes
> for TCP, as the application can make a retry (using a new ephemeral local
> port), that will most certainly work the second time.
>
>
> I can help you develop and improve the section 4. of the draft with you if
> you'd like.
I'll be glad if you do so.

>
>
>
> Regards,
> Ivan
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>


-- 
----------------------------------------
NTT Network Technology Laboratories
Kengo Naito
E-Mail: [e-mail]
TEL: [phone]
----------------------------------------