Michel Py wrote:
BitTorrent is a third of p2p traffic in Sweden? Wow. In
the US it is a small blip on the radar.
Petri Helenius wrote:
Should hold water for Sweden too. Wonder why so many of the
bittorrent streams terminate in the US if it's not on your
radar. Maybe time for finetuning the radar ...
Jared Mauch wrote:
BitTorrent is in my "top ten" tcp ports in my netflow.
Gee I must have something wrong. How does in compare to the
FastTrack/Kazaa monster on your side?
Michel.
this is from a 10-15 min sample period, based
on flow count, not bytecount.
TOP TEN:
(tcp)
80, 25, 6699, 4662, 1433
443, 445, 6881, 7171, 6346
(udp)
53, 6257, 27960, 1026, 135
27015, 22321, 1027, 3310, 28960
- jared
Jared Mauch wrote:
this is from a 10-15 min sample period, based
on flow count, not bytecount.
Bittorrent also spreads the traffic (even by default) across multiple ports because it allocates a port per file being downloaded/seeded.
Pete
For June 2004 (AS378 - Israel):
top 10 sending ports:
Rank Port Bytes in Gigabytes Packets
1 http (80/tcp) 1561 GB 1620273534
2 edonkey (4662/tcp) 162 GB 459762654
3 0/icmp 120 GB 851624490
4 ssh (22/tcp) 89 GB 104515538
5 ftpdata (20/tcp) 78 GB 68494269
6 rtsp (554/tcp) 70 GB 54885058
7 https (443/tcp) 66 GB 138954839
8 0/unknown 56 GB 55661555
9 gnutella-svc (6346/tcp) 50 GB 145165558
10 domain (53/udp) 49 GB 371635845
top 10 receiving ports
Rank Port Bytes in Gigabytes Packets
1 smtp (25/tcp) 344 GB 759247104
2 edonkey (4662/tcp) 186 GB 442992500
3 5662/tcp 154 GB 252829581
4 1026/udp 125 GB 205236837
5 1027/udp 119 GB 197314910
6 microsoftds (445/tcp) 91 GB 1721773411
7 netbiosns (137/udp) 88 GB 1209221595
8 http (80/tcp) 87 GB 1073140502
9 2048/icmp 62 GB 974609659
10 6970/udp 57 GB 103562134
We have hourly, daily, weekly and monthly stats.
-Hank
How are ISPs monitoring P2P traffic these days? Monitoring based on
Netflow/cflowd data and fixed port numbers for application
classification doesn't seem to do the trick anymore as more P2P
applications use random port numbers or even use port 80, with the
purpose of circumventing potential ISP policies or accounting.
With Netflow/fixed port nrs the amount of 'unknown traffic' is
increasing steadily.
The next step in P2P recognition seems to be deep packet inspection with
signature based detection. The major problem here is scalability - I
don't see some device analyzing 1G, the typical uplink capacity of
Internet gateways in a medium SP network, of traffic at layer 7.
If this should be feasable, what if P2P applications would employ
encryption schemes (e.g. IPSec) - this would render signature-based
recognition useless.
-walter
you can also be fairly accurate from the flow data.. eg genuine web traffic is
short small transfers, P2P is long-lived flows of continous high usage
Steve
In the long run, there is no way to accurately determine what kind of
traffic everything is, and short of making encryption illegal and doing
deep packet inspection, there is no future for those kinds of measures
anyway.
Only way I see is to use L3 information as that's basically the only thing
we're asked from our customers to handle (in most cases anyway), we move
packets from one IP address to another IP address.
Mikael Abrahamsson wrote:
you can also be fairly accurate from the flow data.. eg genuine web traffic is short small transfers, P2P is long-lived flows of continous high usage
In the long run, there is no way to accurately determine what kind of
traffic everything is, and short of making encryption illegal and doing
deep packet inspection, there is no future for those kinds of measures
anyway.Only way I see is to use L3 information as that's basically the only thing we're asked from our customers to handle (in most cases anyway), we move packets from one IP address to another IP address.
This might be true from a transit provider standpoint or 'packet mover', but not for DSL/Cable operators which are also ISP. They see big traffic increases over the last 2 years mostly due to P2P that trigger expensive network upgrades in the access - network load (and the investments related to it) and the revenues from subscribers are diverging. Such operators typically have flat rates and have a limited nr of profiles in terms of up-/downstream BW and Cap/month. A small percentage of the subs (20-30%) is responsable for a large percentage of the aggregated load on the network (60-80%).
It makes more sense to introduce more differentiation in product offerings (pricing) where BW 'hoggers' pay more than the 'moderate' users instead of a general price increase. The net effect should be that profits increase, either by reduced network load or by higher revenues from product differentiation.
This differentiation is less effective when it is based purely on US/DS BW and CAP alone. The main issue from a access network standpoint lies in the concurrent usage during peak hours where BW hoggers could affect the casual surfer. Surely, the monthly cap and rate-limitations mitigates this somewhat but only to a certain degree. A more efficient way would be to offer differentiated application-based services (e.g. gaming, P2P, VoIP, ...) Some of the applications could be accounted for at the service endpoint (e.g. gaming portal,voip services provided by the ISP), others need network-based metering/control.
accounting/monitoring applications => know your users => define products => network-based enforcement
Caveat: this might be an utopian vision 
-walter
Walter De Smedt wrote:
The next step in P2P recognition seems to be deep packet inspection with
signature based detection. The major problem here is scalability - I
don't see some device analyzing 1G, the typical uplink capacity of
Internet gateways in a medium SP network, of traffic at layer 7.
If this should be feasable, what if P2P applications would employ
encryption schemes (e.g. IPSec) - this would render signature-based
recognition useless.
We can do realistically 1.3G with current bits. I�m not ready to talk about performance by the end of the year. As a bonus, you'll get classification and population reports for both p2p and backdoored / virused hosts without performance impact.
(export these with BGP4 to fancy effects, or simple ACL / firewall list for more traditional approach)
Pete
way would be to offer differentiated application-based services (e.g.
gaming, P2P, VoIP, ...) Some of the applications could be accounted for
at the service endpoint (e.g. gaming portal,voip services provided by
the ISP), others need network-based metering/control.
I understand the desire, but I'm saying it wont be technically possible to
do so in the long run. The internet will route around such "problems". If
you start to allow port 80 traffic freely, p2p will start to look like web
traffic. You then have to start blocking port 80 servers on your DSL
population and get everybody else to do the same, and whammo, we're in the
same problems we're seeing with spam, consuming large amount of man-hours.
accounting/monitoring applications => know your users => define products
=> network-based enforcementCaveat: this might be an utopian vision
Unfortunately, I believe so.
Also, your figures regarding who uses bw are not the same as mine. I'd say
a lot of the time less than 10% of the users will use more than 80-90% of
the bw.