1. Dividing the Pizza An Advanced Traffic Billing System An Advanced Traffic Billing System Christopher Lawrence Burke The University of Queensland

2. Menu  Design  Inputs  Process  Outputs

3. Design - Overview A short analysis was done on the existing mechanisms for collecting traffic statistics and processing them into information used for billing. The existing system relied on several Excel spreadsheets, a lot of manual processing and produced results which were less than accurate. The following couple of slides show simplified versions of the existing and planned processes.

4. Design – The Process Customers and Peer Networkers Proxies Dialup Banks etc Providers (e.g. Optus) Technical Contacts (other ISPs, APNIC) Information Technology Services Data Collectors Standard Format Usage Data Raw Usage Data (various Formats) Traffic Billing Rates “Whois/DNS Data” Bills Specific Technical Data or Triggers Periodic Usage Data or Aggregates

5. Design – The System RAW DATA 15min Blocks Aggregate Processor Trigger Processor Aggregate Rules Trigger Rules Aggregate and Trigger Data Report Writer Networks Who Is Traffic Rates Bill Writer Customers Aggregates Triggers Bills

6. Inputs – Sources  Gateway Routers  HTTP Proxy Logs  Dial-in Quota Logs  Mirror Logs  Any chargeable traffic sink or source.

7. Inputs – Compression  200 flows/second  Raw router data of 200 bytes per flow  Around 1GByte/day of data  Several days of processing per month The University of Queensland traffic collection from just the gateway router was so large that some form of customised compression was needed.

8. Inputs – Record Format Source IP/Source Customer4 bytes Destination IP/Destination Customer4 bytes Byte Count4 bytes Source Port2 bytes Destination Port 2 bytes Duration of Flow in Minutes2 bytes Start of Flow in Minutes from start of file4 bits Protocol (e.g. UDP) 2 bits Source is IP/Destination is IP2 bits Bit mask of 8 traffic types (e.g. international) 8 bits The standard input data structure is a custom compressed format designed to allow a large quantity of data to be kept online. This 20 byte format can be compressed further … but this was thought sufficient for current requirements. The data structure assumes 15minute blocks.

9. Inputs – Collectors There should be one collector for each source or sink that is being monitored. The collectors are responsible for examining and translating the native format data (logs, router output) into 15 minute blocks of standard data format and feeding that data to the central processor.

10. Process - Overview The process needs to analyse the input data. In theory this is a single process – which must run through a list of rules and answer the questions posed by those rules. The outputs are the answers to those questions.

11. Process – 5 W’s and a H  Who  What  Why  When  Where  How The six universal questions

12. Process – When?  A Range of dates and times this rule is valid  How long a period should an aggregate be over, or should a trigger wait.  How often should aggregates be sent, or how many triggers events before someone is alerted.

13. Process – Where/Who?  Source and Destination IP address – list, range or net/mask.  Source and Destination customers for dynamically allocated address space.  Source and destination port – list, range or name.

14. Process – What/How?  What do we want to measure?  How do we want to measure it?  How do we want to trigger?  Number of packets?  Sum of bytes?  Trigger on certain number of packets?

15. Process – Why?  Why are we measuring or triggering?  Are we aggregating for a customer? If so which customer  Are we triggering for input into a monitoring system?

16. Process – Example Question  Start, Stop Date&Time e.g. 2-Jan-2001 to 2-Dec-2001  Period of sample e.g. 4 hourly  Frequency of Message e.g. every 6 periods  Source/Destination e.g. All  130.102.0.0  Source Port/Dest Port e.g. ftp  All  What to count e.g. bytes  How to count e.g. sum

17. Outputs - Overview  Aggregation – Sums, averages or just counts over time.  Triggers – Events that occur, too much traffic, too many connections etc.  Billing – Aggregation post processed adding customer detail and value. There are three basic types of outputs produced by this system they are:

18. Outputs - Aggregation  Personal e-mails with usage data  Departmental weekly statements of activity.  Statistics and predictive analysis of trends in usage.  Protocol usage (e.g. FTP vs HTTP)  Service usage (e.g. how much use is the proxy getting)

19. Outputs - Triggers  Department warnings of prospective over use.  Warnings within 90 minutes of growing usage of particular ports or IP addresses (possible DOS attack developing).  Triggering can be done on the aggregate outputs – allowing warnings if daily usage is increasing beyond certain parameters.  Trigger on irresponsible or unacceptable usage by individual.

20. Outputs – Billing  Post processing of aggregate data combining network structure and ownership with traffic cost and optional commercial markup.  Optionally autmatically e- mail, fax and/or print based on billing periods.  Half period warning bills to prepare customer for likely costs.

21. Conclusion  Currently the router collector and part of the aggregate rules processor is working.  Although much of this system is still in the pipeline, the overall structure is very modular allowing each new step achieved to give immediate improvement on the existing system.  There is around 3 (wo)man- months work left to get much of what is presented here completed