1 / 14

Implementing TCP Attributes or Web-Proxy Traffic Statistics

Implementing TCP Attributes or Web-Proxy Traffic Statistics Nevil Brownlee The University of Auckland Los Angeles IETF, March 1998. Background. RTFM architecture defines traffic flows in terms of a set of ‘attribute’ values Address attributes define a flow’s endpoints

olga-sharpe
Download Presentation

Implementing TCP Attributes or Web-Proxy Traffic Statistics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing TCP Attributes or Web-Proxy Traffic Statistics Nevil BrownleeThe University of AucklandLos Angeles IETF, March 1998

  2. Background • RTFM architecture defines traffic flows in terms of a set of ‘attribute’ values • Address attributes define a flow’s endpoints • Other attributes contain information about the flow, e.g. • packet and byte counts (in each direction) • first and last packet times • Xwindow traffic analyzer program nifty can display flows in real time The University of Auckland

  3. Few flows lasting longer than about 2 minutes ! C = cache (port 3130) W = www (80 or 8080) The University of Auckland

  4. U of A Gateway Network Drawbridge Router Router WebProxy Accounting Meter CampusBackbone Internet The University of Auckland

  5. ‘TCP Attributes’ • Strong interest in information about TCP flows • Example: To/From TCP Octet counts, i.e. difference between last and first TCP sequence numbers for a flow • Easy to measure for a single TCP stream (IP address:port pair) • Can be aggregated across multiple streams, e.g. for all ports, all hosts in a subnet, etc. • Want RTFM meter to do this aggregation - need some TCP stream statistics before starting on implementation The University of Auckland

  6. Getting TCP Flow Data • Write NeTraMet ruleset, collect flow data • Write perl programs to analyze the data • For this project: • Collect TCP flows for all traffic between UA web proxy and hosts inside UA • Each flow represents an http object. Group these into ‘pages’ and ‘sessions’ • Plot ‘interesting’ distributions The University of Auckland

  7. Ruleset for RTFM Meter # 1010, Fri 13 Mar 98: Rules to watch web proxy traffic # RULES if SourcePeerType = IP save, goto IP_pkt; ignore; # IP_pkt: if DestTransAddress = 8080 # Proxy port number && DestPeerAddress = 130.216.191.6/32 # www-proxy.auckland && SourcePeerAddress = 130.216/16 # Inside UA network goto count_pkt; nomatch; # count_pkt: save SourcePeerAddress /32; # User's IP address save SourceTransAddress; # and port number count; The University of Auckland

  8. Sample Flow Data ##NeTraMet v4.1: -c300 -r rules.dist.www scream hme0, le0 #Format: sourcepeeraddress firsttime sourcetransaddress lasttime topdus tooctets frompdus fromoctets flowruleset flowindex sourcepeertype #Time: 09:30:00 Mon 16 Mar 1998 scream Flows from 48074 to 51713 130.216.97.217 48331 1316 48331 1 60 0 0 19 1072 1 130.216.97.217 48331 1307 48331 1 60 0 0 19 1073 1 130.216.97.217 48331 1314 48331 1 60 0 0 19 1074 1 130.216.97.217 48331 1312 48331 1 60 0 0 19 1075 1 130.216.51.63 48397 1122 48446 6 819 6 1040 19 1076 1 130.216.30.50 48591 1161 48616 7 606 3 3079 19 1077 1 130.216.98.157 48901 1123 49459 7 934 7 3808 19 1078 1 130.216.51.63 48987 1123 49463 5 668 4 732 19 1079 1 130.216.51.63 48988 1124 49040 5 642 4 1158 19 1080 1 130.216.85.223 49035 1033 49056 5 544 4 1494 19 1081 1 130.216.25.123 49186 1147 49756 10 913 11 8926 19 1082 1 130.216.51.63 49231 1125 49283 5 610 4 1114 19 1083 1 130.216.51.63 49231 1126 49382 6 666 5 1158 19 1084 1 The University of Auckland

  9. Analysing the data • Analysis: • Sort flow records into SourceAddress + FirstTime order • Delete all but last record for each flow • Group flows into pages by looking for 0.5s gaps between them • Group the pages into ‘sessions’ by looking for changes in SourceAddress • Results: • About 4 hours data • 37866 flows, 8189 pages, 489 sessions • Using 0.2s or 0.1s made almost no observable difference to the number of pages The University of Auckland

  10. Web Flow Statistics The University of Auckland

  11. Web Page Statistics The University of Auckland

  12. Web Session Statistics The University of Auckland

  13. Conclusion • RTFM makes it very simple to collect the data ! • Web statistics summary: • Most web flows involve 12 or less packets, carrying less than 5 kB of data • Most web pages involve less than 30 packets carrying less than 50 kB of data • More than half the pages had only one or two flows! • UA pages take 10 to 30 seconds to get, and UA users look at each page for 20 to 60 seconds • There were never more than 50 flows active at any time; the median number of active flows was only about 15 • NeTraMet need only keep a table of, say, 200 flows to compute aggregate TCP attribute values The University of Auckland

  14. Traffic Flow References • RTFM Working Group mailing list:rtfm@auckland.ac.nzsend ‘subscribe rtfm your.address’ to majordomo@auckland.ac.nz • RTFM Working Group home page:http://www.auckland.ac.nz/net/Internet/rtfm • NeTraMet home page:http://www.auckland.ac.nz/net/ Accounting/ntm.Release.note.html The University of Auckland

More Related