[e2e] Some stats broken down by protocol

[Vijay Gill]

Based on some queries regarding protocols and flows, here are some of the
protocol breakdowns.


> Some data regarding flows from the Pacific Rim to the US. Keep in mind
> that the sampling rate used was fairly low.
>
> period:  03/04/2001 15:55:18 - 03/05/2001 15:55:19 PST
> Protocol           Pkts       Pkts/sec          Bytes       Bits/sec
> --------  -------------  -------------  -------------  -------------
>      tcp        4566586             52     1118739284         103585
>     icmp          97183              1       59403325           5500
>      udp         207550              2       33848925           3134
>      esp           2019              0        1216156            112
>     skip            673              0         337732             31
>      gre            298              0          94225              8
>     ipip             93              0          49844              4
>     ospf            108              0          33204              3
>     ipv6             14              0           1327              0
>     rsvp              5              0            580              0
>
> the rsvp is an anomaly.

Adding to the above.

Regarding Panos' query about flows:
Here is what the statman sayeth (josh wepman)

1. How hard would it be to quantify the traffic in terms of "flow"
   (src/dst/port) pair? "Flow" statistics would be very interesting
   (e.g active flows per T-sec, for some definition of flow).  I'm
   working with some folks regarding TCP ECN and flow data would
   be very useful.

Number flows (N) at time (T) (a snapshot)
or
Number flows (N) over time T1 -> T2 (counter over time)

Realtime data is of course out of the question.  We only get "expired"
flow information exported to cflowd.  Historical values can be gotten with
a bit of work.  This is not data available in the cflowd tables maintained
in ARTS data.  #Flows is not an attribute maintained.  So we have to view
the raw flow files.  A snapshot could be obtained by counting all flows in
flows files whose start/end time encompass T(snapshot).  The latter
(counter over time) could be determined by counting all the flows seen
from Time1 to time2.

The value is NOT real as a representation of flows on a link.  They are a
value based on "flows" exported from the router as determined by a router.
A flow could be terminated and exported because a FIN occurred, because it
was idle for time T, or because the total time of the flow exceeded a
limit time value.

In order to do either of the above, it needs to be clear that the value
represented is NOT flows on a link at a given time, but flows seen
exported based on flow-export criteria.  It should also be mentioned that
the functionality to do this does not currently exist in cflowd, so any
efforts here would have to be part of a larger Flow Development effort.


Re: DNS

To or from port53.  More generically, we can use artsprotos to
characterize tcp vs udp vs icmp vs whatever else is seen.  The time
domain can be manipulated to what you may be looking for.  Since
protocol is an ARTS stored value, we have historical data to work with.

Likewise, DNS (port 53TCP/UDP) is maintained in ARTS and available
via artsportms and artsports.  We can state from T1 -> T2, what
was the protocol distribution, and for a set of ports, what were
the port distributions.

As with the first question, we do not have #Flows, but we do have
pkt/byte data.

# /usr/local/arts/bin/artsports daily/arts.20010308.ports
router: blah blah blah
ifIndex: 27
period:  03/07/2001 15:55:20 - 03/08/2001 15:55:18 PST
selected ports: 20-21,53,80,119,443
    Port         InPkts        InBytes        OutPkts       OutBytes
   -----  -------------  -------------  -------------  -------------
    http        5920632      422354154        1350887     1368382195
    ELSE        1055537      252207931           3039        2648398
    nntp         269884       80456315          32733        2257472
ftp-data          39530        4840976          52149       76430542
  domain          69178        4482451          82340       13109974
   https           9266        1253745           4470        2222407
     ftp          10868         560030           6164         319734

This data was based on a 1:64 packet sampling rate and has not been
extrapolated to 1:1 values.  An optimal N for sampling has not been
determined for this class of link, so the degree of skew in the above
numbers cannot be stated with any certainty.  If we assumed that 1:64
sampling did correctly represent the true population, then multiplying out
the values by 64 would give you the approximate real values.

--end statman

Hope this was useful.

/vijay