Re: [v6ops] Please review draft-donley-behave-deterministic-cgn

[Chris Donley <[e-mail]>]

This comes down to compression density.  You're right that most
subscribers use few ports, but a few subs do use a very large number (see
the WAND data).  If you pack a lot of subscribers (let's say 1,000) behind
a single IP address, each gets only a handful of ports, and this proposal
almost turns into bulk port logging since many subscribers will be
requesting additional allocations (we're not suggesting per-connection
logging on the overflow).  However, if you pack fewer subs behind a single
public IP (let's say 60), each sub gets ~1000 ports, and 99% or so will
never request another block. Then, using bulk port logging for the
remainder makes for a very small quantity of log messages.  In the example
I presented in Taipei, we can get 100,000x-1,000,000x reduction in log
messages, depending on the size of the port blocks offered for subsequent
allocation.

You're correct that there is a tradeoff between compression density
(per-connection logging wins) and minimizing logging volume (Juniper's
SD-NAT wins). On that continuum, we believe our proposal provides a
balance that keeps log sizes small, but allows a reasonable compression
density while allowing some flexibility to accommodate the 1% of users who
consume significant numbers of ports.


Chris




On 1/4/12 4:18 PM, "Fred Baker" <[e-mail]> wrote:

>
>On Jan 4, 2012, at 2:32 PM, Joel M. Halpern wrote:
>
>> When I asked on operator about the port distribution, their answer was
>>somewhat different.
>> What they said was that when the users are idle, they don't use many
>>ports.  But when the user is busy, they use a lot of ports.
>> This makes repeated, largeish, block allocation sensible, but makes
>>pre-allocation of a small number, and then individual allocation
>>thereafter, a bad strategy, as it will basically log as much as current.
>> 
>> I do not have access to any research results to disambiguate these two
>>reports.
>
>Chris should step in here.
>
>https://www.ietf.org/proceedings/82/slides/behave-5.pdf, quoting
>http://www.wand.net.nz/~salcock/someisp/flow_counting/result_page.html
>also referenced by RFC 6269
>
>In the wand.net.nz HTML, look specifically for "mean number of peak
>sessions for active subscribers only for each 30 minute period"; the HTML
>doesn't have tags that would allow me to simply get you there.
>
>I suspect that Chris/WAND and your service provider might be defining
>"user" and "a lot" differently. The Waikato numbers are very likely
>typical of a residential network behind a NAT - in a home, even if
>several computers are in use, it's unlikely that everyone in the home is
>web surfing during the same minute. Common browsers usually limit the
>number of TCPs they open in parallel to something like 2 or 4, and those
>sessions usually stay open single digit numbers of seconds; this says
>that in a typical residential network, they see 2-4 computers
>simultaneously doing that, for a peak of 4-8 TCP sessions simultaneously
>active. That would be very surprising in a corporate network, but makes
>sense for residential network.
>
>Is the service provider you asked talking about corporate subscribers?
>
>> Yours,
>> Joel
>> 
>> On 1/4/2012 5:27 PM, Dave Thaler wrote:
>>> Yes operational commentary would be very welcome.
>>> 
>>> Also FYI, the author of the draft has declared IPR on it:
>>> https://datatracker.ietf.org/ipr/1617/
>>> 
>>> -Dave
>>> 
>>> -----Original Message-----
>>> From: Fred Baker [mailto:[e-mail]]
>>> Sent: Tuesday, October 11, 2011 6:52 AM
>>> To: v6ops v6ops WG
>>> Cc: Behave Chairs; [e-mail]
>>> Subject: Please review draft-donley-behave-deterministic-cgn
>>> 
>>> Operators subject to law enforcement subpoenas and using Carrier Grade
>>>NAT are having difficulties with the syslog rate for per-connection
>>>logging. Chris Donley has proposed a simplification; the provider
>>>allocates a deterministic set of source ports to his subscribers, and
>>>only needs to log exceptions. Research in the area suggests that usage
>>>of source ports is pareto distributed; a typical user has a requirement
>>>on the order of 4 port numbers in simultaneous use (median), but port
>>>scans and other large volume uses drive the average quite a bit higher.
>>> 
>>> They haven't asked for it, but I suspect the behave chairs would
>>>appreciate operational commentary on the draft.
>>> 
>>> http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn
>>>   "Deterministic Address Mapping to Reduce Logging in Carrier Grade
>>>NATs",
>>>   Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan,
>>>   26-Sep-11
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops