> > The definition of a flow need not be the TCP definition of a > > flow. I am not sure if it will help, but any the queuing > > discipline and ingress que filter are able to work with any > > combination of protocol, source port number, source ip, dest > > port, dest ip as the definition of a flow. This may or may > > not help. > > Ah, that's very interesting. So you could assign all traffic to/from a > 'hog' ISP customer to the elephant category. You cannot assign it as such, it has to happen automaically. If you made the definition of a flow to be the source/destination IP number then the flow consisting of traffic to/from a 'hog' computer would find itself soon find itself designated as an elephant. If this is deployed on the router where the NAT occurs, then the queuing discipline sees the internal IP numbers. The time scales over which a flow becomes/ceases to be an elephant are configurable. There is also a mechanism to have the queuing discipline not purely mice and elephant and not purely fair queueing, but somewhere in between. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
