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

[ivan c <[e-mail]>]

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

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.

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

3.1.2.4 I don't think that RFC6191 is widely deployed, do you have any
reference for this?


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

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.



Regards,
Ivan