Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Jun 2005 17:45:27 -0700 (PDT)

Hi Brian,

Can you clarify what you mean by you agree with the "ongoing
discussion" to resolve it?

I was proposing the following:
        Do people agree with deleting 4.4, Requirement 6b, and the last 
        phrase of 5.2 (everything after the comma). 

Is this what you are agreeing with?

As for the rest of your notes below, I'm assuming that you are not
proposing actual new text for the document, and that the comments
were targetted at the mailing list, right?

> -----Original Message-----
> From: Bryan Ford [mailto:baford@xxxxxxx] 
> Sent: Tuesday, June 21, 2005 09:20
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Cc: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx; Audet, Francois 
> [SC100:9T51:EXCH]
> Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6
> 
> 
> On the REQ-6b issue, I fully agree with Yukata's concerns and 
> support the 
> ongoing discussion to resolve it.  As a side note, though, I 
> just wanted to 
> point out that this presents us with yet another reason we 
> should encourage 
> EF=I NATs as much as possible, and strongly recommend that 
> NATs at least be 
> configurable to EF=I by the administrator whatever their default 
> configuration.  Since as a practical matter any EF=A NAT must have 
> per-session keepalive timers (or at any rate finer than per-binding 
> granularity), applications behind EF=A NATs have to send per-session 
> keepalives.  For applications with a lot of neighbors (e.g., 
> apps running 
> distributed hash table algorithms and the like), that can 
> amount to  a LOT of 
> keepalive traffic.  Applications behind EF=I NATs, in 
> contrast, besides being 
> "first-class citizens" that can help other nodes punch holes, 
> also only have 
> to send keepalives on one session to maintain all their 
> mappings, thereby 
> substantially reducing their "background" traffic load on the Net.
> 
> Of course this still doesn't make applications simpler, since 
> we know in 
> practice applications have to support both EF=A and EF=I 
> NATs.  But in 
> situations where the app is smart enough to detect and take 
> advantage of EF=I 
> behavior anyway (e.g., in order to become a supernode on a 
> P2P network), it 
> can easily leverage this knowledge further by reducing the 
> keepalive traffic 
> it generates to a single session.  Less useless keepalive 
> traffic is good for 
> users and for the Internet.  EF=I is good for users and for 
> the Internet.  
> Nuff said.
> 
> Bryan
> 
> On Thursday 09 June 2005 18:28, 
> yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote:
> >  > The "cleanup" of the sessions is only going to happened
> >  > when the inside endpoint stops sending packets (to anywhere).
> >
> > This is the point I am concerned about. What if the inside endpoint 
> > does not stop sending to some remote hosts for a long time?
> >
> > Let me explain again with an example:
> >
> > Consider host S is behind EF=A/NB=I NAT, providing video streaming 
> > service, for example, from the same local port to *anyone*, like 
> > forever... Accumulative number of connections could be thousands or 
> > millions over time if instantaneous number of connections 
> happens to 
> > be one or more whole time. Since the NAT is EF=A, it has to 
> remember 
> > all the remote host's addresses for the endpoint filtering 
> until the 
> > binding is destroyed. I do not believe that a NAT can store 
> millions 
> > of addresses in memory practically. Then a design might be 
> determined 
> > to have a limit like 256 addresses at maximum for a binding, but is 
> > 256 enough? It is hard tell.
> >
> > The MUST in 6b imposes above problem to implementors. 6b is sure 
> > attractive, but I cannot help anticipating that this may 
> cause another 
> > non-dereministic behavior of NAT. Considering the essential 
> reason to 
> > choose EF=A over EF=I, the sessions no longer in use should 
> be closed. 
> > Actually, an application cannot assume that the NAT it is behind a 
> > behave compliant NAT, 6b is not so useful anyways..
> >
> > - Yutaka
> 
>

---

From: Bryan Ford <[email-masked]>
Date: Thu, 23 Jun 2005 00:07:47 -0700 (PDT)

> Is this what you are agreeing with?

Seems reasonable to me, although deleting just the last phrase of 5.2 seems to 
leave a meaningless sentence fragment ("In the case of ... NATS").  Maybe I'm 
looking at a different version of the text than you are referring to...

   The time for which a NAT filter is valid can be refreshed based on
   packets that are inbound, outbound, or going either direction.  In
   the case of "External Filtering" of "Address dependent" or "Address
   and port dependent" NATs, the scope of the refresh could include the
   filters for just the particular port and destination or for all the
   ports and destinations sharing the same external address and port on
   the NAT.

Did you mean to just delete the whole second sentence?

At any rate, I don't have a strong opinion as to how exactly this issue is 
resolved, as long as it doesn't leave NAT vendors between a rock and a hard 
place like it does at the moment.

> were targetted at the mailing list, right?

Correct.

Thanks,
Bryan